5 things DevOps needs to do to secure containers

For security departments, adoption of containerization presents a multifaceted challenge.

secure containers

Can’t we all get along

Do deepening adoption and broader deployment of container technologies (from the likes of Docker, CoreOS and others) threaten to escalate into the latest skirmish between operations, developers and information security? Certainly, the potential exists to widen the rift, but in fact there is far more common ground than would initially suggest. Containerization introduces new infrastructure that operates dynamically and is open in nature, with more potential for cross-container activity. Containerization presents an almost unprecedented opportunity to embed security into the software delivery pipeline – rather than graft on security checks, container monitoring and policy for access controls as an afterthought.

Aqua’s CTO Amir Jerbi suggests some key things DevOps should know about securing containerized applications.

secure containers

Managing vulnerabilities in container images

Broad use of container images raises the stakes for vulnerability management – and compels organizations to take a fresh look at their current approach. Images are the basic building blocks for containers, and are easily pulled down by developers from a centralized registry to run containers in a highly automated, flexible process.

From a security and governance perspective, trusting the container image is a critical concern throughout the software development lifecycle. Ensuring that images are signed and originate from a trusted registry are solid security best practices. Still, keeping to those practices doesn’t resolve the core challenge: how can I vet and validate code that the images encapsulate?

secure containers

Continuous assessment

In containerized environments images are constantly added to the central registry or hub and containers running the images are spun up and taken down. Amplifying the scale of the problem is the relative ease with which images based on open source builds can be generated from Dockerfiles, for example, and especially as more ‘layers’ incorporated in the image. The more layers that are incorporated in the image build to speed up deployment, the greater the risk that a software component, including open source components, will find its way into production without being scanned, validated and patched if needed.

Unless the process of scanning images before they are even uploaded to registries is tightly managed, as opposed to the traditional approach of periodic scans, the door is opened to propagation of vulnerabilities.

secure containers

Reducing the container attack surface

Containerization has some specific structural and operational quirks that up the ante for reducing the attack surface. Although there is concern about the underlying shared kernel architecture of containers, attention has shifted beyond securing the host to ensuring standard configurations and container profiles.

Unlike virtualized environments, where a hypervisor serves as a point of control, any user or service with access to the kernel root account can see and access across all containers sharing the Linux kernel. Security teams can rely on proven approaches to harden kernels and hosts - but have far less mature and repeatable approaches to securing processes that are specific to container environment.

05 docker

More from Docker

Another example is the ability to bind the Docker daemon to Unix Docker access group or TCP port that allows containers to speak to each other but also has the effect of providing all users with root access. Open access to root reduces operational friction but is likely to have security departments fuming about violations of the least privilege access principle.

Resolving this inherent tension between isolation and the need for container communication, operations and development should take steps both to control the extent to which containers interact with each other internally, and limit the number of containers.

secure containers

Tightening user access control

Until fairly recently, root access to the Docker host was by default was an all-or-nothing proposition. Although constraining access to container host root account has consumed the most attention - and driven investment by Docker in new features in to systematically remove privileged access - the broader concern for security is enforcing access controls to privileged accounts and operations for the deployment pipeline. There are clear benefits for the broader organization for pragmatic and effective access controls: accountability and operational consistency. Accountability entails some ability to pinpoint who made changes to container settings or configurations, downloaded an image or started a container in production.

While root access may be the easiest way for developers, it can also mean that they have too much access. Also, an attacker who gains access to root account will have full access to the container, including its data and programs.

secure containers

Central management

Applying centrally managed constraints on what changes or commands a user can execute based on their role, rather than their ability to access the root account, enables organizations to define and enforce standard processes. Implementing separation of duty and privilege access and command constraints based on user role is a foundation for assurance through the software development lifecycle.

Without a centralized approach, it’s difficult to determine whether the different privileges defined for different users for each container are in fact appropriate and consistent with their functional role, and scoped in terms of least privilege access.

secure containers

Hardening the host: Security isolation

One of the key benefits of containerization is that it isolates an application and its dependencies into a self-contained unit that can run anywhere. A critical implication is that there are tools in place to constrain what the self-contained unit can and can’t access and consume. Control groups and namespaces are the key container isolation components: control groups define how much of the shared kernel and system resources a container can consume, while namespaces define what a container can ‘see’, or effectively which resources it is authorized to access. The design goals for these components is clear: where you want to run multiple services on a server, it is essential to security and stability that the services are as isolated from each other as possible.

The devil in the details, however, is ensuring that control groups and namespaces are appropriately and consistently configured, and that configurations are congruent with security policies.

secure containers

Slipping through the cracks?

While isolation can be an effective way to limit the potential for a container gaining access to kernel resources, it’s not as effective in isolating the container’s execution path. Resource isolation is also not effective for detecting or preventing escalation attacks that abuse privileges or break out of the container “sandbox”.

In the absence of a layered approach with effective (and pragmatic) controls and visibility for run-time defense and container profiling, there are plenty of ways in which containers can slip through the tracks through misconfiguration – or explicit actions by attackers through namespace manipulations. For instance, a denial-of-service attack on a containerized environment is not that dissimilar from a ‘rogue’ container consuming more kernel resources and crowding out other processes.

10 security

Automating the container security process

Nothing would make everyone involved happier than if security could be baked into containers as part of the way they are built, shipped and run - and this is also the best way of minimizing friction between the motivations of DevOps and those of IT security. Since security teams are often unaware of the processes that culminate in containers running in production, it is important to involve them in the definition of workflows and facilitate a knowledge transfer, so as to ensure that they are in a position to provide guidelines as to appropriate controls and practices they require to meet security standards and pass compliance audits.

11 assembly

What devops should do

DevOps, on the other hand, should do what they do best – automation. Using existing CI/CD tools and orchestration tools to embed image scanning, configuration controls, monitoring and other security measures into the container lifecycle from development through to production would make the security process transparent and relatively painless. While there will always be a need for additional security layers and oversight, but automation can bring the baseline up to a level where the additional effort would be minimized – thus reducing the risk of security acting as a barrier to deployment.

RELATED: 6 questions CISOs need to ask about containers

Copyright © 2017 IDG Communications, Inc.

Related Slideshows