Container Security Considerations in a Kubernetes Deployment
Before we can dive into the security aspects of Kubernetes, we must first understand the relevant security issues with the container infrastructure itself. (See our previous articles, for more on the threat models that apply to all Kubernetes deployments and the four tenets of Kubernetes security.)
To run containers in a secure fashion, each Linux node must be properly configured and hardened. The Center for Internet Security (CIS) benchmarks for Docker and a corresponding CIS benchmark for Kubernetes contain many hardening guidelines that operational teams should follow.
For instance, one of the recommended practices is to enable built-in Linux security measures, such as SELinux and Seccomp profiles. SELinux is a kernel-level capability that regulates access to files and network resources, while Seccomp profiles restrict the set of system calls an application can make. Together, these capabilities allow a level of fine-grained control over the workloads that run on the node.
In general, major considerations of node security include:
- Securing node communications with a TLS client certificate, to ensure all critical API access points are secured with end-to-end TLS.
- Enabling relevant kernel-level security controls like SELinux or Seccomp. These capabilities help to limit the attack surface on the node, thereby giving greater control over security of the entire system.
- Limiting direct access, e.g., Secure Shell (SSH) access, to Kubernetes nodes: Forcing all access to nodes via Kubernetes ensures proper access control and logging. This helps to reduce risk for unauthorized access to host resources.
- Follow industry best practices, such as CIS Docker Benchmark, to properly configure and harden the Linux nodes that run containers.
Container Image Security
The most important aspect of container image security is managing vulnerabilities. Because running containers with vulnerabilities exposes your system to attacks and compromises, you must actively manage the images used in your system to discover and remove known vulnerabilities.
A number of commercial and open source packages can perform container image scanning to discover known Common Vulnerabilities and Exposures (CVE) identifiers. The trick is not to stop at scanning. Rather, the scanning function should be integrated with runtime enforcement and remediation capabilities.
For runtime enforcement, consider a process that deploys only those images that pass vulnerability scanning and those that adhere to the organization’s hardening policies. Kubernetes provides mechanisms to exercise such enforcement policies.
For remediation, ensure that the vulnerability scanning and security assessment function is integrated with the organization’s continuous integration/continuous deployment (CI/CD) pipeline. This way, the scanning results are fed directly to the pipeline, thereby kicking off remediation workflows before deployment. This should, in turn, be integrated with Kubernetes’ rolling updates feature, ensuring vulnerable containers are taken offline and replaced with freshly built images without the known flaws.
Container Registry Management
Container registries are the source from which images come. You must manage which registries can be used by your organization to pull images because downloading images from unknown registries can lead to the proliferation of vulnerable and dangerous software.
Use private registries and approved images; that is, only scanned and vetted images can be pushed into your private registries. If you must use public registries, scan the images before deployment. If the security scanning process fails to clear the image, you must fail deployment as a result. That is the only way to ensure the hygiene of your container environment.
With a firm grasp of the threat models, four major tenets of Kubernetes security and, now, container security considerations, you’re ready to explore the four major tenets of Kubernetes deployment security in more depth.