Anyone that’s ever owned a computer appreciates the power of standards. Haven’t you ever wished that you could somehow just have that one cable that plugs anything into your machine, so you have one less accessory to buy and keep track of? Let’s examine how standards around cloud technology like containers are making our lives easier, and as it turns out, more secure and interoperable.
The vast majority of enterprises are looking to enable their business with technology, not build a cloud platform themselves. Building your own platform is an incredible investment in R&D, assuming you can even attract the right talent. Many who have succeeded in both, still failed. For these enterprises, containers are a complex, nuanced conversation around a single component that a modern cloud native platform needs to deliver—for end users, it’s like having a detailed discussion about cables and dongles, instead of the computer itself.
However infrastructure must be proven before it can be relied on to “just work.” Cloud Foundry’s elastic runtime is a proven solution for container orchestration, scaling today to nearly 250,000 containers in a single cluster. This is reflective of the effort Pivotal has invested with de facto (container-related) standards like Buildpacks and Docker over many years. Security for containers has improved notably since 2014, in part due to collaboration around recent industry standards like OCI. So whether you are automating container construction with buildpacks, or using/forking/building Docker images, Cloud Foundry’s secure containerization is just part of a platform-wide security system that leads the industry in protecting your applications on the cloud.
Open Container Initiative (OCI)
Enter the OCI community in 2015. Pivotal was a founding member of the community, which collectively work on helpful standards around a container image format and runtime. The excitement around this stems from both users and members alike. Developers and operations benefit from portability for containerized applications. Members benefit from each other’s contributions without unnecessary reinvention, and have less work to do supporting multiple runtimes/formats, ultimately resulting in better and more secure products out in the market. In short, the commoditization of containers is great news for enterprises looking to enable their business with cloud technology.
OCI, Docker And Pivotal Cloud Foundry
Pivotal Cloud Foundry has been experimenting with containers since 2011, and running them in production since the initial commercial product launch in 2013—first with Warden, then Garden, and now Garden-runC. runC is the reference implementation of the Open Container runtime spec, and both Docker and Cloud Foundry run that same code: both Docker and Cloud Foundry apps are using Open Containers.
We are excited to replace the Garden-Linux runtime in Pivotal Cloud Foundry (PCF) 1.6+ with OCI’s runC container runtime. Garden-runC is now the default container runtime and improves both container security and interoperability. Garden-runC uses the same low-level container execution code as Docker for running containers, so that your container images run the same in PCF as elsewhere.
Ironically, security is one of the more exciting benefits inside what might otherwise be a boring bit of “it just works” commodity infrastructure.
AppArmor is a Mandatory Access Control System (MAC) that is part of the mainline linux kernel. Thanks to Docker’s AppArmor integration being contributed to OCI, AppArmor works great with runC. And since runC is now the default container runtime in Cloud Foundry, PCF users get AppArmor compatibility “for free.”
Generally regarded as easy to use, AppArmor focuses on programs, not users, restricting a given program’s access inside a container to system resources like network, disk, etc. Security administrators can use AppArmor to create enforcement policies that are simple to author and easy to audit. Without an easily auditable system, it’s quite possible to inadvertently introduce security loopholes in a policy that isn’t consistent with itself.
In Cloud Foundry, AppArmor is pre-configured with a default policy and enforced by default for all unprivileged containers. AppArmor can dramatically increase your default security posture!
Seccomp (Secure Computing Mode) is also part of the mainline linux kernel, and restricts the set of system calls a program inside a container can access. This sandbox greatly reduces the surface area for break-out exploits. Docker asserts in its documentation that their default seccomp profile disables around 44 system calls out of 300+. Whitelisting just the critical linux system functions for your program balances the needs of security and application compatibility, and provides a entry level of lockdown for containerized applications. In Pivotal Cloud Foundry 1.6+, this is set up out-of-the-box: we use the same Docker default seccomp profile to maximize compatibility with existing images. It’s like getting free beer in an open container!
It’s also worth noting that security administrators often use 3rd party tools like Grsecurity (or similar) to ensure security at the linux kernel level inside the container, since access control systems and sandboxes reside atop the kernel and LSM.
Unprivileged Containers On PCF
Unprivileged containers are a security technique of mapping the root user inside the container to a regular user at the linux operating system level that has no privileges. This prevents an application from inheriting root access on the host if it breaks out of the container. By using the full set of user-namespacing features in Linux, PCF isolates containers sharing the same host.
PCF also reduces the set of linux system capabilities for processes started inside a container using a variety of methods, including linux control groups (cgroups). PCF takes other steps to harden containers, even blocking all outbound network traffic by default, which can be overridden and/or fine tuned with an ASG (Application Security Group).
Limiting access to linux kernel functions in this manner nicely compliments tools like AppArmor and Seccomp by providing another layer of security, in case the others become compromised.
Secure By Default
While many of us would likely prefer that security “just works,” Cloud Foundry has achieved incredible success with this premise, shipping intelligent automation and default configurations for both security and infrastructure. The addition of AppArmor and Seccomp to PCF’s existing container security and platform security, together with practices like Rotate, Repave, and Repair, can combine for a dramatic improvement to your default security posture and operational security. Repaving VMs can happen every few hours without application downtime. Apps deployed from CI can do the same with containers, which now will have a greatly improved default security posture. And Cloud Foundry’s CVE turnaround time/ease of CVE rollout is unmatched in the industry.
Generally speaking, Pivotal first rolls out new software as-a-service on Pivotal Web Services (PWS) before shipping it to our Pivotal Cloud Foundry customers. In this case, we rolled out Garden-runC as the default container system to PWS in September and have been successfully operating it since then. We did this transparently and without the need for user intervention, confirming the stability that customers expect from PCF.
The new Garden-runC code base is simpler and more modular, allowing future work items beyond security—like pluggable container-to-container networking and pluggable rootfs management.
About the Author
Pieter Humphrey is a Product Marketing Manager responsible for Java Developer Marketing at Pivotal Software, Inc. Pieter comes from BEA/Oracle with long history of developer tools, Java EE, SOA, EAI, application server and other Java middleware as both a marketing guy and sales engineer since 1998. Find me on Twitter at https://www.twitter.com/pieterhumphrey.More Content by Pieter Humphrey