Security Pattern – Container Platform

Overview

The following security pattern describes controls required to protect applications hosted within containers and the underlying platform.

With the growing popularity of microservices architecture, the use of containers has also grown. Containers provide a platform for separating microservices applications into isolated environments and decoupled them from the host operating system.

Docker remains the most popular vendor for containerisation, however there are notable alternatives such as Rocket where this pattern can also be applied. Use of containerisation brings new security challenges, as summarised below.

Typical challenges

Containers use a shared OS model. An attack on a vulnerability within the host OS could lead to a compromise of all containers. Missing system and kernel patches are the greatest source of risk.
Maintaining and monitoring isolation between containers becomes more difficult, given containers have short life span and are updated more frequently.
Managing network micro-segmentation between containers, particularly container-to-container traffic within same host, becomes more complex given increase data traffic and additional network and access control.

Scope

The scope of this document is for addressing the security threats that relate to

ID	Description	Example
01	Hosting of microservice applications within containers	Docker platform hosted within cloud provider such as AWS Faregate or Azure Containers.

Out of Scope

ID	Description of exclusion	Reason for Exclusion
01	Hosting of databases or data storage within containers	Separate consideration to implications of persistent storage, data replications and or data loss.
02	Multi-host container orchestration	Separate consideration to use of container orchestration services and tooling such as Kubernetes or Docker Swarm. Documented under separate security pattern.
03	Service discovery for multi-host containers	Separate considerations to use of service mesh’s and or service discovery tooling such as Hashicorp Consul or AWS Service Mesh.

Dependencies

ID	Description	Impact from dependency not met
01	Summarised security design principles outlined under Jericho Forum® Commandments. https://publications.opengroup.org/w124	Minimal impact as these principles are used as an example set of baseline requirements within security pattern.

Constraints

ID	Description	Impact from constraint
01

Assumptions

ID	Description	Impact if assumption is false
01

Assets at Risk

The following section provides a list of assets affected by the problem statement:

Asset Title	Asset Description
Application Container	Package and run a single application service performing a discreet function, built upon baseline container image.
Container Engine	Container daemon operating within host machine to manage application containers. Utilises operating system resources to segregate and isolate application containers.
Container Host Operating System	Operating system environment (physical or virtual) which manages allocated system resources (CPU, Memory, Storage and Network) to Container Engine.
Container Image Registry	Software artifact registry used to maintain and store container images. This assess represents private hosted container image registry (as opposed to external public such as Docker Hub).
Container Image Build	Tooling and associated workflows for building and compiling container images. These images are stored within Container Image Registry and utilise for build of baseline container images used by Application Containers.

The following assets are also referenced within the pattern but not in scope

External Public Image Repository – Publicly available container image registry hosting 3^rd party container images.
Enterprise Certificate Authority – Required for issuing digital certificates to Application Containers
Source Code Management – Used for maintaining code and configuration for container image builds. Documented under separate security pattern

Threat Model

The following section provides a list of threats within the problem statement:

Threat Event (ID / Title)	Threat Description and Characteristics	Diagram
TE-27: Exploit hardware or platform vulnerabilities	Vulnerabilities in the host operating system platform could lead to a compromise of containers. Containers utilise shared host OS resources with limited isolation between hosted containers and the host operating system. Host operating system maybe exploitable through kernel vulnerabilities or shared system resources allowing privilege escalation.
TE-28: Infection from malware, worms or trojans	Insecure container images may contain malicious code or malware that can subsequently compromise application services hosted within that container. These weaknesses maybe due to out-of-date patching for container images or within application software.
TE-34: Violate isolation in multi-tenant environment	Exploitation of a vulnerability in a single container could lead to container breakouts and compromise of other co-hosted containers. Containers on same host utilise shared OS resources with limited isolation from container to container. Containers maybe exploitable through shared kernel and memory vulnerabilities, allowing attackers to move laterally.
TE-42: Denial of service on hosting platform or system services	Excessive resource usage from a rouge or compromised container could lead to a denial of service attack of other containers. Containers on same host utilise shared OS resources with limited isolation from container to container. Containers may exhaust allocated system resources on the host operating system to perform a denial of service to other hosted containers hosted.

Target State Solution

Summary

The target state solution evaluates the following design requirements to provide the expected target state solution and design principles.

Design Requirements

The target state solution is required to meet the following requirements, as referenced under Dependencies, Assumption and Constraints.

Requirement	Implication to Design Principles
1. The scope and level of protection should be specific and appropriate to the asset at risk.	Container Platform protects all hosted containers.
2. Security mechanisms must be pervasive, simple, scalable, and easy to manage.	The security pattern maintains clear security principles to be applied for container platforms.
3. Assume context at your peril.	Controls defined in this security pattern are used to identify and measure problems, limitations or issues
4. Devices and applications must communicate using open, secure protocols.	Open and encrypted communication channels such as HTTPS are applied for interfaces to container platform services
5. All devices must be capable of maintaining their security policy on an un-trusted network.	Container Platform is protected against both external and internal threats.
6. All people, processes, and technology must have declared and transparent levels of trust for any transaction to take place.	Validate and assess all container images before deployment. Block container images from deployment where assessment has not be performed.
7. Mutual trust assurance levels must be determinable.	Maintain digital signatures for container images once built and validated through CI/CD pipeline.
8. Authentication, authorization, and accountability must interoperate/exchange outside of your locus/area of control.	Apply authentication and authorization for both internal, partner and public clients.
9. Access to data should be controlled by security attributes of the data itself.	Utilise secrets management to protect secrets or sensitive information required during container deployment
10. Data privacy (and security of any asset of sufficiently high value) requires a segregation of duties/privileges.	Utilise secrets management for securing sensitive data or credentials.
11. By default, data must be appropriately secured when stored, in transit, and in use.	Protect containers both during build and deployment phases.

Solution Overview

The following represents the assets for containers across different trust domain and interactions between them during build and deployment.

Additional Notes

Application Containers and baseline container images are hardened and with minimal footprints to reduce attack surfaces and potential for vulnerabilities to be introduced.
The integrity and non-repudiation of workflow processes used for the build of container images or Application Containers are protected from both external and malicious insider threats.
Secrets or sensitive information required by Application Containers are injected during container deployment or run-time. Secrets are not be coded within configuration files or builds artifacts that are stored container image register or source code management.

Container images are then deployed to the Container Platform under the following model

Additional Notes

Microservice applications hosted within containers typically rely heavily on APIs to communicate with each other, which produces increased number of network traffic sessions. Ensure network architecture is designed to cater for microservices and secure connectivity for both inter and intra container to container traffic across hosts.
The scaling and lifecycle of Application Containers being deployed is managed by Container Engine based on configuration specified. The integrity of these configurations are maintained to avoid manipulation.
Application Containers have their own unique digital identity established for authentication and authorisation.
Application Containers should establish mutual trust for inter container-to-container communications or intra communications to other hosts where supported.

Related security patterns

Source Code Management
Container Orchestration

Design Principles

The following design principles are applied for this pattern, based on the requirements.

Prefer minimal base images for Application Containers.
Digitally sign and verify container images during deployment to mitigate man in the middle attacks.
Apply least privilege for Application Containers within platform.
Monitor and audit Application Containers activity within platform.
Implement limits on the system resources that the Application Containers can consume.
Scan and remediate vulnerabilities identified within container images.
Remove secrets from code and configuration files used for container images.

Actors

List the actors involved in this pattern.

Actor Type	Actor Description
Container Platform Administrator	Responsible for management and administration of Container Engines and Container Host Operating System.
Application Developer	Design, build and deployment of microservice applications within Application Containers.

Locations

This pattern is applied to any locations for assets being utilised

Location	Location Description
Container Platform	Container platforms maybe hosted within on-premise datacentres or cloud providers. Cloud providers such as Azure, AWS and GCP also provide Platform-as -a-Service (PaaS) offerings for container hosting platforms.

Sequencing

The pattern is designed within the following sequences

Stage gate	Description
Container Base Image Build	Baseline container images are built and maintained within container image repository. These images may alspo be built upon a vendor supplied image (e.g. standard Windows or Linux Container image)
Application Container Build	Containers are built from baseline image and packaged with relevant binaries or libraries for the application microservice.
Application Container Deployment	Container are deployed into the target environments. Configuration parameters or variables are used for packaging the container and deployment into different environments (Dev, Test, Prod)
Application Container Run Time	Containers may be destroyed and redeployed pending container lifecycle policy or container heath checks. This can be determined by either the Container Engine and/or Container Orchestration (used for clustering of multiple Container Engines deployed across different hosts)

Mapping Threats to Controls

The following provides a mapping of security threats to affected assets and the security control objectives required to mitigate them (further detailed in subsequent security pattern logical designs).

Threat Event	Affects Assets	Security Controls Objectives
TE-27: Exploit hardware or platform vulnerabilities	Container Host Operating System	AC-03: Access Enforcement AU-03: Content of Audit Records CM-02: Baseline Configuration CM-06: Configuration Settings CM-07: Least Functionality RA-02: Security Categorization SC-03: Security Function Isolation SC-06: Resource Availability SI-03: Malicious Code Protection SI-07: Software, Firmware, and Information Integrity
TE-28: Infection from malware, worms or trojans	Container Image Registry Container Image Build	AC-06: Least Privilege AC-20: Use of External Systems AU-03: Content of Audit Records AU-10: Non-repudiation CM-08: System Component Inventory CP-10: System Recovery and Reconstitution RA-05: Vulnerability Monitoring and Scanning SA-03: System Development Life Cycle SA-06: Software Usage Restrictions SA-13: Trustworthiness SA-19: Component Authenticity SC-35: External Malicious Code Identification SI-03: Malicious Code Protection SR-03: Supply Chain Controls and Processes
TE-34: Violate isolation in multi-tenant environment	Application Containers Container Engine	AC-03: Access Enforcement AU-03: Content of Audit Records CM-02: Baseline Configuration CM-06: Configuration Settings RA-02: Security Categorization SA-06: Software Usage Restrictions SC-03: Security Function Isolation SC-08: Transmission Confidentiality and Integrity SC-17: Public Key Infrastructure Certificates SC-50: Software-enforced Separation and Policy Enforcement SI-03: Malicious Code Protection SI-14: Non-persistence
TE-42: Denial of service on hosting platform or system services.	Container Engine Container Host Operating System	AC-06: Least Privilege AU-03: Content of Audit Records SC-05: Denial of Service Protection SC-27: Platform-independent Applications SC-32: System Partitioning SC-50: Software-enforced Separation and Policy Enforcement

Security Pattern

Pattern View: Containers

The following list of logical patterns provide the security control objectives, as they are applied to the assets being protected.

Control list: Application Containers

Control Objective	Control Description
AC-03: Access Enforcement	Access to containers is through approved connectivity channels. Direct access to Application Containers via SSH is disabled.
AU-03: Content of Audit Records	Container generates audit records for the following events: Application start-up and shutdown Application failures and restarts Modification of application parameters and/or configuration
CM-02: Baseline Configuration	Containers operates using standard and approved images from trusted Container Image Registry. Use of private registries maintaining approved images and versions. This includes vendor images, which are copied or synchronised to private registry to allow for security scanning and inspection.
CM-06: Configuration Settings	Containers use hardened images which configures the security settings to the most restrictive mode consistent with operational requirements.
RA-02: Security Categorization	Logical separation of containers onto different host operating systems for containers pending security categorisation and levels of trust.
SA-06: Software Usage Restrictions	Minimise permitted application and services permitted to operate within container.
SC-03: Security Function Isolation	Containers utilise secrets management for securing the transmission of sensitive security parameters or credentials. Secrets are accessible by the application or service within the container, only if it has been granted explicit access.
SC-08: Transmission Confidentiality and Integrity	Containers ensure confidentiality of transmissions through HTTPS.
SC-17: Public Key Infrastructure Certificates	Containers assert their identity using unique assigned digital certificate, issued from approved certificate authority.
SI-03: Malicious Code Protection	Container writeable file system and executables are inspected by vulnerability scanning or malware protection solution. Upon detection, containers are moved into isolation and quarantine to allow subsequent removal of malware or malicious code.
SI-14: Non-persistence	Containers are designed as non-persistent and immutable, to allow creation, updating, and deletion as required.

Control list: Container Engine

Control Objective	Control Description
AC-03: Access Enforcement	Leverage a trusted authentication services (LDAP/AD) for access to Container Engine. Container Engine ensures all login sessions from Container Host Operating System to the Application Container are authenticated.
AC-06: Least Privilege	Container Engine utilises dedicated user and or groups with restricted permissions for execution of Application Containers. Blocks containers attempting to operate under default 'root' permissions. Enforce least privilege for running containers and deny containers from acquiring new privileges during execution.
AU-03: Content of Audit Records	Container Engine generates audit records for the following events: Application Container start-up and stop Container Engine service start-up and stop Access or modifications to Container Engine settings Access or modifications to Application Container parameters and configuration files Successful and unsuccessful verification for digital signatures of container images.
CM-02: Baseline Configuration	Container Engine configuration is hardened, in-line with industry best practises (such as CIS benchmarks).
CM-06: Configuration Settings	Container Engine security settings are configured to the most restrictive mode consistent with operational requirements.
SA-06: Software Usage Restrictions	Configured to only run signed images. Fetch, verify, validate signatures.
SC-03: Security Function Isolation	Container Engine administrative commands, settings and parameters aer isolated from application containers and non-administrative users.
SC-05: Denial of Service Protection	Restrict allocation of host operating system resources to application containers to protect against or limit the effects of a denial of service attack.
SC-06: Resource Availability	Implement limits on the system resources that the containers can consume. Specify the amount of memory and CPU required for Application Containers to operate, instead of relying on an arbitrary amount.
SC-08: Transmission Confidentiality and Integrity	Communication channels to the Container Engine are encrypted.
SC-17: Public Key Infrastructure Certificates	Communication channels to Container Engine are protected using digital certificates from trusted certificate authority.
SC-27: Platform-independent Applications	Restrict Application Containers from mounting sensitive host system directories. Restrict access to host namespaces or directly binding to host networking services.
SC-32: System Partitioning	Utilise separate system partitions within host operating system (storage or network) for system resources being directly consumed by Application Containers.
SC-50: Software-enforced Separation and Policy Enforcement	Container Engine verifies container image fingerprint signature during boot to verify the integrity of the image and that is has not been tampered with.

Control list: Container Host Operating System

Control Objective	Control Description
AC-03: Access Enforcement	Container Host Operating System enforces assigned authorisations for controlling access to containers from the host operating system.
AC-06: Least Privilege	Restrict privileges assigned to Container Engine where supported.
AU-03: Content of Audit Records	Host operating system generates audit records for the following events: Logon to and logoff from any user account Any generic logon and logoff by users to any accounts including but not limited to any system applications Failed logon attempts Account lockouts Account privilege escalation Failed attempts to access data and system resources Successful and failed attempts to use special privileges System or service failures, restarts or shutdowns
CM-02: Baseline Configuration	Container Host Operating System security settings are standardised and use an approved baseline. Security settings are configured to the most restrictive mode consistent with operational requirements.
CM-06: Configuration Settings	Secure all files and directories used by Container Engine by ensuring they are owned by the appropriate user and their file permissions are set to a restrictive value.
CM-07: Least Functionality	Container Host Operating System operates with only minimal services and toolsets required for hosting Container Engine and Application Containers. Where possible, utilise purpose built operating systems designed for container hosting and operate with minimal footprint for running containers.
RA-02: Security Categorization	Container Host Operating System maintains security categorisations to allow containers supporting sensitive or critical applications to be segregated and hosted separately on designated hosts.
SC-05: Denial of Service Protection	Container Host Operating System leverages elastic scaling where possible to mitigate against Denial of Service attacks to system resources.
SC-06: Resource Availability	Enforce restrictions on resource allocations to container daemon for Container Host Operating System.
SC-32: System Partitioning	Ensure logical separation of any system resources being made available to Application Containers, to reduce potential risk of containers accessing sensitive functions or information within host operating system.
SC-50: Software-enforced Separation and Policy Enforcement	Container Host Operating System running Application Containers aer isolated from systems running security or orchestration functions. These systems aer not deployed within same network security groups.
SI-03: Malicious Code Protection	Container Host Operating System aer hardened against malware. Utilise Endpoint Protection solution or system integrity services (such as AppArmor, SELinux or Seccomp).
SI-07: Software, Firmware, and Information Integrity	Ensure system integrity for Container Host Operating System is maintained including underlying virtualisation services and system firmware.

Control list: Container Image Registry

Control Objective	Control Description
AC-06: Least Privilege	Restrict privileges assigned to users or services that can upload or modify container images within registry.
AC-20: Use of External Systems	Maintain images within private registry from source and only permit cloning/copy of images from trusted providers. Perform own validate authenticity and trustworthiness of any images being downloaded from unknown sources.
AU-03: Content of Audit Records	Container Image Registry generates audit records for the following events: Logon to and logoff from any user account Image creation, updates, archive or removal. Changes to Container Image metadata
AU-10: Non-repudiation	Container images are digitally signed from trusted source build tools and workflows.
CM-08: System Component Inventory	Maintain metadata labels or tagging to capture any security related attributes for container images.
CP-10: System Recovery and Reconstitution	Maintain backups of artefacts maintained within image registry and associated metadata.
RA-05: Vulnerability Monitoring and Scanning	Schedule regular scans of your repository in order to detect vulnerabilities that may not have been identified during initial build. Scan and monitor for open source vulnerabilities within container images, operating system (OS) packages installed or other dependencies.
SA-03: System Development Life Cycle	Stale images or images that haven’t been scanned recently are rejected or rescanned before moving to build stage. Build workflows that regularly identifies stale or unused container images from the registry. Archive or remove images until updated with latest patching.
SA-13: Trustworthiness	Ensure and maintain integrity container images being uploaded within container registry.
SC-35: External Malicious Code Identification	Periodically scan for potential malicious code or malware for container images that maybe introduced accidentally the external package dependencies or intentionally by malicious insider.
SI-03: Malicious Code Protection	Container image registry system have endpoint protection enabled for anti-malware and intrusion prevention.
SR-03: Supply Chain Controls and Processes	Utilise trusted image build workflows and tooling when establishing own images within private registry.

Control list: Container Image Build

Control Objective	Control Description
AC-06: Least Privilege	Minimise the base image to core components to reduce attack surface and number of vulnerabilities requiring ongoing patching and updates. Remove any general system libraries or system utilities not required.
AC-20: Use of External Systems	Any underlying base image being sourced from external public locations are from trusted providers or vendors.
AU-03: Content of Audit Records	Container Image Registry generates audit records for the following events: Logon to and logoff from any user account Originating user triggering build events or pipelines Successful and unsuccessful pipeline events triggered for container image builds Successful and unsuccessful digital signing for container images
AU-10: Non-repudiation	Digitally sign container images and associated metadata using unique private digital certificate allocated to image build tooling.
CP-10: System Recovery and Reconstitution	Maintain backups of code base (ideally within source code management) used image builds.
RA-05: Vulnerability Monitoring and Scanning	Scan and monitor for open source vulnerabilities within operating system and dependencies during build.
SA-03: System Development Life Cycle	Prevent leaked sensitive information to baseline container images by scanning for secrets within images artefacts or configuration file.
SA-06: Software Usage Restrictions	Don’t allow sshd daemon to be packaged within base container images.
SA-13: Trustworthiness	Sign images using private certificates issued from trusted certificate authority.
SA-19: Component Authenticity	Use package manager for packages and binaries deployed within the container image. Verify signatures of packages being included within image.
SC-35: External Malicious Code Identification	Scan during build for potential malicious code or malware for container images that maybe introduced accidently the external package dependencies or intentionally by malicious insider.
SR-03: Supply Chain Controls and Processes	Establish multi-stage build capability and maintain deployment phases or environments as parameters. Remove development tooling and libraries using during build or testing from production deployments.

Appendix A – References

Please see below links to external sites for further reading

Appendix B - Disclosure Notice

This document is published as independent research only and is without warrenty. It does not represent any publication from National Institute of Standards and Technology (NIST) or other associated US government entities.