WAF-SEC-120 – Container & Runtime Security

Pillar: Security | Severity: High | Category: Identity Access | Automatable: High

Description

Container workloads MUST run as non-root users (UID != 0) with explicit user and group IDs set in Dockerfile or Kubernetes security context. Privileged container mode MUST be disabled for all production workloads. Container images MUST originate from registries with image scanning enabled (ECR or equivalent) and MUST NOT be pulled directly from unauthenticated public registries at runtime. EKS clusters MUST have the API server endpoint restricted; public access MUST be disabled or limited to known CIDR ranges. Container runtime security monitoring MUST be implemented to detect and alert on anomalous container behaviors at runtime.

Rationale

Risk	Description
Risk	Internet-facing resources or open management ports become direct attack vectors.
Risk	Lateral movement is easier when network segmentation and access rules are missing.

Risk

Description

Risk

Internet-facing resources or open management ports become direct attack vectors.

Risk

Lateral movement is easier when network segmentation and access rules are missing.

Requirements

Container workloads MUST run as non-root users (UID != 0) with explicit user and group IDs set in Dockerfile or Kubernetes security context.
Privileged container mode MUST be disabled for all production workloads.
Container images MUST originate from registries with image scanning enabled (ECR or equivalent) and MUST NOT be pulled directly from unauthenticated public registries at runtime.
EKS clusters MUST have the API server endpoint restricted; public access MUST be disabled or limited to known CIDR ranges.
Container runtime security monitoring MUST be implemented to detect and alert on anomalous container behaviors at runtime.

Implementation Guidance

Implement the required configuration as code in Terraform or equivalent IaC.
Add an automated check to CI/CD so deviations are caught before deployment.

Maturity Levels

Level	Name	Criteria
L1	Ad hoc – control not consistently applied	* Manual evidence exists for some workloads, but coverage is unknown.
L2	Standardised – policy defined and communicated	* A version-controlled policy, ADR, or standard describes the requirement.
L3	Integrated – automated validation in CI/CD	* Terraform checks run automatically on pull requests and report results.
L4	Auditable – metrics and exceptions tracked	* Control coverage, failures, and approved exceptions are reported quarterly.
L5	Optimised – continuous improvement based on data	* Control effectiveness is measured and iteratively improved.

Level

Name

Criteria

Ad hoc – control not consistently applied

* Manual evidence exists for some workloads, but coverage is unknown.

Standardised – policy defined and communicated

* A version-controlled policy, ADR, or standard describes the requirement.

Integrated – automated validation in CI/CD

* Terraform checks run automatically on pull requests and report results.

Auditable – metrics and exceptions tracked

* Control coverage, failures, and approved exceptions are reported quarterly.

Optimised – continuous improvement based on data

* Control effectiveness is measured and iteratively improved.

Checks

waf-sec-120.tf.aws.eks-private-endpoint

Engine: terraform | Provider: aws | Automated: Yes

EKS cluster API server endpoint must not be publicly accessible

The aws_eks_cluster vpc_config block must be present. The EKS API server endpoint should have endpoint_public_access disabled or restricted to known CIDR ranges. Public EKS API endpoints expose the Kubernetes control plane to internet-based attacks targeting API vulnerabilities and credential compromise.

Scope: resource — aws_eks_cluster

Assertions: * vpc_config attribute exists — EKS cluster must have a vpc_config block defined to configure endpoint access restrictions.

Remediation: Add a vpc_config block to the aws_eks_cluster resource. Set endpoint_public_access = false to disable public API access entirely and use a VPN or AWS Direct Connect for cluster management. If public access is required, set endpoint_public_access_cidrs to specific CIDR ranges for your organization’s VPN or office IPs and set endpoint_private_access = true. Deploy a bastion host or use AWS Systems Manager Session Manager in the VPC for kubectl access.

Compliant

resource "aws_eks_cluster" "main" {
  name     = "production-cluster"
  role_arn = aws_iam_role.eks_cluster.arn
  version  = "1.30"

  vpc_config {
    subnet_ids              = aws_subnet.private[*].id
    endpoint_private_access = true
    endpoint_public_access  = false
    security_group_ids      = [aws_security_group.eks_cluster.id]
  }

  enabled_cluster_log_types = ["api", "audit", "authenticator", "controllerManager", "scheduler"]

  tags = {
    environment = "production"
  }
}

Non-Compliant

resource "aws_eks_cluster" "main" {
  name     = "production-cluster"
  role_arn = aws_iam_role.eks_cluster.arn
  version  = "1.30"

  vpc_config {
    subnet_ids             = aws_subnet.public[*].id
    endpoint_public_access = true   # WAF-SEC-120 violation: public API server endpoint
    # endpoint_private_access not set – defaults to false
  }
  # enabled_cluster_log_types not set – audit logging disabled
}

waf-sec-120.tf.aws.ecr-scan-on-push

Engine: terraform | Provider: aws | Automated: Yes

Container images must be sourced from ECR repositories with scanning enabled

All aws_ecr_repository resources supplying container images to production EKS or ECS workloads must have image_scanning_configuration with scan_on_push = true. This ensures vulnerability detection occurs at the point of image ingestion, not as a periodic job that may miss images deployed between scan cycles.

Scope: resource — aws_ecr_repository

Assertions: * image_scanning_configuration attribute exists — ECR repository must have image_scanning_configuration defined to ensure all pushed images are scanned for vulnerabilities.

Remediation: Add an image_scanning_configuration block with scan_on_push = true to all aws_ecr_repository resources. Configure ECR lifecycle policies to automatically remove images with critical findings. Consider enabling Amazon Inspector for enhanced scanning that includes application dependency CVEs in addition to OS packages.

Compliant

resource "aws_ecr_repository" "app" {
  name                 = "production-app"
  image_tag_mutability = "IMMUTABLE"

  image_scanning_configuration {
    scan_on_push = true
  }

  encryption_configuration {
    encryption_type = "KMS"
    kms_key         = aws_kms_key.ecr.arn
  }
}

Non-Compliant

resource "aws_ecr_repository" "app" {
  name                 = "production-app"
  image_tag_mutability = "MUTABLE"
  # No image_scanning_configuration – WAF-SEC-120 violation
  # Vulnerability scanning not enforced at push time
}

waf-sec-120.tf.azurerm.aks-private-cluster

Engine: terraform | Provider: azurerm | Automated: Yes

Azure Kubernetes Service clusters must use private cluster mode

All azurerm_kubernetes_cluster resources must have private_cluster_enabled = true and public_network_access_enabled = false to limit API server exposure.

Scope: resource — azurerm_kubernetes_cluster

Assertions: * private_cluster_enabled is true — AKS cluster must have private cluster mode enabled. * public_network_access_enabled is false — AKS cluster must disable public network access to the API server.

Remediation: Enable private_cluster_enabled and set public_network_access_enabled = false on every AKS cluster. Connect to the API server via private endpoints or Azure Bastion.

Compliant

resource "azurerm_kubernetes_cluster" "app" {
  name                = "app-aks"
  location            = azurerm_resource_group.main.location
  resource_group_name = azurerm_resource_group.main.name
  dns_prefix          = "app-aks"
  private_cluster_enabled = true
  public_network_access_enabled = false
  default_node_pool {
    name       = "default"
    node_count = 2
    vm_size    = "Standard_D2s_v3"
  }
  identity {
    type = "SystemAssigned"
  }
}

Non-Compliant

resource "azurerm_kubernetes_cluster" "app" {
  name                = "app-aks"
  location            = azurerm_resource_group.main.location
  resource_group_name = azurerm_resource_group.main.name
  dns_prefix          = "app-aks"
  # private_cluster_enabled defaults to false
  default_node_pool {
    name       = "default"
    node_count = 2
    vm_size    = "Standard_D2s_v3"
  }
}

waf-sec-120.tf.google.gke-private-cluster

Engine: terraform | Provider: google | Automated: Yes

Google Kubernetes Engine clusters must use private nodes

All google_container_cluster resources must have private_cluster_config.enable_private_nodes = true and master_authorized_networks_config enabled to restrict API server access.

Scope: resource — google_container_cluster

Assertions: * private_cluster_config.enable_private_nodes is true — GKE cluster must use private nodes. * master_authorized_networks_config attribute exists — GKE cluster must restrict master authorized networks.

Remediation: Configure private_cluster_config with enable_private_nodes = true and define master_authorized_networks_config with trusted CIDRs on every GKE cluster.

Compliant

resource "google_container_cluster" "app" {
  name     = "app-gke"
  location = "europe-west3"
  private_cluster_config {
    enable_private_nodes    = true
    enable_private_endpoint = false
    master_ipv4_cidr_block  = "172.16.0.0/28"
  }
  master_authorized_networks_config {
    cidr_blocks {
      cidr_block   = "10.0.0.0/8"
      display_name = "internal-network"
    }
  }
}

Non-Compliant

resource "google_container_cluster" "app" {
  name     = "app-gke"
  location = "europe-west3"
  # private_cluster_config not set – nodes have public IPs by default
}

waf-sec-120.tf.stackit.database-backup-enabled

Engine: terraform | Provider: stackit | Automated: Yes

STACKIT managed databases must have backup and point-in-time recovery enabled

stackit_postgres_flex_instance, stackit_mysql_instance, stackit_redis_instance, and stackit_opensearch_instance resources must have automated backups enabled with a documented retention and recovery procedure.

Scope: resource — stackit_postgres_flex_instance, stackit_mysql_instance, stackit_redis_instance, stackit_opensearch_instance

Assertions: * name attribute exists — STACKIT managed database must have backups and recovery configured.

Remediation: Enable automated backups on all STACKIT managed data services. Define retention, encryption, and recovery SLAs in a documented backup policy.

Compliant

resource "stackit_postgres_flex_instance" "app" {
  project_id = var.stackit_project_id
  name       = "app-db"
  version    = "15"
  # backups enabled with retention >= 7 days
}

Non-Compliant

resource "stackit_postgres_flex_instance" "app" {
  project_id = var.stackit_project_id
  name       = "app-db"
  # WAF-SEC-120 violation: backups not configured
}

waf-sec-120.config.ovh.ovh-identity-access

Engine: config | Provider: ovh | Automated: Yes

OVHcloud workloads must have backup and recovery procedures documented

A version-controlled policy document must exist at docs/security/waf-sec-120-ovh-identity-access.md and document the OVHcloud implementation of this control. The checker validates that the file exists and contains a normative requirement statement (MUST/SHALL/required/mandatory).

Scope: file — docs/security/waf-sec-120-ovh-identity-access.md

Remediation: Create or update docs/security/waf-sec-120-ovh-identity-access.md. State the requirement, how it is implemented for OVHcloud, the review cadence, and the owner.

Compliant

docs/security/waf-sec-120-ovh-identity-access.md:
- The OVHcloud implementation of WAF-SEC-120 is documented.
- Implementation status and owner are recorded.
- Review cadence is defined (e.g. quarterly).

Non-Compliant

# `docs/security/waf-sec-120-ovh-identity-access.md` is missing or does not contain a normative requirement.
# WAF-SEC-120 violation: OVHcloud control is not documented

waf-sec-120.tf.hcloud.volume-backups-enabled

Engine: terraform | Provider: hcloud | Automated: Yes

Hetzner Cloud volumes must have backups enabled

All hcloud_volume resources storing production data must have backups enabled via hcloud_volume or server backup settings, with documented retention and recovery procedures.

Scope: resource — hcloud_volume

Assertions: * name attribute exists — Hetzner Cloud volume must have backups enabled or documented.

Remediation: Enable backups on hcloud_volume resources or the attached hcloud_server. Document backup retention and recovery runbooks.

Compliant

resource "hcloud_volume" "app" {
  name      = "app-data"
  size      = 100
  server_id = hcloud_server.app.id
  # backups enabled via server or volume backup policy
}

Non-Compliant

resource "hcloud_volume" "app" {
  name      = "app-data"
  size      = 100
  server_id = hcloud_server.app.id
  # WAF-SEC-120 violation: backups not verified
}

Evidence

Kind Required Description

Kind	Required	Description
`iac`	Required	Terraform configuration implementing the control.
`governance`	Required	Policy, ADR, or standard documenting the requirement.
`config`	Optional	Cloud console or API output confirming runtime state.

iac

Required

Terraform configuration implementing the control.

governance

Required

Policy, ADR, or standard documenting the requirement.

config

Optional

Cloud console or API output confirming runtime state.

Related Controls

Framework	Controls
ISO 27001:2022	* A.8.8 – Management of technical vulnerabilities * A.8.19 – Installation of software on operational systems * A.8.22 – Segregation of networks * A.8.7 – Protection against malware
ISO 27017	* CLD.9.5 – Segregation in virtual computing environments
CIS Controls v8	* CIS 4 – Secure Configuration of Enterprise Assets and Software * CIS 7 – Continuous Vulnerability Management * CIS 13 – Network Monitoring and Defense
CSA STAR	* CCM IVS-04 – OS Hardening and Base Controls * CCM TVM-04 – Threat Detection and Response
PCI DSS v4.0	* Req 2.2 – Secure configuration baselines * Req 6.4 – Develop systems using secure coding
SOC 2 Type II	* CC6.6 – System hardening * CC7.1 – System monitoring
GDPR	* Art. 32 – Security of processing
NIS2	* Art. 21(2)(c) – Network and information system security
DORA	* Art. 9 – Protection and prevention
EUCS (ENISA)	* OPS-08 – Operations and service management * CSC-01 – Communication security
BSI C5:2020	* OPS-12 – Hardening of operating systems * OPS-13 – Configuration management * COM-01 – Network segmentation
IT-Grundschutz	* SYS.1.6 – Containerisierung * APP.4.4 – Kubernetes
TISAX	* Information security – System hardening and configuration
ANSSI SecNumCloud	* Domain – System hardening
BIO	* BIO – Hardening en configuratiebeheer
ENS High	* op.exp.2 – Configuración de seguridad * op.exp.3 – Gestión de la configuración
UK Cyber Essentials	* CE.SC – Secure configuration
UK NCSC CAF	* B4 – System security
NIST SP 800-53	* CM-2 – Baseline Configuration * CM-6 – Configuration Settings * SI-3 – Malicious Code Protection * SI-4 – System Monitoring
NIST CSF 2.0	* PR.PS-01 – Configuration management practices * DE.CM-09 – Computing hardware/software is monitored
FedRAMP	* CM-2, CM-6, SI-3, SI-4 (Moderate/High baseline)
HIPAA	* § 164.308(a)(5)(ii)(B) – Protection from malicious software
CMMC 2.0	* CM.L2-3.4.1 – Establish baseline configurations * SI.L2-3.14.2 – Provide protection from malicious code
ASD Essential 8	* E8.4 – User application hardening * E8.6 – Operating system patching
IRAP	* ISM – System hardening
CCCS PBMM	* CM-6, SI-3 – Configuration and malware protection
MAS TRM	* Ch.13 – Cloud computing controls
ISMAP	* Container and runtime security
FISC	* Technical measures – System hardening

Framework

Controls

ISO 27001:2022

* A.8.8 – Management of technical vulnerabilities * A.8.19 – Installation of software on operational systems * A.8.22 – Segregation of networks * A.8.7 – Protection against malware

ISO 27017

* CLD.9.5 – Segregation in virtual computing environments

CIS Controls v8

* CIS 4 – Secure Configuration of Enterprise Assets and Software * CIS 7 – Continuous Vulnerability Management * CIS 13 – Network Monitoring and Defense

CSA STAR

* CCM IVS-04 – OS Hardening and Base Controls * CCM TVM-04 – Threat Detection and Response

PCI DSS v4.0

* Req 2.2 – Secure configuration baselines * Req 6.4 – Develop systems using secure coding

SOC 2 Type II

* CC6.6 – System hardening * CC7.1 – System monitoring

GDPR

* Art. 32 – Security of processing

NIS2

* Art. 21(2)(c) – Network and information system security

DORA

* Art. 9 – Protection and prevention

EUCS (ENISA)

* OPS-08 – Operations and service management * CSC-01 – Communication security

BSI C5:2020

* OPS-12 – Hardening of operating systems * OPS-13 – Configuration management * COM-01 – Network segmentation

IT-Grundschutz

* SYS.1.6 – Containerisierung * APP.4.4 – Kubernetes

TISAX

* Information security – System hardening and configuration

ANSSI SecNumCloud

* Domain – System hardening

BIO

* BIO – Hardening en configuratiebeheer

ENS High

* op.exp.2 – Configuración de seguridad * op.exp.3 – Gestión de la configuración

UK Cyber Essentials

* CE.SC – Secure configuration

UK NCSC CAF

* B4 – System security

NIST SP 800-53

* CM-2 – Baseline Configuration * CM-6 – Configuration Settings * SI-3 – Malicious Code Protection * SI-4 – System Monitoring

NIST CSF 2.0

* PR.PS-01 – Configuration management practices * DE.CM-09 – Computing hardware/software is monitored

FedRAMP

* CM-2, CM-6, SI-3, SI-4 (Moderate/High baseline)

HIPAA

* § 164.308(a)(5)(ii)(B) – Protection from malicious software

CMMC 2.0

* CM.L2-3.4.1 – Establish baseline configurations * SI.L2-3.14.2 – Provide protection from malicious code

ASD Essential 8

* E8.4 – User application hardening * E8.6 – Operating system patching

IRAP

* ISM – System hardening

CCCS PBMM

* CM-6, SI-3 – Configuration and malware protection

MAS TRM

* Ch.13 – Cloud computing controls

ISMAP

* Container and runtime security

FISC

* Technical measures – System hardening