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

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

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

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

Additional Notes

Related security patterns

Design Principles  

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

  1. Prefer minimal base images for Application Containers.
  2. Digitally sign and verify container images during deployment to mitigate man in the middle attacks.
  3. Apply least privilege for Application Containers within platform.
  4. Monitor and audit Application Containers activity within platform.
  5. Implement limits on the system resources that the Application Containers can consume.
  6. Scan and remediate vulnerabilities identified within container images.
  7. 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