Containers and Kubernetes have revolutionized many aspects of developing, deploying and scaling applications and infrastructure. Containerized architectures enable developers to focus on what they do best: developing applications.
These architectures lessen the burden on developers by eliminating the task of incorporating details about the runtime environment. Containerized solutions allow the developer to build once and run anywhere. The developer does not have to adapt applications to run on Azure, AWS, on-premises or any combination of possible environments.
At the same time, security challenges for the solutions themselves have not gone away. While containerized architectures remove many environmental details from developers’ responsibilities and allow freedom of choice in cloud platforms, they can complicate security by creating a broader attack surface.
When you use a cloud platform, you rely on their infrastructure being secure. However, you still need to address additional vulnerabilities from oversights in developing and deploying your containers and applications. You are still responsible for what you put in place and configure in the cloud.
To mitigate this, you must be aware of and address security concerns at each step in the container lifecycle. Addressing each of these four areas helps guard your containers against attack.
Admission Controller Security
An admission controller reviews requests to the Kubernetes API server. This takes place after a request has been authenticated and authorized but before an object is allowed to persist. The Kubernetes admission controller governs how the cluster is configured and used.
Admission controllers address questions such as:
- Is a pod requesting a “reasonable” number of resources?
- Are the images used to create microservice pods secure?
- Are deployment priorities being followed?
- Which privileges are granted to which deployments? Do they adhere to principles such as the least privilege to do the job?
You can configure the admissions controller to stop deployments from being exercised. Loosely set policies can cause vulnerabilities, and the admissions controller allows you to detect vulnerabilities and create and enforce policies to run only compliant containers.
Image Layer and Registry Scanning
Containerized solutions are easy to deploy to various environments and situations. But with a containerized solution, any vulnerability packaged inside the container image is exploitable across all running instances. Scanning and detecting policy violations or malware within your existing containers should be a significant part of your security operations.
"Frequent scans are especially important when patching and updating existing containers"
To safeguard against these issues, continuously scan all existing containers to ensure they conform to security policies. Frequent scans are especially important when patching and updating existing containers. Scanning existing images can detect malware or sensitive data, such as API keys and passwords, within the image.
You may need to customize your scans based on the container’s use. Creating advanced security policies enables you to customize enforcement based on a system of names and tags associated with a given container.
Shift Left: Early-Stage Scanning
The key to creating a secure container environment is to start at the beginning — that is, shift left in your development pipeline. Whether you are looking at a continuous integration and delivery (CI/CD) pipeline or something else, the earlier you implement security practices, the easier it is to prevent vulnerabilities from being packaged into containers.
When it comes to container image scanning, if you can integrate into the CI/CD pipeline and perform the layer-based scanning when the container image is built, you can prevent vulnerabilities, malware or sensitive information from being wrapped inside your container image. You can also prevent that image from being shipped to your container registry.
This saves your organization time, money and headaches. Since you can integrate with your source repository and CI/CD tooling, you can trace accountability back to the developer who introduced the vulnerability. It is a lot easier to fix issues in the build pipeline before runtime.
Container Runtime Security
While creating an environment that prevents security risks from becoming a reality is paramount, monitoring containerized applications at runtime is still essential. Runtime protection involves monitoring every cluster for all containerized applications running in each node. Monitoring might involve:
- Detecting disallowed commands
- Detecting attempts to access files illegally
- Building runtime models and monitoring for deviations
- Tracking management tasks and policy adherence
- Reporting and analyzing Kubernetes deployments and actions
While containerization increases application deployment speed, it opens up a new range of security risks. The cloud provider mitigates some of these risks, while you must address others during the development cycle.
End-to-end container lifecycle security is key to mitigating these risks. When deploying containers, focus on the admission controller, conduct image layer and registry scanning as far left as possible and continue implementing runtime security. Tools that enable you to incorporate and automate all these security capabilities can save considerable time for the organization.
