Professional Documents
Culture Documents
Security For Containers - 5 Things DevOps Need To Do PDF
Security For Containers - 5 Things DevOps Need To Do PDF
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:
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?
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.
4
have far less mature and repeatable approaches to securing processes
that are specific to container environment.
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.
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.
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”.
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.
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.
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.