Containers

Portable code execution

environments
Why: Need for speed

https://www.slideshare.net/adriancockcroft/dockercon-state-of-the-art-in-microservices
Why containers?

Business reasons
• enables microservices that scale flexibly
• standardised runnable units across environments DTAP
(Development to Production)
Technical advantages
• small memory footprint
• boot much quicker
 Containers versus VMs
A container runs natively on Linux
and shares the kernel of the host
machine with other containers. It
runs a discrete process, taking no
more memory than any other
executable, making it lightweight.

By contrast, a virtual machine (VM)

runs a full-blown “guest” operating
system with virtual access to host
resources through a hypervisor. In
The Host can run in a general, VMs provide an
VM or on bare metal environment with more resources
than most applications need.
From https://docs.docker.com/get-started/
Containers in a Continuous Integration pipeline

http://slidedeck.io/lodelestra-edu/docker-slides
 Container orchestration

Orchestration covers a
couple of topics that are
intrinsic in scaling up
Docker deployment.

Most popular orchestrator:

Kubernetes (K8s)
Originally Google, now Open
Source
 Containers and images
The container is the actual running unit. If it implements
a micro-service, it probably runs a webserver.
A Docker Image is like a traditional bootable image, but
with a twist.
Docker images contain ready to run pieces of software:
i.e. a Debian Linux kernel with an Apache webserver on it.
The twist is that they are read-only and layered on top of
another. If in the build process a running image is
changed, another layer is created that records those
changes. I.e. a child image is created without modifying
the base image. Only a running image (a container) will
have a writable filesystem.
Docker daemon and client
The Docker daemon runs on a Linux VM
(Virtual Machine) and starts up individual
containers. It can be controlled by API
(Application Program Interface), and in
the illustration, the API is accessed
through the Docker client. Together, the
daemon and client are often referred to
as the Docker Engine.
 (UAT = User Acceptance Test)

Registry and
repository

Containers images are stored in a repository. Repositories are stored in registries, which are services and
can be public or private.

From a risk perspective, hacking the repository (or registry) is an attack vector to introduce malign images
into customer environments.
Even a bona fide registry does not typically provide guarantees over the quality of the images.
The Docker hub is the public registry hosted by Docker Inc. holding many repositories.
Docker networking
Like virtual machines, containers share networking hardware and some
networking code with the hosts that they run on.
Like a hypervisor, the daemon implements specific networking functionality for
containers to communicate. This network functionality implements access control
and bandwidth isolation between containers. So, like with VMs, part of the network
is in the host and engine.
What is the implication of this on resource isolation and the implementation of
network controls? Where is QoS implemented and enforced? How would you audit
this?

When containers are to be connected across multiple hosts, overlay networks are
often used.
Summary
• Containers are a portable execution environment
• Controlled through the Docker daemon on a host machine
• Less isolation than VM
• Orchestrated
Container security
Docker security according to Adrian Mouat
See Adrian Mouat's post on O'Reilly: https://www.oreilly.com/ideas/five-security-concerns-
when-using-docker
• Exploits of the kernel on which the containers are running. I.e. can you crash that OS?
• Denial of service attacks of one container versus another running on the same host.
• Container breakout. If you are root on the container, after breakout you would be root on
the host.
• Poisoned images. How do you know the image is what it claims to be and is not rootkitted?
• Compromising secrets. Secure server to service communication requires passwords or
other credentials. How do you deploy these safely at speed and at scale?
More container control areas
• Image provenance and quality
• Management of credentials and secrets
• Resource management
• Isolation
• Governance and operations
Image provenance and quality
Image provenance and quality is about making sure you know that the
containers (running images) are not pwned or backdoored, and that
you know about the components and their vulnerabilities.
Example controls:
• Use only official images from a trusted registry or trusted parties or
that have been build locally
• Adequate management of developer and operations accounts and
their privileges
• Track upstream and composing image versions and vulnerabilities
• Scan images for vulnerabilities
Credentials and Secrets
Any complex IT system will have many collaborating parts, most of
which nowadays are provisioned automatically. This raises concerns
about the authentication methods and keys, as well as encryption
keys. How are these created, managed, distributed and destroyed?
Example controls:
• proper security architecture that limits exposure of secrets
• properly architecting key management and distribution services
• no hard wired secrets
• "search and destroy" policy for secrets leaking to registries
Resource management
Docker supports highly scalable environments. This has risks in two directions.
• Are enough resources provisioned to deliver any service level commitments?
• Is the cost of those resources in relation to the benefit they provide? I.e. is
overprovisioning limited?
• Resources include CPU, memory, bandwidth, but also software resources such
as port numbers and IP addresses.
Example controls
• Setting and enforcement of quotas on resources of containers, hosts, developer
teams, etcetera
• Measurement and monitoring
Isolation
Isolation is about the (lack of) separation between components, as well as isolating
components from bad guys. This could be about access, or about resource
consumption, for example. Links with resource management.
Isolation needs to be between containers, and between networks
Example controls:
• network segregation (hyper segregation)
• data at rest and in motion encryption
• harden containers and virtual machines
• policies that limit multi-tenancy on physical or virtual machines
 Governance and operations
Governance and operations is about policies and procedures. More and more, we
are seeing the integration of development and operations (DevOps), even with
security (DevSecOps). This requires a well tooled, and well organised team.
Example controls:
• proper tooling and automation of the development process
• proper contract and SLA (Service Level Agreement) management on external
service providers
• proper implementation of patching or update processes
• automation of testing procedures, including security assessments.
More resources
• Many vendors now have Docker
security tools, often agents: config
checks, software versions
• CIS Benchmark:
https://www.cisecurity.org/benchmark/
docker/
• CSA working group paper (includes
many risks and controls)
challenges-in-securing-application-containers-and-
microservices.pdf