Avoid vulnerable container images¶
This section helps you implement ISO 27001, specifically:
- A.12.6.1 Management of Technical Vulnerabilities
- This safeguard is enabled by default with the enforcement action
denysince Compliant Kubernetes apps v0.19.0. As a result, resources that violate this policy will not be created.
- The default enforcement action for this safeguard has been changed to
denysince Compliant Kubernetes apps v0.29.0. As a result, resources that violate this policy will generate warning messages, but will still be created.
A healthy security posture requires you to ensure your code has no known vulnerabilities. Compliant Kubernetes comes with a registry which includes vulnerability scanning of container images. It can even be configured to prevent the Kubernetes cluster from pulling images with vulnerabilities above a set criticality. This is a per-project setting, so you could, for example, have a stricter policy for publicly facing application components -- e.g., the front office -- and a less strict policy for internal application components -- e.g., the back office.
Public container registry, such as Docker Hub and Quay, might not stick to the vulnerability management you require, perhaps being at times too strict or too loose.
You can designate a set of registries, a project within a registry or specific container images as trusted. By this you declared that you did a risk analysis and determined that they fulfill your security requirements.
How Does Compliant Kubernetes Help?¶
Your administrator can configure Compliant Kubernetes to technically enforce a set of trusted container registries. This means that if you accidentally reference an image in an untrusted registry, you will get the following error:
Error: admission webhook "validation.gatekeeper.sh" denied the request: [denied by require-harbor-repo] container "ck8s-user-demo" has an invalid image repo "harbor.example.com/demo/ck8s-user-demo:1.16.0", allowed repos are ["harbor.cksc.a1ck.io"]
The resolution is rather simple. You have two options:
- Change the container image to point to a trusted registry.
- Get in touch with your administrator and discuss augmenting the set of trusted registries.
Instead of adding a not-really-trusted registry to the set of trusted registries, prefer mirroring some public images in your Compliant Kubernetes registry.
If your administrator has not enforced this policy yet, you can view current violations of the policy by running
kubectl get k8sallowedrepos.constraints.gatekeeper.sh require-harbor-repo -ojson | jq .status.violations