Make it possible to configure images

[aarnq]

Is your feature request related to a problem? Please describe.

Compliant Kubernetes is static when it comes to the configuration of which images it uses, and we should change this to address some key scenarios:

• Using a private registry mirror instead of a public registry
• Using a pull through cache (by finding all repositories needed to be cached)
• Patching an image version to mitigate vulnerabilities

Describe the solution you'd like

Make it configurable for each instance of where we are using an image so we can:

• Configure the registry of the image (falling back to the one defined by the chart)
• Configure the repository of the image (falling back to the one defined by the chart)
• Configure the tag of the image (falling back to the one defined by the chart)
• Configure the sha of the image to better enforce which image we are using.

Make it configurable on a global level so we can:

• Configure the registry of all images (if they do not have an specific override).
• Configure the repository of all images (if they do not have an specific override).

This should also include images in resources created by operators to ensure that they are captured as well.

Definition of done:

• [ ] Images used can be individually configured.
• [ ] Image registry can be globally configured.

[cristiklein]

We solved this by configuring the container runtime, as opposed to the apps layer: https://elastisys.io/compliantkubernetes/operator-manual/air-gapped-environment/#migrating-images-manually

Is this issue still relevant?

[simonklb]

We solved this by configuring the container runtime, as opposed to the apps layer: https://elastisys.io/compliantkubernetes/operator-manual/air-gapped-environment/#migrating-images-manually

Is this issue still relevant?

@aarnq feel free to correct me if I'm wrong. I think the idea here is for us to declaratively configure each image so that we are in more control of what is running in the cluster. It looks to me that the link you provided describes how to ingest images when you don't want to pull directly from the upstream registries.

[aarnq]

We solved this by configuring the container runtime, as opposed to the apps layer: https://elastisys.io/compliantkubernetes/operator-manual/air-gapped-environment/#migrating-images-manually Is this issue still relevant?

@aarnq feel free to correct me if I'm wrong. I think the idea here is for us to declaratively configure each image so that we are in more control of what is running in the cluster. It looks to me that the link you provided describes how to ingest images when you don't want to pull directly from the upstream registries.

Yes, so the goal of this issue is to go further and allow us to have an inventory of images that we can approve by pinning the checksum and sign. Allowing us to secure our supply chain by fetching the images we need, and better respond to vulnerabilities by using rebuilt or patched images dynamically, rather than statically. And it will help if we want to start to rebuild images to ensure that they have the latest patches applied when we prepare releases.

And it would compliment the air-gapped scenario as it would provide a better inventory of images that are required, and potentially simplifies how that can be managed in apps. (In such scenarios configuring mirrors in the container runtime will still be needed as this doesn't cover the Kubernetes and infrastructure layer, but it will provide a process to implement it elsewhere.)

[cristiklein]

@aarnq Understood, thanks for the clarification!