Container Orchestration Demands a Security Focus
Containers and containerized applications running on cloud resources are delivering new levels of speed and efficiency to modern development teams. Containers are optimized for agile deployment and can be run in on-premises and virtualized infrastructures. They require less coordination and oversight than large, monolithic applications, and are simply more flexible. Automated, continuous integration and delivery pipelines help ensure code is appropriately tested and staged before being moved into production.
Using containers is decidedly advantageous, but it also creates new security challenges that security teams need to address. Certainly, the benefits of orchestration and automated deployment are huge for organizations that want to move fast and be responsive to business challenges, but these benefits must be balanced with recognition of the following:
Containers share the host OS that they run on, which is different than the way a virtual machine works. When configurations aren’t managed effectively, the host and containers both become vulnerable to security issues.
Containers do not operate in isolation, and they are not a true sandbox like a hypervisor is for virtual machines.
Orchestration automation adds a layer of complexity, which can result in misconfigurations that over-provision access and subsequently, an increased attack surface.
Images that are stored in publicly-available repositories are typically used to create containers. These images are usually dependent on other images, and when a vulnerability is detected in one, it can proliferate rapidly to any of (potentially) thousands of other containers.
Containers are ephemeral, so IP address-based security controls are less effective and make forensic investigations more difficult. Reuse of IP addresses also confuses traceability.
Orchestration and application acceleration
When a containerized application is pushed to a test environment, the CI/CD pipeline takes over. Orchestration can be complex, and care must be taken to not introduce new security vulnerabilities into the process. Therein lies the need for a different security model for containers.
Containerized applications can also be created as microservices to handle specific, and narrowly-focused tasks. A single microservice could fulfill search requests and another could update customer information records in a database. Containerized applications running as microservices can be easier to dynamically test, distribute, and deploy than their monolithic counterparts. Microservice architectures will result in many more unique containers that each must be managed and secured.
Containerized application security
Many of the security risks introduced by containerized applications and their supporting services and infrastructure can be discovered and mitigated or remediated through deep visibility into the organization’s environment, along with analysis of the security events. Through analysis of those security events that provide context and delivers details about behavioral anomalies, organizations can identify the issues in their orchestration processes and fix them before they do serious damage.
These recommendations are essential to avoiding container security vulnerabilities:
Configuration and vulnerability visibility: Extend your vulnerability management program to include your container technologies. Look for solutions that identify vulnerabilities in your host OS, container images, and the containers themselves using real-time analytical data collected across your infrastructure. Misconfigurations in container provisioning could result in a larger, more vulnerable surface area or allow untrusted access to trusted resources. Resources like the CIS Benchmark provide prescriptive security guidance for most operating systems and many applications including Docker and Kubernetes.
Only use trusted images: Containers are built from images stored on public or private repositories. Understand where your images are sourced and look for tools to scan these images for any vulnerabilities. Remember that one vulnerability in a single image will proliferate into every container based on that image.
Make default to least privilege a prime policy: Regularly audit and review root and other superuser access and remove privileged access from processes that do not require it. Docker containers are granted access to specific namespaces including network, processes, inter-process communications, file system mount points, and the kernel. Document and understand all shared access to these namespaces and look for instances of inappropriate privilege. An example would be mounting a container volume to the host OS /etc directory could result in a serious security vulnerability.
Build anomaly detection into your security discipline: Because of the highly dynamic and ephemeral nature of containerized environments, reading container logs won’t be enough. Analysis through machine learning, which can apply behavioral context is the most effective way to detect anomalies. This is the most accurate way of identifying issues and needs to become part of the security team’s standard operations.
Containerized applications deployed in the cloud make it easier for organizations to more quickly give needed services to their customers. There continue to be exciting advances in technologies that analyze behavior in real-time to monitor for and alert on misconfigurations and other vulnerabilities in cloud-based container infrastructures. Coupling these technologies with anomaly analysis and evolved security best practices will create the necessary threat detection, protection, and response controls essential to keeping these dynamic clouds secure.