Kubernetes CIS Benchmark and SOC2 Compliance: A Practical Guide

Compliance in Kubernetes is not about checking boxes — it’s about proving to auditors that your security controls are real, tested, and documented. Whether you’re pursuing SOC2 certification, preparing for a customer security questionnaire, or implementing CIS Benchmark standards, you need a clear mapping between your Kubernetes configuration and the compliance frameworks your organization is held to.

This guide covers both the CIS Kubernetes Benchmark and SOC2 Trust Service Criteria, showing how to map one to the other and automate the verification process.

CIS Kubernetes Benchmark Overview

The CIS (Center for Internet Security) Kubernetes Benchmark is the industry-standard configuration guide for securing Kubernetes clusters. It’s maintained by a community of security professionals and updated for each major Kubernetes release.

Structure

The benchmark is divided into sections:

Section	Scope	Example Controls
1. Control Plane	API server, controller-manager, scheduler, etcd	Audit logging, encryption at rest, authentication
2. etcd	etcd server configuration	TLS, peer auth, file permissions
3. Control Plane Configuration	Authentication, authorization	RBAC, admission controllers
4. Worker Nodes	Kubelet, kube-proxy	Anonymous auth, authorization mode, certificates
5. Policies	Pod security, RBAC, network, secrets	PSS, network policies, service accounts

Scoring Levels

Each control has a scoring level:

• Level 1 (L1): Essential security settings that can be applied without significant operational impact. These are the minimum baseline for any production cluster.
• Level 2 (L2): More restrictive settings that may require application changes or operational adjustments. Required for high-security environments.

Key CIS Controls for Workload Security

The controls most relevant to application teams fall in Section 5 (Policies):

5.1 — RBAC and Service Accounts:

• 5.1.1: Cluster-admin role only used where required
• 5.1.3: Minimize wildcard use in Roles and ClusterRoles
• 5.1.5: Default service accounts not actively used
• 5.1.6: Service Account Tokens only mounted where necessary
• 5.1.8: Limit use of Bind, Impersonate, and Escalate permissions

5.2 — Pod Security:

• 5.2.1: At least one active policy control mechanism (PSS, OPA, Kyverno)
• 5.2.4: Minimize containers with readOnlyRootFilesystem set to false
• 5.2.5: Minimize containers with allowPrivilegeEscalation
• 5.2.7: Minimize admission of root containers
• 5.2.9: Minimize containers with added capabilities
• 5.2.12: Minimize containers without a seccomp profile

5.3 — Network Policies:

• 5.3.2: All namespaces have NetworkPolicies defined

5.4 — Secrets:

• 5.4.1: Prefer using secrets as files over environment variables
• 5.4.2: Consider external secret storage

Run a check against the benchmark right now:

# Using kube-bench (by Aqua Security)
kubectl apply -f https://raw.githubusercontent.com/aquasecurity/kube-bench/main/job.yaml
kubectl logs job/kube-bench

Or run it locally:

kube-bench run --targets master,node

SOC2 Trust Service Categories

SOC2 (System and Organization Controls 2) is an audit framework developed by the AICPA. It evaluates controls across five Trust Service Categories (TSC):

Category	Description	Kubernetes Relevance
Security (CC)	Protection against unauthorized access	RBAC, network policies, pod security, admission control
Availability (A)	System uptime and reliability	PDB, resource limits, autoscaling, DR
Processing Integrity (PI)	Accuracy and completeness of processing	Admission controllers, image signing, audit logging
Confidentiality (C)	Protection of confidential data	Secrets management, encryption at rest, mTLS
Privacy (P)	Personal data handling	Not directly K8s-related, but encryption helps

Most Kubernetes SOC2 controls map to the Security and Availability categories.

Mapping Kubernetes Controls to SOC2 Criteria

Here’s how common Kubernetes security controls map to SOC2 Common Criteria (CC):

CC6.1 — Logical Access Security

“The entity implements logical access security software, infrastructure, and architectures over protected information assets.”

Kubernetes Control	Implementation	Evidence
RBAC enforcement	Namespace-scoped roles, no wildcard permissions	kubectl get clusterrolebindings output
Service account isolation	One SA per workload, automount disabled	Pod specs showing dedicated SAs
Authentication	OIDC integration, no anonymous auth	API server flags, --anonymous-auth=false
Multi-factor auth	OIDC with MFA for cluster access	Identity provider configuration

CC6.3 — Authorization

“The entity authorizes, modifies, or removes access to data, software functions, and other protected information assets.”

Kubernetes Control	Implementation	Evidence
Least privilege RBAC	No cluster-admin except admins	RBAC audit results
Admission control	OPA/Kyverno blocking insecure configurations	Policy list, violation reports
Pod Security Standards	Restricted enforcement on all app namespaces	Namespace labels

CC6.6 — System Boundaries

“The entity implements logical access security measures to protect against threats from sources outside its system boundaries.”

Kubernetes Control	Implementation	Evidence
Network policies	Default deny, namespace isolation	NetworkPolicy resources
Ingress TLS	TLS 1.2+ on all ingress	Ingress resource specs
API server access control	Private endpoint, VPN-only	Cloud provider config
Cloud metadata protection	Block 169.254.169.254	NetworkPolicy blocking link-local

CC7.1 — Monitoring

“The entity monitors system components and the operation of those components for anomalies.”

Kubernetes Control	Implementation	Evidence
Audit logging	API server audit policy, 30-day retention	Audit policy YAML, log samples
Runtime security	Falco with alerting	Falco rules, alert history
Resource monitoring	Prometheus + alerting on anomalies	Alert rules, dashboard screenshots
Centralized logging	Fluent Bit shipping to SIEM	DaemonSet config, log pipeline

CC8.1 — Change Management

“The entity authorizes, designs, develops or acquires, configures, documents, tests, approves, and implements changes.”

Kubernetes Control	Implementation	Evidence
Infrastructure as Code	All manifests in Git	Git repository history
Admission control	Kyverno/OPA blocking non-compliant deploys	Policy violation logs
Image signing	Cosign signatures verified at admission	Verification policy, signed images
CI/CD security scanning	Trivy in pipeline, blocking critical CVEs	Pipeline config, scan results

A1.2 — Recovery

“The entity authorizes, designs, develops or acquires, configures, documents, tests, approves, and implements changes to infrastructure to meet its objectives.”

Kubernetes Control	Implementation	Evidence
etcd backups	Automated encrypted snapshots	CronJob config, backup verification logs
Velero backups	Daily application + volume backups	Velero schedule, restore test logs
PodDisruptionBudgets	PDB for all critical workloads	PDB resources
Disaster recovery drills	Quarterly restore testing	Drill reports, RTO/RPO measurements

Automating Compliance Checks

Manual compliance verification doesn’t scale. Use these tools to automate:

kube-bench (CIS Benchmark)

kube-bench by Aqua Security runs the full CIS Kubernetes Benchmark against your cluster:

# Run as a Kubernetes Job
kubectl apply -f https://raw.githubusercontent.com/aquasecurity/kube-bench/main/job.yaml

# View results
kubectl logs job/kube-bench

# Run for specific targets
kube-bench run --targets master    # Control plane
kube-bench run --targets node      # Worker nodes
kube-bench run --targets policies  # Section 5 (policies)

kube-bench outputs PASS/FAIL/WARN for each control with remediation instructions. Export the results as JSON for your audit evidence folder:

kube-bench run --json > cis-benchmark-results.json

kubescape (Multi-Framework)

kubescape supports CIS Benchmark, NSA-CISA hardening guide, and MITRE ATT&CK frameworks:

# Install
curl -s https://raw.githubusercontent.com/kubescape/kubescape/master/install.sh | /bin/bash

# Run CIS Benchmark scan
kubescape scan framework cis-v1.23-t1.0.1

# Run NSA-CISA scan
kubescape scan framework nsa

# Scan specific namespace
kubescape scan framework cis-v1.23-t1.0.1 --include-namespaces production

# Output as JSON for audit evidence
kubescape scan framework cis-v1.23-t1.0.1 --format json --output cis-results.json

kubescape provides a compliance score (0-100%) and prioritizes findings by severity.

Trivy Operator (Continuous Scanning)

For continuous compliance monitoring, deploy the Trivy Operator:

helm install trivy-operator aquasecurity/trivy-operator \
  --namespace trivy-system --create-namespace \
  --set operator.scanJobsConcurrentLimit=3

It automatically scans running workloads and generates reports:

# View vulnerability reports
kubectl get vulnerabilityreports -A

# View compliance reports
kubectl get clustercompliancereports

Scheduled Compliance Reports

Set up a CronJob to run compliance checks weekly and store results:

# Weekly kube-bench scan
kubectl create cronjob cis-scan \
  --image=aquasec/kube-bench:latest \
  --schedule="0 6 * * 1" \
  -- kube-bench run --json

Evidence Collection for Audits

When an auditor asks “show me your Kubernetes security controls,” you need organized, timestamped evidence. Here’s what to collect:

For CIS Benchmark Compliance

# 1. kube-bench results (JSON)
kube-bench run --json > evidence/cis-benchmark-$(date +%Y%m%d).json

# 2. Network policies across all namespaces
kubectl get netpol -A -o yaml > evidence/network-policies.yaml

# 3. PSS labels on all namespaces
kubectl get namespaces -o jsonpath='{range .items[*]}{.metadata.name}{"\t"}{.metadata.labels}{"\n"}{end}' > evidence/namespace-labels.txt

# 4. RBAC configuration
kubectl get clusterroles,clusterrolebindings -o yaml > evidence/rbac-cluster.yaml
kubectl get roles,rolebindings -A -o yaml > evidence/rbac-namespaced.yaml

# 5. Admission controller configuration
kubectl get validatingwebhookconfigurations -o yaml > evidence/admission-webhooks.yaml
kubectl get clusterpolicies -o yaml > evidence/kyverno-policies.yaml  # If using Kyverno
kubectl get constraints -o yaml > evidence/gatekeeper-constraints.yaml  # If using OPA

# 6. API server configuration (audit policy, encryption)
kubectl get pods -n kube-system -l component=kube-apiserver -o jsonpath='{.items[*].spec.containers[*].command}' > evidence/apiserver-flags.txt

For SOC2 Audits

Organize evidence by Trust Service Criteria:

evidence/
  CC6.1-access-control/
    rbac-cluster.yaml
    rbac-namespaced.yaml
    oidc-configuration.png
  CC6.3-authorization/
    kyverno-policies.yaml
    pss-namespace-labels.txt
    admission-webhooks.yaml
  CC6.6-system-boundaries/
    network-policies.yaml
    ingress-tls-config.yaml
    metadata-block-policy.yaml
  CC7.1-monitoring/
    audit-policy.yaml
    falco-rules.yaml
    prometheus-alerts.yaml
    log-pipeline-config.yaml
  CC8.1-change-management/
    ci-cd-pipeline.yaml
    image-signing-policy.yaml
    trivy-scan-results.json
  A1.2-recovery/
    velero-schedule.yaml
    backup-verification-log.txt
    dr-drill-report.md

Gap Analysis: What Templates Cover vs What You Still Need

The K8s Security Pro template pack covers a significant portion of CIS Benchmark Section 5 (Policies) and SOC2 Security/Availability criteria:

Covered by templates:

• Default deny network policies (CIS 5.3.2)
• Pod Security Standards enforcement (CIS 5.2.1 - 5.2.12)
• RBAC least privilege roles (CIS 5.1.1 - 5.1.8)
• Service account hardening (CIS 5.1.5, 5.1.6)
• Seccomp profiles (CIS 5.2.12)
• Admission control policies — Kyverno and OPA/Gatekeeper (CIS 5.2.1)
• Audit policy (CIS 1.2.18)
• Resource limits and quotas (related to SOC2 Availability)
• PodDisruptionBudgets (SOC2 A1.2)
• Runtime security rules — Falco (SOC2 CC7.1)
• External secrets management (CIS 5.4.2)
• Namespace isolation and egress control (CIS 5.3.2, SOC2 CC6.6)

You still need (outside templates):

• Control plane hardening (CIS Sections 1-3) — these are cluster-level configurations managed by your cloud provider (EKS, GKE, AKS) or kubeadm
• etcd encryption configuration (CIS 1.2.29)
• OIDC/SSO integration for user authentication
• CI/CD pipeline security scanning
• Log aggregation infrastructure (ELK, Splunk, Datadog)
• Backup and disaster recovery infrastructure (Velero)
• Incident response procedures (organizational, not technical)
• Physical security and personnel controls (SOC2 CC6.4, CC6.5)

Continuous Compliance

Compliance is not a one-time audit — it’s an ongoing process. Build compliance into your workflow:

1. Pre-commit: Scan manifests locally with kubescape scan before pushing
2. CI/CD: Run kube-bench and Trivy in your pipeline, fail on critical findings
3. Admission: Use Kyverno/OPA to prevent non-compliant resources from being created
4. Runtime: Deploy Falco for real-time detection and Trivy Operator for continuous scanning
5. Weekly: Automated compliance reports via CronJob, stored as audit evidence
6. Quarterly: Full kube-bench scan, RBAC audit, network policy review, DR drill

This shift-left approach catches compliance violations before they reach production, dramatically reducing the time and cost of audits.

Getting Started

The fastest path to CIS Benchmark compliance for workload security (Section 5) is:

1. Apply default deny network policies to every namespace
2. Enable PSS restricted on all application namespaces
3. Deploy Kyverno or OPA/Gatekeeper with security policies
4. Harden service accounts (disable auto-mount, use projected tokens)
5. Run kube-bench and fix remaining findings

For SOC2, start with the CIS Benchmark foundation and add monitoring (Falco, audit logging), change management (GitOps, admission control), and availability controls (PDB, backups).

The complete CIS Benchmark and SOC2 compliance mappings — with control-by-control coverage analysis, evidence collection commands, and gap identification — are available in the K8s Security Pro Professional and Enterprise tiers. The free Quick-Start Kit includes the 50-point checklist with CIS Benchmark IDs for every control.

---

Related Templates

Implement what you’ve learned with these production-ready YAML templates:

• Template 10: Audit Policy — 16-rule API server audit policy covering secrets, RBAC, exec, and authentication events.
• Template 17: OPA/Gatekeeper Constraint Templates — Admission-time enforcement for resource limits and privileged container blocking.
• Template 19: Kyverno Policy Bundle — 7 ClusterPolicies covering resource limits, non-root, read-only fs, and more.

Related Articles

• Kubernetes Pod Security Standards: From PSP to PSS Migration Guide — Implement the pod security controls required by CIS Section 5.2.
• Kubernetes Network Policies: The Complete Guide to Zero Trust Networking — Satisfy CIS 5.3.2 with comprehensive network segmentation.