Runbook 01 — Kubernetes Compliance Assessment

Purpose

This runbook provides a structured process for performing a Kubernetes security and compliance assessment.

The objective is not simply to run a compliance scanner. A professional assessment determines whether the Kubernetes environment is:

securely configured
aligned with recognized security benchmarks
governed through appropriate policies
properly monitored and auditable
protected against configuration drift
supported by sufficient compliance evidence
operating within organizational security requirements

This runbook can be reused during:

security assessments
compliance reviews
internal audits
Kubernetes platform reviews
pre-production security assessments
cloud security assessments
periodic governance reviews

Operational Principle: Compliance assessment should combine automated evidence with manual validation. A passing scanner result does not automatically mean that a Kubernetes environment is secure.

1. Mission Information

Item	Details
Runbook	Kubernetes Compliance Assessment
Environment	Kubernetes / Managed Kubernetes
Difficulty	Intermediate
Primary Role	Kubernetes Security Engineer
Supporting Roles	Cloud Security Engineer, DevSecOps Engineer, GRC Analyst
Assessment Type	Security & Compliance
Primary Standard	CIS Kubernetes Benchmark
Additional Guidance	NSA/CISA Kubernetes Hardening Guidance
Governance Alignment	NIST / Organizational Security Controls
Assessment Method	Automated + Manual
Output	Kubernetes Compliance Assessment Report

2. Assessment Objectives

The assessment should answer five important questions:

Is the Kubernetes cluster securely configured?
Are workloads deployed according to organizational security requirements?
Are security policies technically enforced?
Can the organization demonstrate compliance using reliable evidence?
Are identified compliance gaps tracked and remediated?

The final assessment should provide both technical findings and management-level compliance visibility.

3. Scope Definition

Before beginning the assessment, clearly establish the scope.

Document:

cluster name
Kubernetes version
cluster type
cloud provider
environment classification
production or non-production status
namespaces included
workloads included
control plane responsibility
node responsibility
applicable security standards
applicable regulatory requirements
assessment date
assessment owner

Example scope:

Cluster: production-k8s-01
Environment: Production
Platform: Managed Kubernetes
Namespaces: All production namespaces
Primary Benchmark: CIS Kubernetes Benchmark
Additional Guidance: NSA/CISA Kubernetes Hardening
Assessment Type: Quarterly Compliance Review

For managed Kubernetes services, clearly identify which control-plane components are managed by the cloud provider.

Do not report provider-managed configuration as a customer failure without first validating the shared responsibility model.

4. Establish the Compliance Baseline

Determine which standards apply to the environment.

Typical baselines may include:

Kubernetes Security

CIS Kubernetes Benchmark
NSA/CISA Kubernetes Hardening Guidance
Kubernetes security best practices

Enterprise Governance

Depending on organizational requirements:

NIST Cybersecurity Framework
NIST SP 800-53
ISO/IEC 27001
SOC 2
PCI DSS
internal security standards
cloud security policies

Create a simple control mapping.

Requirement	Kubernetes Area	Validation
Access Control	RBAC	Role review
Least Privilege	RBAC / Service Accounts	Permission review
Workload Security	Pod Security	Configuration inspection
Network Segmentation	NetworkPolicy	Policy validation
Secrets Protection	Secrets Management	Configuration review
Auditability	Audit Logging	Logging validation
Vulnerability Management	Container Images	Image security review
Configuration Governance	Admission Control	Policy review

5. Collect Cluster Information

Begin with basic environment discovery.

Examples:

kubectl cluster-info

kubectl version

kubectl get nodes -o wide

kubectl get namespaces

kubectl get pods -A

kubectl get deployments -A

Record:

Kubernetes version
node versions
node operating systems
runtime information
namespace inventory
workload inventory

This establishes the environment against which the remaining controls will be evaluated.

6. Review Kubernetes Version Compliance

Determine whether the Kubernetes version is:

currently supported
approved by the organization
receiving security updates
compatible with required security controls

Check:

kubectl version

Review node versions:

kubectl get nodes

Look for:

outdated Kubernetes releases
inconsistent node versions
unsupported versions
delayed security updates

Example finding:

Finding: Unsupported Kubernetes Version

Risk:
Unsupported Kubernetes versions may no longer receive security
patches and can expose the cluster to known vulnerabilities.

Recommendation:
Upgrade the cluster to an organizationally approved and
vendor-supported Kubernetes release.

7. Perform CIS Benchmark Assessment

Where appropriate for the environment, use an approved CIS Kubernetes Benchmark assessment tool such as kube-bench.

The benchmark commonly evaluates areas including:

control plane configuration
API server
controller manager
scheduler
etcd
worker nodes
kubelet
Kubernetes policies

Record results using categories such as:

PASS
FAIL
WARN
INFO
NOT APPLICABLE

Do not automatically classify every failed automated check as a confirmed security issue.

Validate important findings manually.

8. Review API Server Security

The Kubernetes API server is one of the most security-sensitive components of the platform.

Assess:

authentication mechanisms
authorization configuration
anonymous access
admission controllers
audit logging
TLS configuration
insecure endpoints
API exposure

Where you have appropriate administrative access, inspect the relevant cluster or provider configuration.

Questions to answer:

Is anonymous authentication appropriately restricted?
Is RBAC authorization enabled?
Are appropriate admission controls enabled?
Is API access restricted?
Are audit logs available?
Is communication encrypted?

Managed Kubernetes services may abstract some of these settings.

Record those controls as:

Provider Managed

when appropriate rather than treating them as unavailable evidence.

9. Assess RBAC Configuration

Review Kubernetes authorization.

Start with:

kubectl get clusterroles

kubectl get clusterrolebindings

kubectl get roles -A

kubectl get rolebindings -A

Identify:

excessive cluster-admin assignments
wildcard permissions
unnecessary cluster-wide permissions
stale users
stale service accounts
excessive privilege assignments
unnecessary privileged groups

Pay particular attention to permissions containing:

resources: ["*"]
verbs: ["*"]

Wildcard privileges should receive additional scrutiny.

10. Review Cluster Administrator Access

Identify subjects receiving highly privileged access.

kubectl get clusterrolebindings -o yaml

Review bindings associated with:

cluster-admin

Document:

Subject	Type	Role	Business Need	Approved
Platform Admin	Group	cluster-admin	Platform Operations	Yes
CI Service	ServiceAccount	cluster-admin	Unknown	Review

Any unexplained administrative access should become an assessment finding.

11. Assess Service Accounts

Inventory service accounts:

kubectl get serviceaccounts -A

Review:

unnecessary service accounts
privileged service accounts
automatically mounted credentials
service accounts bound to cluster-wide roles
abandoned application identities

Check workload configuration for:

automountServiceAccountToken: false

where Kubernetes API access is unnecessary.

The objective is to minimize unnecessary credential exposure.

12. Assess Pod Security

Review workload security configurations.

Look for workloads using:

privileged: true

Also assess:

runAsNonRoot
allowPrivilegeEscalation
readOnlyRootFilesystem
capabilities
seccompProfile

Review workload specifications:

kubectl get pods -A -o yaml

Look particularly for:

privileged containers
root execution
host networking
host PID access
host IPC access
dangerous capabilities
unrestricted hostPath mounts

13. Review Pod Security Admission

Determine whether Kubernetes Pod Security Standards or equivalent organizational controls are enforced.

Inspect namespace labels:

kubectl get namespaces --show-labels

Look for controls such as:

pod-security.kubernetes.io/enforce
pod-security.kubernetes.io/audit
pod-security.kubernetes.io/warn

Determine whether sensitive namespaces use appropriate policies such as:

restricted

or another approved organizational baseline.

14. Assess Network Segmentation

Inventory NetworkPolicies:

kubectl get networkpolicy -A

Determine whether workloads have appropriate:

ingress restrictions
egress restrictions
namespace isolation
application segmentation

A namespace containing sensitive workloads but no NetworkPolicy should receive additional review.

Document:

Namespace
NetworkPolicy Present
Default Deny
Ingress Restricted
Egress Restricted
Status

15. Review Kubernetes Secrets

Inventory secrets without exposing secret values unnecessarily.

kubectl get secrets -A

Assess:

access permissions
unnecessary secrets
service account token handling
secrets mounted into workloads
external secret management
encryption at rest
secret rotation procedures

Never copy decoded production secrets into the assessment report.

Compliance evidence should demonstrate control effectiveness, not expose credentials.

16. Review Container Image Security

Inventory deployed images:

kubectl get pods -A \
-o jsonpath="{..image}" \
| tr -s '[[:space:]]' '\n' \
| sort \
| uniq

Review organizational requirements for:

approved registries
vulnerability scanning
image signing
immutable image references
base-image governance
image update procedures

Look for uncontrolled use of tags such as:

latest

Production environments should preferably use controlled and traceable image versions.

17. Assess Admission Control

Determine whether admission controls enforce security requirements before workloads enter the cluster.

Possible technologies include:

Kubernetes admission controls
OPA Gatekeeper
Kyverno
cloud-provider policy services

Assess whether policies exist for controls such as:

preventing privileged containers
blocking hostPath usage
requiring resource limits
requiring approved registries
enforcing labels
requiring non-root execution
restricting dangerous capabilities

18. Review Gatekeeper Controls

If Gatekeeper is deployed:

kubectl get constrainttemplates

kubectl get constraints

Review:

active templates
active constraints
enforcement actions
policy coverage
exceptions

Confirm that policies are actually enforcing requirements rather than existing only as unused templates.

19. Review Kyverno Controls

If Kyverno is deployed:

kubectl get clusterpolicies

kubectl get policies -A

Review policy actions such as:

validate
mutate
generate
verifyImages

Determine whether critical policies operate in enforcement mode.

A policy operating only in audit mode may provide visibility without preventing non-compliant workloads.

20. Assess Logging and Auditability

Determine whether sufficient security logging exists.

Review:

Kubernetes API audit logs
authentication logs
authorization activity
workload logs
admission-control events
node security logs
cloud control-plane logs

Confirm logs are forwarded to an appropriate centralized platform.

Examples:

SIEM
Cloud logging platform
Security analytics platform
Centralized log management

Validate:

retention
access control
integrity
alerting
investigation capability

21. Review Monitoring and Detection

Determine whether security-relevant Kubernetes activity can be detected.

Examples include:

privileged workload creation
unexpected administrative access
unusual API activity
suspicious service-account usage
unauthorized configuration changes
abnormal container execution

Compliance should not stop at preventive controls.

A mature Kubernetes environment should support:

Prevent → Detect → Investigate → Respond

22. Assess Namespace Governance

Review namespace organization:

kubectl get namespaces

Determine whether namespaces:

have defined ownership
separate environments appropriately
contain required labels
use resource controls
have network policies
use appropriate Pod Security controls

Create an inventory:

Namespace	Owner	Environment	Network Policy	Pod Security	Status
production	App Team	Production	Yes	Restricted	Compliant
development	Dev Team	Development	Partial	Baseline	Review

23. Review Resource Governance

Check resource quotas:

kubectl get resourcequota -A

Check limit ranges:

kubectl get limitrange -A

Assess whether workloads define appropriate:

resources:
  requests:
  limits:

Resource governance contributes to:

availability
workload stability
capacity management
denial-of-service resilience
tenant isolation

24. Review Kubernetes Configuration Changes

Determine how cluster configuration changes are controlled.

Assess whether organizations use:

Git-based configuration management
Infrastructure as Code
pull-request approval
CI/CD validation
policy-as-code
change management
configuration drift detection

A mature environment should avoid uncontrolled manual production changes.

Expected model:

Developer
   ↓
Git Repository
   ↓
Pull Request
   ↓
Security / Policy Validation
   ↓
Approval
   ↓
Deployment Pipeline
   ↓
Kubernetes

25. Collect Compliance Evidence

Evidence should be collected throughout the assessment.

Examples:

cluster-version.txt
node-inventory.txt
namespace-inventory.txt
rbac-review.txt
network-policy-review.txt
pod-security-review.txt
admission-policy-review.txt
cis-assessment-results.txt
logging-validation.txt
compliance-findings.csv

Evidence should be:

timestamped
attributable
protected
reproducible
stored securely

Avoid storing:

passwords
tokens
private keys
decoded secrets
unnecessary sensitive data

26. Classify Findings

Use a consistent risk model.

Critical

Immediate or severe exposure requiring urgent remediation.

Examples:

uncontrolled administrative access
severe externally exposed management interface
widespread critical privilege failure

High

Major security weakness with significant exploitation potential.

Examples:

unnecessary privileged workloads
excessive cluster-wide permissions
major admission-control gaps

Medium

Important weakness requiring planned remediation.

Examples:

missing NetworkPolicies
incomplete Pod Security enforcement
inconsistent logging

Low

Hardening or governance improvement.

Examples:

missing ownership labels
inconsistent resource limits
minor configuration deviations

Informational

Observation or improvement opportunity without immediate security impact.

27. Create the Findings Register

Use a structured register.

ID	Finding	Severity	Control	Owner	Status
K8S-001	Excessive cluster-admin access	High	Access Control	Platform Team	Open
K8S-002	Missing NetworkPolicy	Medium	Network Security	App Team	Open
K8S-003	Privileged workload detected	High	Workload Security	DevOps	Open
K8S-004	Missing resource limits	Low	Governance	App Team	Open

Every finding should have an accountable owner.

28. Document Each Finding Professionally

Use a consistent structure.

Finding ID

K8S-001

Title

Excessive Cluster Administrator Access

Severity

High

Observation

Multiple identities have been assigned cluster-admin privileges without documented operational justification.

Risk

Compromise of one highly privileged identity could provide broad control over Kubernetes resources and workloads.

Evidence

Record the relevant role-binding information without exposing sensitive credentials.

Recommendation

Review all administrative bindings and replace broad privileges with narrowly scoped RBAC permissions wherever operationally possible.

Owner

Kubernetes Platform Team

Target Date

Defined by organizational remediation SLA

29. Determine Compliance Status

Controls may be classified as:

Compliant
Partially Compliant
Non-Compliant
Not Applicable
Not Assessed
Provider Managed

Example:

Control Area	Status
Kubernetes Version	Compliant
RBAC	Partially Compliant
Pod Security	Non-Compliant
Network Security	Partially Compliant
Secrets Management	Compliant
Admission Control	Compliant
Logging	Compliant
Governance	Partially Compliant

This provides a clearer picture than a simple pass/fail result.

30. Calculate Overall Assessment Results

Summarize:

Controls Assessed: 50
Compliant: 35
Partially Compliant: 8
Non-Compliant: 5
Not Applicable: 2

Do not rely exclusively on a percentage.

A cluster could achieve a high compliance percentage while still containing one Critical security weakness.

Risk severity must therefore remain visible in the final assessment.

31. Prepare the Executive Summary

The executive summary should answer:

What was assessed?
Which standards were used?
What is the overall security posture?
What are the most important findings?
What requires immediate action?

Example:

The Kubernetes environment demonstrates a generally established
security baseline; however, several governance and workload security
gaps require remediation.

The most significant observations involve excessive administrative
permissions, inconsistent network segmentation, and incomplete
workload security enforcement.

Priority remediation should focus on reducing privileged access,
strengthening admission controls, and establishing consistent
namespace security policies.

32. Build the Remediation Plan

Prioritize remediation based on risk.

Immediate

Address:

critical privilege issues
exposed administrative interfaces
dangerous privileged workloads
critical configuration failures

Short Term

Address:

excessive RBAC
missing admission controls
network segmentation gaps
secret-management weaknesses

Medium Term

Improve:

policy-as-code coverage
compliance automation
evidence collection
configuration drift detection
reporting

Continuous

Maintain:

benchmark assessments
vulnerability scanning
policy validation
access reviews
compliance reporting

33. Remediation Validation

A finding should not be closed simply because someone reports that it has been fixed.

Perform validation.

Example workflow:

Finding
   ↓
Remediation
   ↓
Technical Validation
   ↓
Evidence Collection
   ↓
Control Reassessment
   ↓
Finding Closure

Update status:

Open
In Progress
Pending Validation
Closed
Risk Accepted

34. Establish Continuous Compliance

A mature Kubernetes security program moves away from one-time assessments.

Target model:

Code
  ↓
Policy Validation
  ↓
CI/CD Security Checks
  ↓
Admission Control
  ↓
Kubernetes
  ↓
Runtime Monitoring
  ↓
Compliance Reporting

Continuous controls may include:

policy-as-code
configuration scanning
CIS assessments
vulnerability scanning
image validation
drift detection
admission enforcement
centralized logging
automated compliance reporting

The objective is to detect compliance drift before it becomes a long-lived production problem.

35. Recommended Assessment Frequency

Organizations should determine frequency based on risk and regulatory requirements.

A practical model could include:

Activity	Suggested Cadence
Configuration Monitoring	Continuous
Policy Validation	Every Deployment
Vulnerability Assessment	Continuous / Scheduled
Privileged Access Review	Monthly
CIS Benchmark Assessment	Quarterly
Kubernetes Compliance Review	Quarterly
Full Governance Assessment	Annually

These are operational recommendations rather than universal regulatory requirements.

36. Kubernetes Compliance Assessment Checklist

Cluster

Kubernetes version reviewed
Node versions reviewed
Unsupported components identified
Cluster inventory documented

Identity

ClusterRoles reviewed
ClusterRoleBindings reviewed
Administrative privileges reviewed
Service accounts reviewed
Wildcard permissions identified

Workloads

Privileged containers reviewed
Root execution reviewed
Linux capabilities reviewed
hostPath usage reviewed
Pod Security controls reviewed

Network

NetworkPolicies reviewed
Namespace isolation validated
Sensitive workloads segmented
Ingress exposure reviewed

Secrets

Secret access reviewed
Encryption requirements validated
External secret-management controls reviewed
Rotation process reviewed

Images

Container registries reviewed
Vulnerability scanning validated
Image versioning reviewed
Image trust requirements validated

Policy

Admission controls reviewed
Gatekeeper/Kyverno policies reviewed where applicable
Enforcement mode validated
Policy exceptions reviewed

Monitoring

Audit logging validated
Centralized logging confirmed
Security monitoring validated
Alerting capability reviewed

Governance

Namespace ownership documented
Resource governance reviewed
Change-control process reviewed
Compliance evidence collected

37. Required Deliverables

At completion, produce:

1. Kubernetes Compliance Assessment Report

Contains:

scope
environment overview
methodology
standards assessed
findings
risk ratings
recommendations

2. Compliance Control Matrix

Control
Requirement
Evidence
Status
Finding
Owner

3. Findings Register

Finding ID
Severity
Description
Recommendation
Owner
Target Date
Status

4. Evidence Package

Contains sanitized technical evidence supporting assessment conclusions.

5. Remediation Plan

Prioritized remediation activities with accountable owners.

38. Definition of Done

The Kubernetes compliance assessment is complete when:

assessment scope has been documented
applicable standards have been identified
Kubernetes inventory has been collected
CIS controls have been assessed
RBAC has been reviewed
workload security has been reviewed
network security has been assessed
secrets controls have been reviewed
admission controls have been assessed
logging and monitoring have been validated
governance controls have been reviewed
evidence has been collected
findings have been risk rated
remediation owners have been assigned
executive summary has been completed
assessment report has been delivered

Key Takeaways

A professional Kubernetes compliance assessment is more than running a benchmark scanner.

The complete process combines:

Benchmark Assessment
        +
Configuration Review
        +
Identity & RBAC Review
        +
Workload Security
        +
Network Security
        +
Policy Enforcement
        +
Logging & Monitoring
        +
Governance
        +
Evidence
        =
Kubernetes Compliance Assurance

The most important skill is learning to distinguish between:

a failed automated check, a genuine security risk, an accepted architectural decision, and a provider-managed responsibility.

That judgment is what turns compliance scanning into professional Kubernetes security engineering.

What’s Next?

➡️ Runbook 02 — Enterprise Kubernetes Policy Review

In the next runbook, you will move from broad Kubernetes compliance assessment into a focused review of enterprise policy enforcement.

You will assess how Kubernetes security requirements are translated into enforceable technical controls using:

admission control
OPA Gatekeeper
Kyverno
Pod Security Standards
namespace governance
policy exceptions
policy-as-code
deployment pipelines
compliance evidence
continuous policy monitoring

The objective is to determine whether enterprise Kubernetes security policies are merely documented or are actually enforced throughout the workload lifecycle.