NIST SP 800-190

Use a host operating system designed for running containers so that the attack surface outside the container runtime is minimal. Remove unused services and apply immutable patterns where supported.

• host OS standard and version inventory
• service inventory on container hosts
• image rebuild cadence for nodes
• configuration management baseline export

• general purpose OS used for container hosts
• package set drifts as engineers install tools by hand
• no rebuild cadence, only in place upgrades

Keep host kernels and container runtime components patched on a defined schedule, with a process for emergency patching of kernel vulnerabilities that affect container isolation.

• host patch schedule with measured cadence
• runtime version inventory across clusters
• emergency patch playbook
• deviation register for nodes lagging baseline

• runtime updates deferred indefinitely due to fear of restart
• no zero day playbook for container escape vulnerabilities
• patch coverage measured as average, not as worst case

Scan every container image for known vulnerabilities before it is promoted to production and continuously after deployment. Track vulnerabilities by image, base layer, and software package so that remediation can be prioritized against the actual runtime exposure.

• image scanner integration with the CI pipeline
• policy that blocks promotion of images with critical findings
• vulnerability dashboard with image to deployment mapping
• remediation SLA report by severity

• only initial images scanned, not rebuilt periodically
• no policy blocking promotion of images with known critical CVEs
• base image refresh cadence not defined

Build images using minimal base layers, remove development tools and shells where possible, and configure non root users. Treat the Dockerfile or equivalent build specification as code that is reviewed and version controlled.

• approved base image catalog
• Dockerfile lint rules and review evidence
• non root user enforcement at admission control
• exception register for images requiring shells

• images run as root with no documented business reason
• no minimal base image standard published
• build specifications not subject to code review

Prevent secrets, API tokens, private keys, and credentials from being baked into container images at build time. Use a runtime secrets manager and scan images for secrets before they are pushed to the registry.

• secret scanner integrated with build pipeline
• secret rotation procedure for findings
• runtime secret injection design (vault, sidecar, or platform native)
• audit log of secret access by workload

• scanning runs after registry push rather than before
• no rotation triggered after a leaked secret is found
• developers paste credentials into Dockerfile environment variables

Shared responsibility model definition. Control from NIST SP 800-190 framework, domain: NIST SP 800-190: Cloud Governance.

• Shared responsibility matrix
• Provider contract excerpts
• Service ownership map

• No documented matrix per provider
• Ownership ambiguity for IAM
• Misaligned expectations

Cloud security policy and strategy. Control from NIST SP 800-190 framework, domain: NIST SP 800-190: Cloud Governance.

• Cloud security policy
• Cloud strategy document
• Approval records for new services

• Policy lags new cloud services
• No cloud strategy
• Ad hoc adoption

Cloud risk assessment. Control from NIST SP 800-190 framework, domain: NIST SP 800-190: Cloud Governance.

• Cloud risk register
• Provider risk assessment reports
• Re-assessment schedule

• Risk assessed only at onboarding
• No re-assessment after material changes
• Provider concentration risk ignored

Regulatory compliance for cloud services. Control from NIST SP 800-190 framework, domain: NIST SP 800-190: Cloud Governance.

• Cloud compliance matrix
• Provider attestation reports
• Customer responsibility documentation

• No mapping of regulations to cloud controls
• Outdated provider attestations
• Customer-side gaps unowned

Cloud security roles and responsibilities. Control from NIST SP 800-190 framework, domain: NIST SP 800-190: Cloud Governance.

• RACI matrix for security functions
• Job descriptions with security duties
• Segregation of duties analysis

• RACI absent or stale
• Overlapping responsibilities
• SoD conflicts unmitigated

Virtual network segmentation. Control from NIST SP 800-190 framework, domain: NIST SP 800-190: Cloud Infrastructure Security.

• Network architecture diagram
• Firewall rule review evidence
• Segmentation test results
• DMZ design document

• Flat internal networks
• Stale firewall rules
• No micro-segmentation for sensitive zones

Container and serverless security. Control from NIST SP 800-190 framework, domain: NIST SP 800-190: Cloud Infrastructure Security.

• Image scanning results
• Admission controller policy
• Function permissions inventory

• Images deployed without scanning
• Root containers
• Over-permissioned functions

Cloud workload protection. Control from NIST SP 800-190 framework, domain: NIST SP 800-190: Cloud Infrastructure Security.

• CWPP coverage report
• Runtime detection logs
• Hardening posture report

• Coverage gaps across accounts
• No runtime detection
• Drift from hardening baseline

Image and template hardening. Control from NIST SP 800-190 framework, domain: NIST SP 800-190: Cloud Infrastructure Security.

• Golden image build records
• Template scanning results
• Approved image registry

• Ad hoc images in production
• Templates unscanned
• No central image registry

Cloud configuration management. Control from NIST SP 800-190 framework, domain: NIST SP 800-190: Cloud Infrastructure Security.

• CSPM findings backlog
• Configuration baseline
• Remediation SLA tracker

• CSPM noise overwhelms remediation
• No baseline per service
• Drift not auto-remediated

Cloud security monitoring and logging. Control from NIST SP 800-190 framework, domain: NIST SP 800-190: Cloud Operations & Monitoring.

• Cloud log onboarding inventory
• Detection use cases for cloud
• Alert response samples

• Audit logs not centralized
• Cloud detections immature
• No anomaly baselines

Incident response in cloud. Control from NIST SP 800-190 framework, domain: NIST SP 800-190: Cloud Operations & Monitoring.

• Cloud IR playbooks
• Snapshot-for-forensics procedure
• Provider engagement records

• No cloud-specific playbooks
• No forensic snapshot capability
• Provider contacts unknown

Cloud vulnerability management. Control from NIST SP 800-190 framework, domain: NIST SP 800-190: Cloud Operations & Monitoring.

• Scan schedule and scope
• Remediation SLA dashboard
• Authenticated scan coverage report

• Unauthenticated scans only
• SLA breaches on criticals
• Scope gaps on cloud assets

Cloud change management. Control from NIST SP 800-190 framework, domain: NIST SP 800-190: Cloud Operations & Monitoring.

• IaC pipeline approval records
• Change ticket linkage to deploys
• Drift detection alerts

• Console changes outside IaC
• No approval gate
• Drift uncorrected

Service level agreement management. Control from NIST SP 800-190 framework, domain: NIST SP 800-190: Cloud Operations & Monitoring.

• SLA register
• Service credit claims
• Provider scorecards

• SLA breaches uncaptured
• No service credit claims process
• No scorecards

Data classification for cloud. Control from NIST SP 800-190 framework, domain: NIST SP 800-190: Data Protection in Cloud.

• Cloud data catalog
• Classification tags on resources
• Sensitive data discovery report

• No classification on cloud buckets
• Untagged sensitive data
• Discovery limited to certain accounts

Encryption of cloud-stored data. Control from NIST SP 800-190 framework, domain: NIST SP 800-190: Data Protection in Cloud.

• Cloud encryption configuration
• Customer-managed key inventory
• Bucket encryption posture report

• Default provider keys only
• Unencrypted snapshots
• No coverage validation

Data residency and sovereignty. Control from NIST SP 800-190 framework, domain: NIST SP 800-190: Data Protection in Cloud.

• Residency requirements matrix
• Region restriction policy
• Cross-border transfer assessment

• No residency policy
• Replication to non-approved regions
• No transfer impact assessment

Data backup and recovery in cloud. Control from NIST SP 800-190 framework, domain: NIST SP 800-190: Data Protection in Cloud.

• Backup schedule and retention
• Restore test results
• Immutable backup configuration

• No restore tests in 12 months
• Backups not immutable
• RTO/RPO not measured

Secure data deletion in cloud. Control from NIST SP 800-190 framework, domain: NIST SP 800-190: Data Protection in Cloud.

• Deletion request workflow
• Cryptographic erasure records
• Lifecycle policy configuration

• Soft delete only
• Backups retain deleted data indefinitely
• No deletion proof to data subjects

Cloud identity management. Control from NIST SP 800-190 framework, domain: NIST SP 800-190: Identity & Access in Cloud.

• Cloud IAM policy
• Federation configuration
• Role assignment exports

• Local cloud accounts not federated
• Wildcard IAM policies
• No periodic role review

Multi-factor authentication for cloud. Control from NIST SP 800-190 framework, domain: NIST SP 800-190: Identity & Access in Cloud.

• MFA enrollment coverage report
• Conditional access policy export
• Phishing-resistant MFA roadmap

• MFA bypass for service accounts
• SMS-based MFA still in use
• Incomplete coverage for VPN/admin paths

Privileged access in cloud environments. Control from NIST SP 800-190 framework, domain: NIST SP 800-190: Identity & Access in Cloud.

• Role-permission matrix
• PAM session recordings
• Just-in-time elevation logs
• Standing privilege review minutes

• Excessive standing admin rights
• Shared privileged credentials
• No session recording for break-glass

Federation and single sign-on. Control from NIST SP 800-190 framework, domain: NIST SP 800-190: Identity & Access in Cloud.

• SSO catalog of integrated apps
• SAML/OIDC configuration
• App onboarding standards

• Apps bypass SSO
• No standard onboarding flow
• Stale federations

API security and access tokens. Control from NIST SP 800-190 framework, domain: NIST SP 800-190: Identity & Access in Cloud.

• API gateway configuration
• Token lifetime policy
• API inventory

• Long-lived tokens
• No API inventory
• Unauthenticated APIs in production

Collect application, orchestrator, and runtime logs to a central platform with retention aligned to incident response needs. Ensure container short lifespans do not lead to log loss for forensic analysis.

• log shipping agent design
• log retention policy with regulatory cross reference
• sample retrieval of logs from a terminated pod
• incident response playbook citing log sources

• logs lost when pods terminate quickly
• audit logs not collected from the orchestrator API server
• retention shorter than incident detection latency

Adapt incident response procedures to container realities including ephemeral workloads, image based forensics, and rapid scale events. Define how compromised containers are quarantined and how their state is captured.

• container incident response playbook
• image and process capture procedure
• tabletop exercise records
• post incident review of a container event

• responders kill compromised pods before evidence is preserved
• no documented network isolation method for pods
• playbook never exercised against container scenarios

Limit pod to pod communication using network policies that follow a default deny model. Allow only the flows that the application requires, including egress, so a compromised pod cannot pivot freely across the cluster.

• default deny NetworkPolicy in each namespace
• allow list policies per application
• egress firewall logs for cluster nodes
• policy compliance dashboard

• default allow remains in development namespaces
• no egress control to the internet
• policies authored once and never updated as apps change

Avoid co tenanting workloads of dramatically different sensitivity on the same node or namespace. Use node selectors, taints, and dedicated node pools to separate regulated workloads from general purpose applications.

• node pool segmentation design
• taint and toleration policy
• data classification mapping to namespace
• deviation register for shared nodes

• sensitive workloads share nodes with batch jobs
• no labels reflecting data classification
• scheduling policies bypassed during capacity events

Authenticate humans and services accessing the orchestrator API using strong identity providers. Disable static token bootstrap accounts once cluster setup is complete and ensure all administrative actions tie back to a named identity.

• identity provider integration design
• audit log sample showing user attribution
• bootstrap token disablement evidence
• kube admin RBAC bindings export

• shared kubeconfig files distributed via chat tools
• service account tokens never rotated
• audit logs do not include source IP

Apply role based access control across the orchestrator using least privilege. Restrict cluster admin privileges to a small named group and prefer namespace scoped roles for development teams.

• RBAC role definitions and bindings export
• list of cluster admin holders with business justification
• namespace ownership register
• quarterly access certification records

• default service accounts granted edit on namespaces
• no review of cluster admin membership
• wildcard verbs and resources used in bindings

Apply baseline and restricted pod security standards so that workloads cannot run privileged containers, mount the host file system, or use the host network without an approved exception. Enforce these controls at admission, not just at lint time.

• pod security admission configuration per namespace
• exception register with expiration dates
• audit log of rejected pod creations
• policy as code rule set (e.g. OPA, Kyverno) and tests

• privileged pods permitted in shared namespaces
• no enforcement in dev clusters that mirror production
• exceptions persist long after the underlying need is gone

Restrict registry access to authenticated users and workloads, enforce role based controls over who can push images, and remove anonymous read where possible. Apply network controls so that only approved nodes can pull from the registry.

• registry RBAC export with push permissions
• service account credentials rotation log
• network policy restricting registry pulls to known CIDR
• audit log of registry push events

• anonymous pull enabled to support legacy clients
• developer accounts retain push rights to production registry
• no monitoring of unusual push patterns

Identify and remove stale images from registries to reduce the chance that obsolete vulnerable code is redeployed. Apply tag immutability for production tags and document retention by tag pattern.

• registry retention policy by tag
• automated cleanup job evidence
• tag immutability configuration for release tags
• report of images older than retention threshold

• tag overwrites permitted on production tags
• no automation removing untagged or stale layers
• retention policy is published but not enforced

Configure the container runtime to reduce kernel level attack surface using seccomp profiles, AppArmor or SELinux, and capability dropping. Ensure these controls apply to every container, not just hand picked services.

• default seccomp profile applied to all pods
• AppArmor or SELinux mode configuration per node
• capability allow list per workload
• runtime configuration drift report

• seccomp profile set to unconfined for compatibility
• AppArmor in complain mode rather than enforce
• containers granted SYS_ADMIN broadly

Run containers with read only root file systems where the application supports it. Use tmpfs or volumes for paths that need to be writable so that an attacker cannot persist modifications inside a running container.

• policy requiring read only root for new workloads
• exception register for writable containers
• audit of running containers with writable root
• design pattern documentation for tmpfs usage

• writable root retained because application logs locally
• no scan of running containers for compliance
• exception process exists on paper only

Deploy runtime threat detection that monitors process activity, file changes, and network behavior inside containers. Tune detections to the workload baseline and integrate alerts with the SOC.

• runtime detection tool design
• baseline ruleset documentation
• alert handling playbook
• monthly metrics on detection volume and false positive rate

• detection tool deployed but alerts not routed to SOC
• rules left at vendor defaults causing alert fatigue
• no validation that the agent is running on every node

Provide secrets to containers at runtime through a managed secrets system rather than environment variables or mounted files in plaintext. Rotate secrets on schedule and revoke them when a workload is decommissioned.

• secrets manager integration design
• rotation schedule by secret type
• decommission checklist including secret revocation
• audit log of secret access by workload identity

• secrets injected via plain env vars from CI
• no rotation cadence enforced
• decommissioned workloads still hold valid credentials

Treat third party images as supply chain dependencies. Mirror them into an internal registry, scan and approve them before use, and track which workloads consume each external image so that a future vendor compromise can be triaged quickly.

• approved third party image catalog
• mirror sync job evidence
• vendor risk assessments for high impact images
• consumption map of external images to workloads

• workloads pull directly from public registries
• no inventory of which external images are in use
• vendor advisories not monitored for in use images

Sign container images during the build process and verify those signatures at admission to clusters. Track image provenance back to source repository commits and build pipelines that produced them.

• signing tool and key custody documentation
• admission controller policy requiring signature verification
• build attestation generated per image
• registry configuration enforcing signed tags

• signing performed but never verified at deploy
• keys for signing held in CI without HSM protection
• no link maintained from image hash to source commit