In the sections below, we outline in greater detail some of the Kubernetes best practices you should follow for all three stages of the container lifecycle.
Build Phase
First and foremost, you must secure your container images. This involves first building secure images and then scanning for vulnerabilities.
Best practices are to use minimal base images and avoid using images with shells or OS package managers — these can bring unknown vulnerabilities into your system. Also, avoid adding unnecessary components and only use up-to-date images. You must ensure that any tools, applications, and all images are up to date.
Regular scanning is an important part of Kubernetes security, so make sure to use a scanner that can identify image vulnerabilities, as well as OS package and third-party runtime vulnerabilities. These scans and security checks should be built into and automated as part of your continuous integration/continuous deployment (CI/CD) pipeline. For example, the Validating Admission Controller in Kubernetes allows you to reject deployment creation if images are not scanned before deployment or if the images are over 90 days old.
Keep in mind that the best security policy is defense in depth. So, a vulnerability in one area, such as in a container, a cluster, the cloud, or in your code, can be addressed before it has production impact and before it can reach other parts of your network.
Deploy Phase
You must securely configure your Kubernetes infrastructure before workloads are deployed. You need to know what you are deploying and how, and from there, you can identify and respond to potential security threats or violations.
Knowing exactly what you are deploying requires an understanding of:
- Components
- Known vulnerabilities
- Pods that will be deployed
- All clusters, namespaces, and nodes involved
- Whether it will run privileged
- What deployments it will communicate with
You also need to know what it can access and whether the deployment is already in compliance with – or violation of – any security or policy requirements.
From there, you can implement deploy-phase recommendations. These include using namespaces to isolate sensitive workloads to contain potential attacks, limiting the impact of any errors or malicious actions taken by authorized users, and controlling traffic between pods and clusters via network segmentation to prevent unauthorized lateral movement across containers.
As a general rule, you must always evaluate access privileges by anyone and anything in your system, including access permissions of your containers. Only give your containers the privileges and capabilities it needs to perform its required function(s).
Also, never deploy code from an unknown source, which in Kubernetes means only using images from known registries or those with authorized access. Relevant business resources such as developers and programmers should know how to label deployments with the correct name or alias so that the relevant teams can address the security issues they are responsible for should any arise.
Runtime Phase
You can manage Kubernetes’ security challenges by gaining visibility into the runtime environment and detecting and then responding to runtime threats as they arise.
This involves monitoring process activity, network communications between different containers and containerized services, and communications between containers, containerized services, and third-parties, clients, or external servers.
By comparing observed versus expected activity, you can identify and then stop suspicious activity. By extending vulnerability scanning to running deployments will help you catch runtime vulnerabilities that did not appear before. Many Kubernetes built-in controls such as read-only root file systems can prevent attacks that require software installation, and you should monitor network traffic to limit unnecessary or unsecured communications.
