eBook

Security for Containers –

5 Things DevOps
Need to Do
Introduction
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 far there is far
more common ground than would initially suggest.

For security departments, adoption of containerization presents a multi-

faceted challenge:

Containerization introduces new infrastructure that operates dynamically

and is open in nature, with more potential for cross-container activity.

•• Containerization introduces new processes that move code through the

software development pipeline at an accelerated pace and with greater
flexibility (or, less oversight).
•• Containerization introduces new identities accessing resources in the
form of developers and IT operations that may have immediate effect on
runtime environments.

From a delivery perspective, these are all elements that contribute to

reducing the time to deployment time, application resource footprint and
collapsing the friction between operations and development.

Dev Test Run

Scan for image Image change Monitor container
vulnerabilities mgmt. behavior
User access control Harden the host Detect/prevent
config. intrusion
User access control User access control

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.

2
In fact, investments in visibility and control can result in improved
organizational accountability for stability and change management, better
application performance monitoring and higher levels of automation.
For instance, a targeted denial of service attack (or a poorly configured
container) where one container starves other containers of shared kernel
resources impacts availability as much as security. Rather than pit
security, application delivery and operational teams against each other
when the emphasis is on flexibility and time to delivery, there is plenty of
scope to make this a collaborative effort that minimizes disruption.

To make the most of the benefits that containers offer while ensuring the
security of the containers and their contents, DevOps can do part of the
heavy lifting early on and prevent subsequent roadblocks.

Here are five key things DevOps should know about securing
containerized applications:

1. Managing Vulnerabilities in Container Images

2. Reducing the Container Attack Surface
3. Tightening User Access Control
4. Hardening the Host
5. Automating the Entire Process

1. 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.

3
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?

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.
In the absence of continuous vulnerability assessment and remediation
implemented as an integral part of risk and governance programs,
containerization initiatives can be set back or even shelved.

2. Reducing the Container Attack Surface

Reducing the attack surface is a basic tenet of security. In fact, by avoiding
letting code that has vulnerabilities into our environment we are doing
exactly that. However, containerization has some specific structural and
operational quirks that up the ante for reducing the attack surface.

Although there is concern in security circles 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

4
have far less mature and repeatable approaches to securing processes
that are specific to container environment.

Many of these processes are intrinsic to containerization – such as the

container itself relies on the kernel as well as the Docker daemon for
a range of services accessed via system calls. While Docker has made
significant improvements in the ability to invoke out of the box Seccomp
profiles, these profiles only disable 44 system calls by default, out of an
available 313, leaving some 270 system calls open.

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 that are accessible to
Docker groups through sockets or open ports.

3. Tightening User Access Control

Until fairly recently, root access to the Docker host was by default was
an all or nothing proposition – generating plenty of anxiety for security
professionals. 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

5
container in production. With generic root access in place, identifying
who made changes is practically impossible. While root access may be
the easiest way of providing access and giving developers the access
they need to get the job done, 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.

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.

4. 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

6
configurations are congruent with security policies.

While isolation can be 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.

5. 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.

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.

7
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.

Want to Learn More?

See how Aqua’s container security platform provides
Download Whitepaper
multiple layers of protection for containerized
applications, using scalable, automated security
policy enforcement. Download our whitepaper or
Request a Demo
request a live demo.

About Aqua
Aqua enables enterprises to secure their virtual container environments
from development to production, accelerating container adoption and
bridging the gap between DevOps and IT security.

Aqua’s Container Security Platform provides full visibility into container

activity, allowing organizations to detect and prevent suspicious activity
and attacks, providing transparent, automated security while helping to
enforce policy and simplify regulatory compliance.