Compliance
Mapping Kubernetes security controls to compliance frameworks — CIS Benchmarks, PCI DSS, SOC 2, HIPAA, FedRAMP, and ISO 27001. Automated compliance scanning, evidence collection, continuous compliance monitoring, and gap remediation.
Coverage Checklist
- Compliance frameworks: CIS / PCI DSS / SOC 2 / HIPAA / FedRAMP / ISO 27001
- CIS Kubernetes Benchmark sections and scoring
- kube-bench: automated CIS scan, output formats
- kube-bench in-cluster Job YAML
- PCI DSS requirements mapped to K8s controls
- PCI DSS: network segmentation with NetworkPolicy
- PCI DSS: CHD namespace isolation pattern
- SOC 2 Trust Services Criteria mapped to K8s
- HIPAA § 164.312 technical safeguards
- FedRAMP impact levels and NIST 800-53 controls
- ISO 27001 Annex A controls mapped to K8s
- Kubernetes control mapping master table
- kube-bench automated scanning
- Polaris: workload best practices audit
- Checkov: IaC compliance scanning
- Trivy: combined vuln + misconfig scan
- OPA Gatekeeper: policy-as-code for compliance
- Evidence collection: commands for each control area
- Compliance report generation
- Continuous compliance: Kyverno Policy Reports
- 5 metrics, 4 alerts, 5 runbooks, 8 best practices
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.
Prescriptive configuration recommendations for Kubernetes components. Automated via kube-bench. The technical foundation all other frameworks build on.
Required for any organization that processes, stores, or transmits cardholder data. Strong network segmentation, access control, and audit logging requirements.
AICPA Trust Services Criteria: Security, Availability, Confidentiality, Processing Integrity, Privacy. Audit over a period (typically 6–12 months).
Required for covered entities and business associates handling electronic protected health information. Technical and administrative safeguards.
Based on NIST 800-53. Required for cloud services used by US federal agencies. Three impact levels: Low / Moderate / High.
International standard for ISMS (Information Security Management System). Annex A contains 93 controls mapped to 4 themes.
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
| Section | Component | Key Checks | Auto-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 Check | ID | Implementation |
|---|---|---|
| Disable anonymous API auth | 1.2.1 | --anonymous-auth=false on kube-apiserver |
| Use RBAC authorization | 1.2.7 | --authorization-mode=Node,RBAC |
| Enable audit logging | 3.2.1 | --audit-log-path + --audit-policy-file |
| Encrypt secrets at rest | 1.2.31 | --encryption-provider-config with KMS/secretbox |
| Disable kubelet anonymous auth | 4.2.1 | authentication.anonymous.enabled: false in kubelet config |
| Restrict kubelet API access | 4.2.2 | authorization.mode: Webhook in kubelet config |
| Protect kernel defaults | 4.2.6 | --protect-kernel-defaults=true on kubelet |
| Restrict pod capabilities | 5.2.8 | PSA restricted + securityContext.capabilities.drop: [ALL] |
| Apply NetworkPolicies | 5.3.2 | Default-deny NetworkPolicy + explicit allow policies per namespace |
| Avoid default ServiceAccounts | 5.1.5 | automountServiceAccountToken: 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 Requirement | Kubernetes 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 Control | Description | Kubernetes Evidence |
|---|---|---|
| CC6.1 | Logical access security | RBAC policies, OIDC auth, MFA for cluster access, SA token binding |
| CC6.2 | Access provisioning and deprovisioning | RBAC creation/deletion audit logs; offboarding removes RoleBindings |
| CC6.3 | Least privilege enforcement | RBAC role scope review; rbac-police policy violations; no wildcard permissions |
| CC6.6 | Logical access from outside boundaries | NetworkPolicy egress; API server endpoint restriction; ingress authentication |
| CC6.7 | Encryption of data in transit and at rest | etcd encryption at rest (KMS v2); TLS for all API communications; mTLS |
| CC7.1 | Detection of vulnerabilities | Trivy Operator continuous scanning; Falco runtime detection |
| CC7.2 | Monitoring of security events | Audit logging → SIEM; Falco → alerting; PagerDuty integration |
| CC7.3 | Security incident response | Runbooks; audit log retention; incident response playbooks |
| CC8.1 | Change management | GitOps (ArgoCD); image signing; admission webhooks enforce policy |
| A1.1 | Availability capacity planning | Resource 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 Safeguard | Standard | Kubernetes 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 |
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 Family | Key Controls | Kubernetes Implementation |
|---|---|---|
| AC — Access Control | AC-2, AC-3, AC-6, AC-17 | RBAC; OIDC; least privilege; remote access audit logging |
| AU — Audit & Accountability | AU-2, AU-3, AU-9, AU-12 | Audit logging; log integrity (immutable storage); log coverage |
| CA — Assessment & Authorization | CA-7 | Continuous monitoring; Trivy Operator; kube-bench scheduled scans |
| CM — Configuration Mgmt | CM-2, CM-6, CM-7 | GitOps (ArgoCD); admission webhooks; CIS benchmark hardening |
| IA — Identification & Auth | IA-2, IA-5, IA-8 | OIDC MFA; no static credentials; certificate-based authentication |
| SC — System & Comm Protection | SC-7, SC-8, SC-28 | NetworkPolicy; TLS; encryption at rest |
| SI — System & Info Integrity | SI-2, SI-3, SI-7 | Patch management; image scanning; integrity verification |
ISO 27001:2022
| Annex A Theme | Key Controls | Kubernetes 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 Control | CIS | PCI DSS | SOC 2 | HIPAA |
|---|---|---|---|---|
| RBAC least-privilege | 5.1.x | Req 7 | CC6.1, CC6.3 | §164.312(a) |
| OIDC authentication + MFA | 1.2.2 | Req 8 | CC6.1 | §164.312(d) |
| Audit logging (API server) | 3.2.x | Req 10 | CC7.2 | §164.312(b) |
| Secrets encryption at rest | 1.2.31 | Req 3 | CC6.7 | §164.312(a)(iv) |
| NetworkPolicy default-deny | 5.3.2 | Req 1 | CC6.6 | §164.312(e) |
| mTLS between services | — | Req 4 | CC6.7 | §164.312(e) |
| Image vulnerability scanning | 5.4.x | Req 5, 6 | CC7.1 | §164.312(c) |
| Image signing (Cosign) | — | Req 6 | CC8.1 | §164.312(c) |
| PSA restricted enforcement | 5.2.x | Req 2 | CC6.1 | — |
| Resource quotas + limits | — | — | A1.1 | — |
| PodDisruptionBudgets | — | — | A1.1, A1.2 | — |
| GitOps change control | — | Req 12 | CC8.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
| Metric | Source | Description |
|---|---|---|
kyverno_policy_results_total{result="fail"} | Kyverno | Compliance policy violations currently active |
polaris_score | Polaris | Overall workload compliance score (0–100) |
kube_bench_failed_checks_total | kube-bench + custom exporter | CIS benchmark failed checks by section |
trivy_vulnerability_id{severity="CRITICAL"} | Trivy Operator | Critical CVEs in running workloads |
namespaces_without_network_policy | Custom / kube-state-metrics | Namespaces 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
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.
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.
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.
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.
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.
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.
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.
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.