Trusted Repositories and Container Registries in Kubernetes

In this topic, we will consider some of the key capabilities of trusted repositories and container registries. We will cover secure authentication, scanning and signing of content as necessary practices that ensure a secure Kubernetes environment.

In order to establish a deployment of Kubernetes cluster and application workloads into that cluster, it is important to mention the container repositories and containers that are used as a part of the deployment pipeline. There are actually 3 main steps that would ensure that your cluster is secured:

1. Content Signing

• Automate Secure Policy: Tooling must support policies regarding the onboarding of unsigned content and content signing.
  This means that when you deploy and it goes to get a container from a registry you have an option to use software that will pull only signed content and there is a security setting in Kuberenetes that will always pull the latest content.

2. Keys and Certificates

• Authentication and Authorization: Repositories must support regularly rotated permissions and credentials.
  These keys and TLS certificates will be a part of Kubernetes security infrastructure to ensure that malware wouldn’t be implemented through mentioned repositories. And they wouldn’t find a way to Kubernetes environment.

3. Scanning

• Hygiene and Vulnerability Scanning: Internal and third party repositories must be scanned on an ongoing basis to remediate and identify vulnerability and malware.
  The scanning includes the Kubernetes executables and in case of the YML files, organizations typically have to scan those as well to make sure that hackers are not able to explore configuration files.

Let’s take a closer look at this diagram:

Utilizing repositories for software whether it could be third-party components or source code that make up a framework for the infrastructure or application, you have to look at whether it is a public/signed/public repository or trusted registry? It might be that it is just a repository and not a registry, in that case, they may not contain the full ability to implement a security policy. The reason is that the difference between registry and repositories is whether there is metadata!

The metadata defines the content and allows applications when they pull that content from the repositories to measure against the policy.

• Is it signed by the an authorized vendor?
• Is the image we consider is safe?
• Is this image was scanned?

So, these repositories and registries are used in all stages of the environment provided above. Sometimes repositories, where you are pulling things into a Development, may not be as secure as the downstream Test, Staging and Production level. And so some of the public repositories are wide open, especially with all the open-source that is available via public repositories, for instance, GitHub. But as we move through the process we have to lock things down. Test needs to replicate the environment that is Staged for further (stress/)testing and Production environment. In this case, trusted registries are necessary for implementation if you are going to support a secure Kubernetes infrastructure.  

Kubernetes infrastructure is only as secure as the applications running on that infrastructure. So, as you promote things through Development, Test, Staging, and Production the role of trusted registries is extremely important. Remember, Kubernetes security does not start and stop the Kubernetes components themselves, it includes the entire pipeline which includes repositories and software on-boarding process.

Discover more with Gcore Managed Kubernetes