Trusted image registries

Context

Attackers could use a poisoned docker image to break out of a container and gain access to the hosts\nodes in a Kubernetes cluster.

For example, the Azure Threat Metric for Kubernetes could enlight four example scenarios of Kubernetes attack with the used of untrusted image repositories:

• Initial Access – Compromised Image: A workstation has been compromised and the attacker could use stolen credentials to deploy a poisoned docker image through the CICD pipeline.
• Execution – Running untrusted code inside of a container: A poisoned image used could contain an embedded reverse listener that will connect back to the attacker console and provide a shell when the container is deployed.
• Persistence – Backdoor Container: An attacker that gained partial access to the cluster may use existing weaknesses in the design to attach a poisoned image during the container deployment process. Armed with access and inherited permissions, the attacker could potentially capture the contents of the service account token mounted in the container.
• Privileged Escalation – Breaking out of the Container: Once a poisoned image deployed, an attacker could escape out of the container and exploit vulnerabilities to gain power over the underlying hosts/nodes in the Kubernetes cluster.

In order to protect your cluster, K8SaaS provides a policy to restrict the access to only trusted image registries.

Use case

• Control the sources from which the container images are pulled and pushed from your Kubernetes cluster.

What to do ?

Please raise a ticket to support-platform, asking for an escalation to "TDP-k8saas" group, with the following information:

• URL of the registries that you will only be allowed to pull images

Known limitations

Linkerd is deployed by default in your cluster, and k8saas use public images. So to enable trusted registries, we'll add the cr.l5d.io registry managed by linkerd.

How to test this feature ?

A getting started is provided in the Thales gitlab Innersource: link