Container Lockdown!

Reading Time: 4 minutes

If you are working in the information technology sector and your organization is moving towards the Cloud and/or your application development team is using Agile development, then you will inevitably encounter application containers (or simply “containers”).  As an information security professional, I not only have to understand the technology and processes but I also have to know how to ensure security is integrated.   My first stop to learn about security best practices and benchmarks are the National Institute of Standards and Technology (NIST) Special Publication 800 Series (https://csrc.nist.gov/publications/sp) and the Center for Internet Security Benchmarks (https://www.cisecurity.org/cis-benchmarks/). 

NIST Special Publication 800-190 Application Container Security Guide (link https://doi.org/10.6028/NIST.SP.800-190) provides recommendations organizations should follow to help ensure the security of their container technology implementations and usage.  This is a well written document that covers basic concepts for application virtualization and containers and container technology architecture, major risks for container technologies components, countermeasures for major risks, container threat scenario examples, and container technology life cycle security considerations.  It is a lot of useful information but I needed a shortlist of security recommendations derived from this document to discuss with management, developers, and operational team members.  Thus I created this Container Cheat Sheet.  Please use this for reference purposes only.  Always refer back to the source document when performing an assessment or creating a [container technology] policy.

First thing, let’s provide a bit of background information.

What is a container?

According to mapr.com, an application container is “a stand-alone, all-in-one package for a software applicationContainers include the application binaries, plus the software dependencies and the hardware requirements needed to run, all wrapped up into an independent, self-contained unit.”

What are the five tiers of the container technology architecture?

According to NIST SP 800-190, the five tiers of the container technology architecture are:

  1. Developer systems (generate images and send them to testing and accreditation)
  2. Testing and accreditation systems (validate and verify the contents of images, sign images, and send images to the registry)
  3. Registries (store images and distribute images to the orchestrator upon request)
  4. Orchestrators (convert images into containers and deploy containers to hosts)
  5. Hosts (run and stop containers as directed by the orchestrator)
Five Tiers of Container Technology Architecture courtesy of NIST

Container Security Cheat Sheet

The recommendations identified in this cheat sheet come verbatim from National Institute of Standards and Technology (NIST) Special Publication 800-190 Application Container Security Guide and is meant to be used as a reference and not a replacement for reading NIST SP 800-190.

Image Security Recommendations

  • Integrate security tools with the entire lifecycle of images, from the beginning of the build process, to whatever registries the organization is using, to runtime.
  • Implement security tools that provide visibility into vulnerabilities at all layers of the image (i.e., base layer, application framework, custom software).
  • Implement policy-driven enforcement at each stage of the build and deployment process to ensure that only image that meet the organization’s vulnerability and configuration policies are allowed to progress.
  • Never enable SSH and other remote administration tools designed to provide remote shells to hosts within containers.
  • Use base layer images from trusted sources only.
  • Images should be configured to run as non-privileged users.
  • Secrets should be stored outside of images and provided dynamically at runtime, as needed, using an orchestrator.
  • Encrypt secrets at rest and in transit using Federal Information Processing Standard (FIPS) 140 approved cryptographic algorithms.
  • Maintain a set of trusted images and registries and ensure that only images from this set are allowed to run in their environment.
  • Centrally control what images and registries are trusted in the environment.
  • Identify each image by cryptographic signature, using a NIST-validated implementation.
  • Validate image signatures before image execution to ensure images are from the trusted sources and have not been tampered with.

Sample images: Alpine Linux, Windows Nano Server Sample Runtimes: Docker, rkt, Open Container Initiative Daemon

Registry Recommendations

  • Configure development tools, orchestrators, and container runtimes to only connect to registries over encrypted channels.
  • Images should be scanned for vulnerabilities and compliance before being pushed to a registry.
  • Automatically prune registries of unsafe, vulnerable images that should no longer be used.
  • All access to registries should require authentication.
  • All write access to registries should be audited and any read actions for sensitive images should be similarly be logged.

Sample Registries: Amazon EC2 Container Registry, Docker Hub, Docker Trusted Registry, Quay Container Registry

Orchestrator Recommendations

  • Orchestrators should use a least privilege access model.
  • Developers should have limited or no access to containers used in production.
  • Organizations should use strong authentication methods such as multifactor authentication
  • Organizations should use single sign-on to existing directory systems where applicable,
  • Orchestrators should be configured to separate network traffic into discrete virtual networks by sensitivity level.
  • Define rules that prevent high sensitivity workloads from being placed on the same host as those running lower sensitivity workloads using host pinning
  • Segment containers by purpose, sensitivity, and threat posture
  • Orchestrators should ensure the nodes are securely introduced to the cluster, have a persistent identity throughout their lifecycle, and can also provide an accurate inventory of nodes and their connectivity states
  • Orchestrators should provide mutually authenticated network connections between cluster members and end-to-end encryption of intra-cluster traffic.

Sample Orchestrators: Kubernetes, Mesos, Docker Swarm

Container Recommendations

  • Deploy and use a dedicated container security solution capable of preventing, detecting, and responding to threats aimed at container runtime.
  • Container runtime must be monitored for vulnerabilities, and when problems are detected, they must be remediated quickly.
  • Group containers with the same purpose, sensitivity, and threat posture on a single host OS kernel
  • Organizations should control the egress network traffic sent by containers to ensure they are not able to send traffic across networks of differing sensitivity levels.
  • Organizations should implement app-aware tools to see the inter-container traffic and dynamically generate rules used to filter this traffic.
  • Organizations should automate compliance with container runtime configuration standards (see Center for Internet Security Docker Benchmark)
  • Containers should be run with their root filesystems in read-only mode
  • Containers should rarely make changes to the host OS file system and should almost never make changes to locations that control the basic functionality of the host OS (e.g., /hoot, /etc, C\Windows).
  • Organizations should institute separate environments for development, test, production, and other scenarios, each with specific controls to provide role-based access control for container deployment and management activities.

Host OS Recommendations

  • Use container-specific host OSs. 
  • Hosts should be continuously scanned for vulnerabilities and updates applied.
  • Host OSs should be operated in an immutable manner with no data or state stored uniquely and persistently on the host and no application-level dependencies provided by the host.
  • All authentication to the OS is audited, login anomalies are monitored, and any escalation to perform privileged operations is logged.
  • Ensure that containers are run with the minimal set of file system permissions required.

What do you think? Do you have anything to add?

Leave a Reply

2 comments

  1. Containers are a big topic of discussion across multiple swim lanes and this is a good reminder than security is of paramount importance. Integrate security from the beginning to ensure final success.

  2. AffiliateLabz

    Great content! Super high-quality! Keep it up! 🙂