On This Page
  1. Compliance Frameworks Overview
  2. CIS Kubernetes Benchmark
  3. PCI DSS
  4. SOC 2
  5. HIPAA
  6. FedRAMP / NIST 800-53
  7. ISO 27001
  8. Kubernetes Control Mapping
  9. Automated Compliance Scanning
  10. Evidence Collection
  11. Continuous Compliance
  12. Metrics, Alerts & Runbooks
  13. Best Practices
Coverage Checklist

Compliance Frameworks Overview

Multiple compliance frameworks apply to Kubernetes-hosted workloads. The controls they require significantly overlap — a well-secured Kubernetes cluster simultaneously satisfies requirements across frameworks.

CIS Kubernetes Benchmark
Technical hardening

Prescriptive configuration recommendations for Kubernetes components. Automated via kube-bench. The technical foundation all other frameworks build on.

PCI DSS v4.0
Payment card data

Required for any organization that processes, stores, or transmits cardholder data. Strong network segmentation, access control, and audit logging requirements.

SOC 2 Type II
Service organizations

AICPA Trust Services Criteria: Security, Availability, Confidentiality, Processing Integrity, Privacy. Audit over a period (typically 6–12 months).

HIPAA
Healthcare / ePHI

Required for covered entities and business associates handling electronic protected health information. Technical and administrative safeguards.

FedRAMP
US federal cloud

Based on NIST 800-53. Required for cloud services used by US federal agencies. Three impact levels: Low / Moderate / High.

ISO 27001:2022
Information security

International standard for ISMS (Information Security Management System). Annex A contains 93 controls mapped to 4 themes.

Compliance ≠ Security

Compliance frameworks define minimum bars, not best practices. Passing a CIS benchmark scan does not mean your cluster is secure — it means it meets a specific configuration baseline. Use compliance as a floor, not a ceiling. Many real-world breaches occurred in compliant environments.

CIS Kubernetes Benchmark

The CIS Kubernetes Benchmark (current: v1.9.0 for Kubernetes 1.29+) defines configuration recommendations across six sections. Each check is scored (mandatory) or not scored (advisory).

Benchmark Sections

SectionComponentKey ChecksAuto-Remediable
1 Control Plane Components API server flags: anonymous-auth, insecure-port, audit-log, authorization-mode Partial
2 etcd TLS peer/client auth, data directory permissions, encryption at rest Partial
3 Control Plane Config Audit policy completeness, encryption config, admission plugins Partial
4 Worker Nodes kubelet auth, anonymous-auth=false, protect-kernel-defaults, TLS cert rotation Partial
5 Kubernetes Policies RBAC, NetworkPolicy, PSS, Secrets management, image policy Yes (Kyverno)

kube-bench: Automated CIS Scanning

# Run kube-bench on control plane node
kube-bench run --targets master

# Run on worker node
kube-bench run --targets node

# Run all targets
kube-bench run

# Output as JSON for SIEM ingestion
kube-bench run --json > kube-bench-results.json

# Output as JUnit XML for CI integration
kube-bench run --junit > kube-bench-results.xml

# Run against specific benchmark version
kube-bench run --benchmark cis-1.9

kube-bench as In-Cluster Job

# Run kube-bench as a Kubernetes Job (node perspective)
apiVersion: batch/v1
kind: Job
metadata:
  name: kube-bench
  namespace: kube-system
spec:
  template:
    spec:
      hostPID: true       # Required to inspect host processes
      nodeSelector:
        node-role.kubernetes.io/control-plane: ""
      tolerations:
      - key: node-role.kubernetes.io/control-plane
        operator: Exists
        effect: NoSchedule
      containers:
      - name: kube-bench
        image: aquasec/kube-bench:latest
        command: ["kube-bench", "run", "--targets", "master,etcd,policies", "--json"]
        volumeMounts:
        - name: var-lib-etcd
          mountPath: /var/lib/etcd
          readOnly: true
        - name: etc-kubernetes
          mountPath: /etc/kubernetes
          readOnly: true
      restartPolicy: Never
      volumes:
      - name: var-lib-etcd
        hostPath: { path: /var/lib/etcd }
      - name: etc-kubernetes
        hostPath: { path: /etc/kubernetes }

Key CIS Controls and Kubernetes Implementation

CIS CheckIDImplementation
Disable anonymous API auth1.2.1--anonymous-auth=false on kube-apiserver
Use RBAC authorization1.2.7--authorization-mode=Node,RBAC
Enable audit logging3.2.1--audit-log-path + --audit-policy-file
Encrypt secrets at rest1.2.31--encryption-provider-config with KMS/secretbox
Disable kubelet anonymous auth4.2.1authentication.anonymous.enabled: false in kubelet config
Restrict kubelet API access4.2.2authorization.mode: Webhook in kubelet config
Protect kernel defaults4.2.6--protect-kernel-defaults=true on kubelet
Restrict pod capabilities5.2.8PSA restricted + securityContext.capabilities.drop: [ALL]
Apply NetworkPolicies5.3.2Default-deny NetworkPolicy + explicit allow policies per namespace
Avoid default ServiceAccounts5.1.5automountServiceAccountToken: false on default SA

PCI DSS v4.0

PCI DSS applies when Kubernetes runs workloads that process, store, or transmit cardholder data (CHD). The entire cluster doesn't need to be in scope — scope reduction via network segmentation is critical.

Key PCI DSS Requirements → Kubernetes Controls

PCI RequirementKubernetes Implementation
Req 1: Network security controls NetworkPolicy default-deny in CHD namespace; separate namespace per PCI scope boundary; Calico GlobalNetworkPolicy for node-level isolation
Req 2: Secure configurations CIS Kubernetes Benchmark pass; kube-bench automated scan; Polaris workload policy; no default credentials
Req 3: Protect stored account data Secrets encryption at rest (KMS v2); etcd encryption for all CHD-adjacent namespaces; no CHD in logs
Req 4: Protect cardholder data in transit mTLS between services (Istio/Linkerd); TLS termination at ingress; cert-manager certificate lifecycle
Req 5: Protect against malware Image scanning (Trivy, no CRITICAL/HIGH CVEs); Falco runtime monitoring; distroless images
Req 6: Develop/maintain secure systems SLSA provenance; dependency scanning; Cosign image signing; Kyverno registry policy
Req 7: Restrict access to system components RBAC least-privilege; namespace-scoped Roles; no wildcard resource permissions
Req 8: Identify users and authenticate OIDC authentication; MFA for kubectl access; no static kubeconfig shared between users
Req 10: Log and monitor all access Audit logging at Request level for CHD resources; SIEM integration; 12-month retention
Req 11: Test security of systems kube-bench quarterly; penetration testing; Trivy Operator continuous scanning
Req 12: Policies and procedures Kyverno policies as code = policy documentation; GitOps policy review process

CHD Namespace Isolation Pattern

# PCI-scoped namespace with all controls applied
apiVersion: v1
kind: Namespace
metadata:
  name: pci-cardholder
  labels:
    pci-scope: "true"
    # Pod Security Admission: enforce restricted
    pod-security.kubernetes.io/enforce: restricted
    pod-security.kubernetes.io/enforce-version: v1.29
    pod-security.kubernetes.io/audit: restricted
    pod-security.kubernetes.io/warn: restricted
---
# Default-deny NetworkPolicy for CHD namespace
apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: default-deny-all
  namespace: pci-cardholder
spec:
  podSelector: {}
  policyTypes: [Ingress, Egress]
# Explicit allow policies added per service

SOC 2

SOC 2 audits against the AICPA Trust Services Criteria. The Security criteria (Common Criteria, CC) are required for every SOC 2 report; the others (Availability, Confidentiality, Processing Integrity, Privacy) are optional and selected based on the service's scope.

Common Criteria → Kubernetes Controls

CC ControlDescriptionKubernetes Evidence
CC6.1Logical access securityRBAC policies, OIDC auth, MFA for cluster access, SA token binding
CC6.2Access provisioning and deprovisioningRBAC creation/deletion audit logs; offboarding removes RoleBindings
CC6.3Least privilege enforcementRBAC role scope review; rbac-police policy violations; no wildcard permissions
CC6.6Logical access from outside boundariesNetworkPolicy egress; API server endpoint restriction; ingress authentication
CC6.7Encryption of data in transit and at restetcd encryption at rest (KMS v2); TLS for all API communications; mTLS
CC7.1Detection of vulnerabilitiesTrivy Operator continuous scanning; Falco runtime detection
CC7.2Monitoring of security eventsAudit logging → SIEM; Falco → alerting; PagerDuty integration
CC7.3Security incident responseRunbooks; audit log retention; incident response playbooks
CC8.1Change managementGitOps (ArgoCD); image signing; admission webhooks enforce policy
A1.1Availability capacity planningResource requests/limits; HPA; cluster autoscaler; PodDisruptionBudgets

HIPAA

HIPAA applies to covered entities (healthcare providers, health plans, clearinghouses) and their business associates who access electronic protected health information (ePHI).

§ 164.312 Technical Safeguards → Kubernetes

HIPAA SafeguardStandardKubernetes Implementation
Access Control § 164.312(a)(1) RBAC with unique user identification; no shared kubeconfigs; namespace isolation for ePHI workloads
Automatic Logoff § 164.312(a)(2)(iii) Short-lived OIDC tokens (1h); kubectl context expiry; bound ServiceAccount tokens (1h TTL)
Encryption and Decryption § 164.312(a)(2)(iv) Secrets encryption at rest; TLS for all data in transit; mTLS for service-to-service
Audit Controls § 164.312(b) Kubernetes audit logging for all ePHI namespace access; SIEM integration; 6-year retention
Integrity § 164.312(c)(1) Image signing (Cosign); admission control (signed images only); etcd checksums
Person or Entity Authentication § 164.312(d) OIDC with MFA; no anonymous authentication; audit trail per user identity
Transmission Security § 164.312(e)(1) NetworkPolicy: deny all egress outside ePHI boundary; TLS 1.2+ minimum; certificate rotation
HIPAA Business Associate Agreement

If your Kubernetes cluster runs on a managed cloud (EKS, GKE, AKS), ensure you have a signed Business Associate Agreement (BAA) with the cloud provider covering the managed control plane. The cloud provider's access to your cluster infrastructure creates a BAA requirement.

FedRAMP / NIST 800-53

FedRAMP authorizations are based on NIST SP 800-53 Rev 5 control baselines. The impact level (Low/Moderate/High) determines which controls are required.

NIST 800-53 FamilyKey ControlsKubernetes Implementation
AC — Access ControlAC-2, AC-3, AC-6, AC-17RBAC; OIDC; least privilege; remote access audit logging
AU — Audit & AccountabilityAU-2, AU-3, AU-9, AU-12Audit logging; log integrity (immutable storage); log coverage
CA — Assessment & AuthorizationCA-7Continuous monitoring; Trivy Operator; kube-bench scheduled scans
CM — Configuration MgmtCM-2, CM-6, CM-7GitOps (ArgoCD); admission webhooks; CIS benchmark hardening
IA — Identification & AuthIA-2, IA-5, IA-8OIDC MFA; no static credentials; certificate-based authentication
SC — System & Comm ProtectionSC-7, SC-8, SC-28NetworkPolicy; TLS; encryption at rest
SI — System & Info IntegritySI-2, SI-3, SI-7Patch management; image scanning; integrity verification

ISO 27001:2022

Annex A ThemeKey ControlsKubernetes Evidence
Organizational (A.5) A.5.10 Acceptable use; A.5.15 Access control; A.5.23 Cloud services RBAC policies; cloud-provider security configuration; container security policy
People (A.6) A.6.3 Security awareness; A.6.5 Offboarding RBAC removal on offboarding; audit log per user identity
Physical (A.7) A.7.8 Equipment security Node disk encryption (LUKS); managed hardware (cloud providers)
Technological (A.8) A.8.5 Secure auth; A.8.8 Vulnerability mgmt; A.8.9 Configuration mgmt; A.8.11 Data masking; A.8.12 Data leakage; A.8.15 Logging; A.8.24 Encryption OIDC; Trivy scanning; CIS benchmark; Secrets management; audit logging; encryption at rest and in transit

Kubernetes Control Mapping

This master table maps Kubernetes security controls to multiple frameworks simultaneously. Implementing one control often satisfies requirements across all frameworks.

Kubernetes ControlCISPCI DSSSOC 2HIPAA
RBAC least-privilege5.1.xReq 7CC6.1, CC6.3§164.312(a)
OIDC authentication + MFA1.2.2Req 8CC6.1§164.312(d)
Audit logging (API server)3.2.xReq 10CC7.2§164.312(b)
Secrets encryption at rest1.2.31Req 3CC6.7§164.312(a)(iv)
NetworkPolicy default-deny5.3.2Req 1CC6.6§164.312(e)
mTLS between servicesReq 4CC6.7§164.312(e)
Image vulnerability scanning5.4.xReq 5, 6CC7.1§164.312(c)
Image signing (Cosign)Req 6CC8.1§164.312(c)
PSA restricted enforcement5.2.xReq 2CC6.1
Resource quotas + limitsA1.1
PodDisruptionBudgetsA1.1, A1.2
GitOps change controlReq 12CC8.1§164.312(c)

Automated Compliance Scanning

Polaris: Workload Best Practices

# Polaris: audit workload configurations against best practices
# Install as in-cluster audit tool
helm repo add fairwinds-stable https://charts.fairwinds.com/stable
helm install polaris fairwinds-stable/polaris \
  --namespace polaris \
  --create-namespace

# Run as CLI audit against cluster
polaris audit --cluster --format pretty

# Run against a specific namespace
polaris audit --cluster --namespace production --format json > polaris-report.json

# Run against local YAML files (CI gate)
polaris audit --audit-path ./k8s/ --format pretty --set-exit-code-on-danger

# Polaris checks: readinessProbe, livenessProbe, resources, securityContext,
# image tags, privileged containers, hostPath, runAsNonRoot, etc.

Checkov: IaC Compliance Scanning

# Checkov: static analysis of Kubernetes manifests and Terraform
pip install checkov

# Scan Kubernetes manifests
checkov -d ./k8s/ --framework kubernetes

# Scan with specific checks only (CIS benchmark checks)
checkov -d ./k8s/ --framework kubernetes \
  --check CKV_K8S_1,CKV_K8S_2,CKV_K8S_8,CKV_K8S_9

# Output as SARIF for GitHub Security tab
checkov -d ./k8s/ --framework kubernetes \
  --output sarif --output-file checkov-results.sarif

# Scan Helm charts
checkov -d ./charts/ --framework helm

Trivy: Combined Vulnerability + Misconfiguration Scan

# Trivy: scan cluster for both CVEs and misconfigurations
trivy k8s --report summary cluster

# Detailed report with misconfig and CVE findings
trivy k8s --report all \
  --format json \
  --output trivy-cluster-report.json \
  cluster

# Scan specific namespace
trivy k8s --namespace production --report all cluster

# Scan Kubernetes manifests for misconfigurations (CI gate)
trivy config ./k8s/ --exit-code 1 --severity HIGH,CRITICAL

OPA Gatekeeper: Policy-as-Code for Compliance

# Gatekeeper ConstraintTemplate: require resource limits (PCI/SOC2/CIS 5.2)
apiVersion: templates.gatekeeper.sh/v1
kind: ConstraintTemplate
metadata:
  name: k8srequiredresources
spec:
  crd:
    spec:
      names:
        kind: K8sRequiredResources
  targets:
  - target: admission.k8s.gatekeeper.sh
    rego: |
      package k8srequiredresources

      violation[{"msg": msg}] {
        container := input.review.object.spec.containers[_]
        not container.resources.limits.memory
        msg := sprintf("Container '%v' must have memory limit", [container.name])
      }

      violation[{"msg": msg}] {
        container := input.review.object.spec.containers[_]
        not container.resources.requests.cpu
        msg := sprintf("Container '%v' must have CPU request", [container.name])
      }

Evidence Collection

Compliance audits require producing evidence that controls are in place and operating effectively. This section provides commands to collect evidence for each major control area.

Access Control Evidence

# List all ClusterRoleBindings (evidence of privilege assignment)
kubectl get clusterrolebindings -o json | \
  jq '.items[] | {name:.metadata.name, role:.roleRef.name, subjects:.subjects}'

# List all users with cluster-admin
kubectl get clusterrolebindings -o json | \
  jq '.items[] | select(.roleRef.name=="cluster-admin") | .subjects[]'

# RBAC permissions for a specific service account
kubectl auth can-i --list \
  --as=system:serviceaccount:production:myapp-sa \
  --namespace production

# All RoleBindings in a namespace
kubectl get rolebindings,clusterrolebindings -n production -o yaml

Encryption Evidence

# Verify API server has encryption config flag
kubectl get pod kube-apiserver-$(hostname) -n kube-system -o yaml | \
  grep encryption-provider-config

# Verify a secret is encrypted in etcd
ETCDCTL_API=3 etcdctl \
  --cacert=/etc/kubernetes/pki/etcd/ca.crt \
  --cert=/etc/kubernetes/pki/etcd/server.crt \
  --key=/etc/kubernetes/pki/etcd/server.key \
  get /registry/secrets/production/db-password | head -c 40
# Must start with: k8s:enc:

# Check KMS health endpoint
kubectl get --raw /healthz/kms-providers

Audit Logging Evidence

# Verify audit logging is enabled
kubectl get pod kube-apiserver-$(hostname) -n kube-system -o yaml | \
  grep -E "audit-log-path|audit-policy-file"

# Show audit policy in use
cat /etc/kubernetes/audit-policy.yaml

# Verify audit logs are being written
ls -lh /var/log/kubernetes/audit/
tail -1 /var/log/kubernetes/audit/audit.log | jq .stageTimestamp

# Count audit events in last hour (proves logging is active)
find /var/log/kubernetes/audit/ -newer /tmp/one-hour-ago | \
  xargs wc -l

Network Security Evidence

# List all NetworkPolicies (evidence of network segmentation)
kubectl get networkpolicies --all-namespaces -o wide

# Verify default-deny exists in sensitive namespaces
kubectl get networkpolicy -n pci-cardholder default-deny-all -o yaml

# Show namespaces WITHOUT NetworkPolicy (compliance gap)
for ns in $(kubectl get namespaces -o jsonpath='{.items[*].metadata.name}'); do
  count=$(kubectl get networkpolicies -n "$ns" --no-headers 2>/dev/null | wc -l)
  if [ "$count" -eq 0 ]; then
    echo "NO NetworkPolicy: $ns"
  fi
done

Generating a Compliance Report

# Generate comprehensive compliance snapshot
#!/bin/bash
REPORT_DIR="compliance-evidence-$(date +%Y%m%d)"
mkdir -p "$REPORT_DIR"

# kube-bench CIS scan
kube-bench run --json > "$REPORT_DIR/kube-bench.json"

# Polaris workload audit
polaris audit --cluster --format json > "$REPORT_DIR/polaris.json"

# Trivy cluster scan
trivy k8s --report all --format json \
  --output "$REPORT_DIR/trivy-cluster.json" cluster

# RBAC snapshot
kubectl get clusterrolebindings -o json > "$REPORT_DIR/clusterrolebindings.json"
kubectl get rolebindings --all-namespaces -o json > "$REPORT_DIR/rolebindings.json"

# NetworkPolicy snapshot
kubectl get networkpolicies --all-namespaces -o json > "$REPORT_DIR/networkpolicies.json"

# Encrypt the evidence package before storing
tar czf - "$REPORT_DIR/" | \
  gpg --symmetric --cipher-algo AES256 \
  > "compliance-evidence-$(date +%Y%m%d).tar.gz.gpg"

echo "Compliance evidence collected in $REPORT_DIR"

Continuous Compliance

Point-in-time compliance scans create gaps between audits. Continuous compliance uses policy enforcement and automated scanning to detect drift immediately.

Kyverno Policy Reports

# Kyverno generates PolicyReport and ClusterPolicyReport CRDs
# Policy Reporter UI provides dashboard over these reports

# View policy violations in a namespace
kubectl get policyreport -n production -o yaml

# View cluster-scoped policy violations
kubectl get clusterpolicyreport -o yaml

# Install Policy Reporter for dashboard
helm install policy-reporter policy-reporter/policy-reporter \
  --namespace policy-reporter \
  --create-namespace \
  --set ui.enabled=true \
  --set kyvernoPlugin.enabled=true

Continuous Compliance Architecture

Admission-Time Enforcement

Kyverno ClusterPolicies / OPA Gatekeeper / ValidatingAdmissionPolicy reject non-compliant resources on creation — prevents drift before it starts.

Background Scan

Kyverno background scanning runs policies against existing resources (not just new admits) and generates PolicyReports for violations — detects drift in resources that pre-date the policy.

Scheduled Scans

kube-bench CronJob runs daily. Trivy Operator continuously re-scans running images. Polaris in audit mode runs weekly. Results shipped to SIEM.

Drift Detection

GitOps (ArgoCD) detects configuration drift from desired state. Any manual kubectl apply that deviates from Git triggers an out-of-sync alert.

# kube-bench CronJob — daily scheduled CIS scan
apiVersion: batch/v1
kind: CronJob
metadata:
  name: kube-bench-daily
  namespace: kube-system
spec:
  schedule: "0 2 * * *"    # Daily at 2 AM
  jobTemplate:
    spec:
      template:
        spec:
          hostPID: true
          nodeSelector:
            node-role.kubernetes.io/control-plane: ""
          tolerations:
          - key: node-role.kubernetes.io/control-plane
            operator: Exists
            effect: NoSchedule
          containers:
          - name: kube-bench
            image: aquasec/kube-bench:v0.7.3
            command: ["kube-bench", "run", "--json"]
            volumeMounts:
            - name: etc-kubernetes
              mountPath: /etc/kubernetes
              readOnly: true
          restartPolicy: Never
          volumes:
          - name: etc-kubernetes
            hostPath: { path: /etc/kubernetes }

Metrics, Alerts & Runbooks

Key Metrics

MetricSourceDescription
kyverno_policy_results_total{result="fail"}KyvernoCompliance policy violations currently active
polaris_scorePolarisOverall workload compliance score (0–100)
kube_bench_failed_checks_totalkube-bench + custom exporterCIS benchmark failed checks by section
trivy_vulnerability_id{severity="CRITICAL"}Trivy OperatorCritical CVEs in running workloads
namespaces_without_network_policyCustom / kube-state-metricsNamespaces with no NetworkPolicy applied

Alerts

# Alert: Compliance policy violations above threshold
- alert: CompliancePolicyViolations
  expr: sum(kyverno_policy_results_total{result="fail",policy_type="validate"}) > 10
  for: 15m
  annotations:
    summary: "More than 10 active compliance policy violations"

# Alert: New namespace without NetworkPolicy
- alert: NamespaceWithoutNetworkPolicy
  expr: namespaces_without_network_policy > 0
  for: 10m
  annotations:
    summary: "Namespace created without NetworkPolicy — open network access"

# Alert: kube-bench FAIL count increased
- alert: CISBenchmarkRegressions
  expr: kube_bench_failed_checks_total > kube_bench_failed_checks_total offset 24h
  annotations:
    summary: "CIS benchmark failure count increased since yesterday — configuration regression"

# Alert: Critical CVE in PCI-scoped namespace
- alert: CriticalCVEInPCIScope
  expr: sum by (namespace, workload) (trivy_vulnerability_id{severity="CRITICAL", namespace="pci-cardholder"}) > 0
  for: 5m
  severity: critical
  annotations:
    summary: "Critical CVE in PCI-scoped workload — immediate remediation required"

Runbooks

New kube-bench CIS Failures

1. Review kube-bench JSON output for FAIL items
2. Map to specific K8s configuration flag or policy
3. Create a PR to fix the configuration via GitOps
4. Re-run kube-bench to verify remediation
5. Document in compliance register if accepted risk

Compliance Audit Preparation

1. Run evidence collection script 2 weeks before audit
2. Review kube-bench output and remediate FAIL items
3. Export Kyverno PolicyReports — address violations
4. Verify audit log retention policy is met
5. Prepare RBAC review documentation

Policy Violation Remediation

1. Query Kyverno PolicyReport: kubectl get policyreport -A
2. Identify resource and owning team
3. Create ticket for remediation with SLA per violation severity
4. For critical violations in PCI scope: immediate escalation

Scope Creep (PCI / HIPAA)

1. Identify new workload/namespace in regulated scope
2. Apply PSA labels, NetworkPolicy, RBAC to new namespace
3. Ensure audit logging covers new namespace
4. Update compliance scope documentation
5. Notify security/compliance team

Audit Log Gap Detected

1. Determine gap window: when did logging stop/restart
2. Check for compliance-reportable events in window (secret access, RBAC changes)
3. Document as compensating control if gap was <15 min
4. File incident report if gap exceeds framework threshold

Best Practices

1

Run kube-bench at cluster provisioning and on every upgrade

CIS benchmark results establish a hardening baseline and catch configuration drift introduced by upgrades. Automate with a CronJob and alert on regression.

2

Encode compliance requirements as Kyverno policies

Policy-as-code means your compliance requirements are version-controlled, reviewed, and continuously enforced — not just documented. Kyverno background: true audits existing resources, not just new admits.

3

Separate regulated workloads into dedicated namespaces

Namespace-level scope isolation (CHD in pci-cardholder, ePHI in hipaa-phi) minimizes the blast radius of a compromise and makes audit scope clear. Apply tighter PSA/NetworkPolicy/RBAC to these namespaces.

4

Automate evidence collection for audit readiness

Scrambling to collect evidence during an audit window is high-risk. Run evidence collection scripts regularly, store outputs in immutable storage, and practice the audit evidence handoff process with your compliance team.

5

Map every compliance requirement to a specific Kubernetes control

The compliance-to-K8s mapping table ensures you can demonstrate coverage to auditors. When a new framework requirement is added, trace it to the K8s control that satisfies it before the audit.

6

Document accepted risks formally

Not every kube-bench FAIL needs immediate remediation — some controls don't apply or have compensating controls. Document accepted risks with a risk owner, justification, and review date. Auditors care more about documented decisions than zero failures.

7

Treat compliance as continuous, not periodic

Point-in-time assessments create a false sense of security. Deploy Kyverno background scanning, Trivy Operator, and GitOps drift detection to maintain compliance posture between audits. Alert on regression, not just on failures at audit time.

8

Use shared controls to satisfy multiple frameworks

Audit logging, RBAC, encryption at rest, and image scanning simultaneously satisfy PCI DSS, SOC 2, HIPAA, and ISO 27001 requirements. Implement each control once with the most stringent requirement in mind, then document it satisfies all applicable frameworks.