Containers deliver many advantages over virtual machines, but they also have downsides. Simply put, containers do not actually contain. The lack of a hypervisor means that you don’t get full isolation in containers like you do with virtualization. Moreover, the dynamic and ephemeral nature of containers brings an onslaught of new runtime complexities to manage.
All of the above adds up to new security challenges when working with containers, especially when it comes to runtime security. In this post, I’ll identify and discuss some common runtime security challenges that can arise with containerized applications.
Threats to Container Runtime Security
Even though the attack surface has changed with the shift to containers, the common threats are not new, just modified. Some well-known vulnerabilities that need to be watched out for include port scanning (which gives a better understanding of what services are exposed and provide further opportunities for movement), hijacked processes, data exfiltration, backdoor administrative accounts and SSH access (which can be used to plant malicious software, providing ongoing access to the container), network lateral movement, brute force attacks, etc.
Some new vulnerabilities include compromised containers that attempt to download malware or scan internal systems for weaknesses, containers being forced to use system resources to compromise other containers (DoS attacks), containers breaking out and gaining unauthorized access across other containers and/or the host and data center (through privilege escalation attacks).
Container Runtime Security Improvements
Container runtime security is an ongoing process and requires continuous work. The strategies you adopt should be container-aware (preferably container-native), seamless, and should operate in the same manner as the containerized applications (which means that they should be automated and be able to scale on demand). The following are some important precautions to take.
8 Hacks to Improve Container Runtime Security Improvements:
Limit the Attack Surface
Less software means less risk. Reduce images to create a smaller attack surface and limit unnecessary modules and dependencies. Create security profiles with seccomp to sandbox code. You can build a list of system calls that are allowed to be called in the container and limit processes within it to dictate from the beginning what a container can or cannot do. Use AppArmor or SELinux for more advanced features and to enable stricter rules.
Harden the Host OS
Run stronger kernels and update them often. If you run a kernel with GRSEC and PAX, this will add many safety checks, both at compile-time and run-time. Use distros that are tailored to run containers (CoreOS, Red Hat Atomic Host, RancherOS, etc). Be diligent about applying the latest security patches and test your host OS against security benchmarks.
Manage Container Builds
Scan images for known vulnerabilities and integrate security testing into the build process. Use automation to detect builds with issues and to trigger rebuilds.
Harden Container Images
Run integrity checks on container images. Digitally sign images at build time to ensure that the code running in a container is what was originally supplied or is from the source it claims to be from. Always try to use trusted sources.
Enable User Namespacing
The user namespace allows users within containers to be mapped to other users in the host system. Map the root user in the container to a high-numbered user on the host so that it cannot do much damage should there be a container breakout.
Mount as Read-Only
Facilitate immutable infrastructure (and improve scalability in the process) by making the whole container read-only, if possible.
Constantly Monitor and Protect the Runtime Environment
Establish normal application behavior and then enact security policies based on that (i.e. prevent deployment if a container requires root access). Monitor every container for anomalies and the image registry to automatically replace affected images. Perform live scans of running containers and hosts and block activity when something deviates. Store data on all security events and perform analysis to determine the root cause and prevent future attacks.
Integrate with Enterprise Security Tools
Consider leveraging enterprise security tools to further enhance runtime security. For example, Twistlock Runtime Defense uses machine learning to predict runtime behavior of containers and hosts. Twistlock also offers comprehensive vulnerability scanning that will scan your images and compare against current CVE data, which gives you good coverage against new threats.
Although containers bring a set of new unique runtime security challenges, their nature also enables better protection for your applications. Since containers are typically stateless and easily replaceable, it is easier to patch any issues and deploy a new version across the deployment chain, allowing you to react quickly to security issues.
As containers become more popular and change the way we build applications, we also need to alter the traditional security mindset. It is vital to embed security early in the process and to establish automated security tooling early in the pipeline. Instead of creating security measures as a final step before code deployment, security needs to be ingrained into every step of the development pipeline.
Related Container Security Posts:
Follow us on Twitter
Follow us on Twitter for real time updates on the cloud native ecosystem, Twistlock product, and cloud native security threats.
IAM Roundup: AWS vs. Azure vs. GCPRead the Blog
How to Securely Configure a Linux Host for ContainersRead the Blog
Don’t Forget the Audit Trail! The Role of Reporting in SecurityRead the Blog
Securing Cloud Native Applications on Pivotal Container Service (PKS)Read the Blog
What to Know: Gartner’s Security Considerations and Best Practices for Securing Serverless PaaSRead the Blog