DevOps is all about speed and agility. The whole point is to remove barriers and roadblocks to enable teams and individuals to streamline productivity. That speed can’t come at the expense of security, though. Organizations need to be able to find an effective balance between agility and security—operating as fast as possible while maintaining security at the same time.
When it comes to containers and containerized applications, the environment is even more dynamic and the number of containers can scale exponentially up or down in an instant. The challenge of effectively monitoring and managing security in a container environment—without significantly slowing productivity—is daunting.
As with most technologies, security was more or less an afterthought for containers. It wasn’t until containers achieved some mainstream traction that organizations started to consider the security implications. In the past couple of years, there have been a variety of concepts introduced to address container security. Microsoft, VMware, Intel and others have tried to develop containers that are more secure by essentially making each container its own virtual machine as well. There also exist container security solutions that either run as a kernel plugin or in privileged access—both of which require root access and create as many problems as they solve.
Privileged Security Containers
It’s great that container security is getting so much attention. However, organizations adopt containers for a reason, and it’s equally important that you don’t sacrifice the benefits of containers in the name of container security.
The privileged container approach delivers much of what you need from a container security solution. It can effectively detect, protect and respond to security issues in the container environment. However, as stated above, you lose the portability aspect of containers and limit your deployment options. If you ever choose to migrate to a container-as-a-service (CaaS), function-as-a-service (FaaS) or serverless computing platform, the privileged container model will break. You will be forced to re-architect your container security solution.
A Container-Native Approach
One of the primary promises of containers is that they are platform agnostic and portable. You should be able to take a containerized application to a container environment anywhere and run them. That isn’t possible if the container security solution relies on a platform-specific kernel plugin, or if it runs in privileged security containers that require root access to the underlying OS. That’s why a container-native solution—security that is built into the container itself—is a more viable approach to container security.
A blog post from Layered Insight explains, “The ultimate solution is embedding security within the container runtime. By making security part of the container runtime, organizations can accelerate the deployment of containers in production by removing the friction of security.”
Developers need to understand the composition of container images, be able to monitor communication across the microservices-based architecture and enforce business requirements for containerized applications. Security and operations need to understand the security and configuration issues of containerized applications, be able to monitor containers and be able to protect containerized applications in production.
An embedded, container-native approach gives both sides of the DevOps equation what they need. Running within the container itself, this approach provides accurate insight into container images, effective analysis of containers during runtime and the ability to automatically enforce policies and limit container behavior. More importantly, you have container security across the entire life cycle of the containers without sacrificing scalability or portability.