Runbook 01 — Kubernetes Compliance Assessment

Kubernetes security is not complete when individual controls are configured.

An enterprise must also be able to answer:

Are our Kubernetes environments
configured according to our
approved security requirements?

That requires a repeatable assessment process.

This runbook provides a professional workflow for evaluating Kubernetes environments against organizational security baselines and applicable compliance requirements.

The objective is not simply:

Find Misconfigurations

The objective is:

Define Requirements
      ↓
Collect Evidence
      ↓
Evaluate Controls
      ↓
Identify Gaps
      ↓
Assess Risk
      ↓
Remediate
      ↓
Validate
      ↓
Maintain Compliance

Runbook Information

Type: Security & Compliance Assessment Runbook

Difficulty: Intermediate to Advanced

Primary Audience:

Kubernetes Security Engineers

Cloud Security Engineers

DevSecOps Engineers

Platform Engineers

Security Consultants

GRC Professionals

Security Architects

Internal Auditors

Primary Skills:

Kubernetes Security Assessment

Compliance Validation

Control Testing

Evidence Collection

RBAC Review

Workload Security

Network Security

Policy-as-Code

Runtime Security

Risk Assessment

Remediation Management

Runbook Mission

You have been asked to assess an enterprise Kubernetes environment.

Management wants to understand:

Is the cluster securely configured?

Are identities properly controlled?

Are workloads hardened?

Is network communication restricted?

Are secrets protected?

Are admission policies enforced?

Can suspicious activity be detected?

Can security controls be demonstrated
with evidence?

Your responsibility is to produce:

Assessment Scope

Control Matrix

Evidence Package

Security Findings

Risk Ratings

Remediation Plan

Compliance Summary

Assessment Principles

A Kubernetes compliance assessment should follow:

Evidence
   +
Risk
   +
Repeatability
   +
Traceability

Avoid assessments based solely on:

Looks Secure

or:

Team Says It Is Configured

Every important conclusion should be supported by evidence.

01 — Define Assessment Scope

Never begin by randomly checking Kubernetes resources.

First define the scope.

Document:

Organization:

Assessment Date:

Assessor:

Environment:

Cluster:

Kubernetes Platform:

Cloud Provider:

Region:

Business Owner:

Technical Owner:

Assessment Type:

Applicable Security Baseline:

Applicable Compliance Requirements:

Example Scope

Environment:
Production

Platform:
Managed Kubernetes

Assessment:
Kubernetes Security and Compliance Review

Included:

Cluster Configuration
Identity and RBAC
Namespaces
Workloads
Network Policies
Secrets
Admission Controls
Logging
Runtime Security

Excluded:

Application Source Code
External SaaS Platforms
Unrelated Cloud Accounts

02 — Define Assessment Boundaries

Identify exactly what is:

In Scope

Out of Scope

Shared Responsibility

Third-Party Managed

This is especially important with managed Kubernetes.

Managed Kubernetes Responsibility

Conceptually:

Cloud Provider
      ↓
Managed Control Plane

Customer
      ↓
IAM
RBAC
Workloads
Nodes
Networking
Secrets
Policies
Logging
Runtime Security

The exact boundary varies by platform.

Document it before assessing controls.

03 — Identify Applicable Requirements

Compliance should start with requirements.

Possible sources include:

Organizational Security Baseline

Kubernetes Hardening Standard

CIS Kubernetes Benchmark

Cloud Security Standards

Internal Policies

Customer Requirements

Regulatory Requirements

Industry Frameworks

Do not automatically assume every control from every framework applies equally.

Control Mapping Model

Requirement
    ↓
Security Control
    ↓
Kubernetes Implementation
    ↓
Evidence
    ↓
Assessment Result

Example

Requirement:
Workloads must operate with least privilege.

Control:
Container privilege restrictions.

Implementation:
securityContext

Evidence:
Deployment manifests

Result:
Pass / Fail / Partial

04 — Build the Control Matrix

Create a working assessment matrix.

ID	Control Area	Requirement	Evidence	Result
K8S-01	Identity	Least privilege	RBAC	TBD
K8S-02	Workload	Non-root	Pod specs	TBD
K8S-03	Network	Segmentation	NetworkPolicy	TBD
K8S-04	Secrets	Restricted access	RBAC/config	TBD
K8S-05	Admission	Guardrails	Policies	TBD
K8S-06	Logging	Audit visibility	Logging config	TBD
K8S-07	Runtime	Threat detection	Runtime tooling	TBD

Use consistent result values such as:

Pass

Partial

Fail

Not Applicable

Not Tested

05 — Verify Assessment Context

Before collecting evidence:

kubectl config current-context

Review:

kubectl cluster-info

Then:

kubectl get nodes

Record:

Cluster:

Context:

Environment:

Node Count:

Assessment Identity:

Important

Compliance assessment access should normally be:

Read-Only

where practical.

Do not change production configuration simply to test whether a control exists.

06 — Establish Evidence Handling

Create a structured evidence model.

Assessment
│
├── 01-Scope
├── 02-Cluster
├── 03-Identity-RBAC
├── 04-Workloads
├── 05-Network
├── 06-Secrets
├── 07-Admission
├── 08-Logging
├── 09-Runtime
├── 10-Findings
└── 11-Remediation

Evidence Rules

Evidence should be:

Relevant

Timestamped

Traceable

Protected

Minimized

Reproducible

Never collect sensitive values unnecessarily.

07 — Review Kubernetes Version

Record the cluster version.

kubectl version

Review node information:

kubectl get nodes -o wide

Assess:

Supported Version?

Upgrade Required?

Known End-of-Support Concern?

Version Consistency?

Node Version Drift?

Version support policies change, so compare the observed version against the current vendor and Kubernetes support policy applicable at assessment time.

08 — Review Cluster Architecture

Document:

Control Plane Model

Worker Nodes

Node Pools

Ingress Architecture

Load Balancers

Container Runtime

Storage Architecture

Identity Integration

Logging Architecture

Runtime Security

Build a simple diagram:

Users
  ↓
Identity Provider
  ↓
Kubernetes API
  ↓
RBAC
  ↓
Namespaces
  ↓
Workloads
  ↓
Services
  ↓
Network
  ↓
External Systems

09 — Review Namespace Architecture

List namespaces:

kubectl get namespaces

Assess whether namespaces provide meaningful separation for:

Applications

Teams

Environments

Security Boundaries

Platform Services

Questions

Are production and development separated?

Are sensitive workloads isolated?

Are system namespaces protected?

Are namespace owners known?

Are abandoned namespaces present?

10 — Review Namespace Governance

Check for:

Ownership

Labels

Resource Quotas

Limit Ranges

Network Policies

Pod Security Controls

Admission Policies

A namespace should not simply exist without governance.

11 — Review Authentication Architecture

Determine how administrators and users authenticate.

Possible mechanisms include:

Enterprise Identity Provider

Cloud IAM

Certificates

Federated Identity

Managed Kubernetes Authentication

Assess:

Centralized Identity

MFA

Lifecycle Management

Shared Credentials

Temporary Access

Privileged Access

12 — Identify Kubernetes Subjects

Review RBAC subjects:

Users

Groups

ServiceAccounts

Security objective:

Named Identity
      +
Business Requirement
      +
Minimum Access

13 — Review ClusterRoleBindings

List:

kubectl get clusterrolebindings

Inspect relevant bindings:

kubectl describe clusterrolebinding <binding-name>

Pay particular attention to bindings involving highly privileged roles.

High-Risk Question

Who Has Cluster-Wide Administrative Access?

14 — Review RoleBindings

List across namespaces:

kubectl get rolebindings -A

Assess:

Subject

Role

Namespace

Business Requirement

Privilege Level

15 — Review Roles and ClusterRoles

List:

kubectl get roles -A

Then:

kubectl get clusterroles

Look for broad permissions such as:

resources: ["*"]

verbs: ["*"]

Wildcards are not automatically vulnerabilities.

They require context and justification.

16 — Review Effective Permissions

For important identities, evaluate effective permissions.

Where authorized:

kubectl auth can-i --list --as=<identity>

For ServiceAccounts:

kubectl auth can-i --list --as=system:serviceaccount:<namespace>:<service-account>

Focus on permissions involving:

Secrets

Pods

Deployments

Jobs

DaemonSets

RBAC

ServiceAccounts

Nodes

Persistent Storage

17 — Review cluster-admin Usage

Identify subjects bound to highly privileged roles.

For each privileged identity document:

Identity:

Type:

Business Requirement:

Owner:

MFA:

Access Method:

Approval:

Review Date:

Finding Example

Finding:
Excessive Cluster Administrative Access

Observation:
Multiple identities possess broad
cluster-wide administrative privileges.

Risk:
Compromise of one privileged identity
could result in cluster-wide impact.

Recommendation:
Reduce administrative assignments,
use group-based access,
implement privileged access controls,
and periodically recertify permissions.

18 — Review Service Accounts

List:

kubectl get serviceaccounts -A

Identify:

Default ServiceAccounts

Application ServiceAccounts

Automation Identities

Privileged ServiceAccounts

Unused ServiceAccounts

Questions

Does every ServiceAccount have an owner?

Does the workload need Kubernetes API access?

Are permissions namespace-scoped?

Is token mounting required?

19 — Review Service Account Token Exposure

Inspect workloads for:

serviceAccountName

automountServiceAccountToken

Security principle:

No API Requirement
      ↓
No Unnecessary API Credential

20 — Review RBAC for Indirect Privilege

Do not review only obvious:

cluster-admin

Some permissions can create indirect privilege.

Review capabilities involving:

Creating Pods

Modifying Workloads

Using Powerful ServiceAccounts

Reading Secrets

Modifying RBAC

Creating Jobs

Creating DaemonSets

Attack Path Thinking

Low-Privilege Identity
      ↓
Create Workload
      ↓
Attach Powerful Identity
      ↓
Gain Additional Access

Compliance assessments should evaluate effective attack paths, not only role names.

21 — Review Workloads

Inventory:

kubectl get deployments -A

Then:

kubectl get daemonsets -A

Then:

kubectl get statefulsets -A

Then:

kubectl get jobs -A

Review representative and high-risk workloads in detail.

22 — Review Runtime User

Inspect whether workloads explicitly implement:

runAsNonRoot

Assess:

Does the workload require root?

Is the requirement documented?

Can the image support non-root?

23 — Review Privileged Containers

Search workload specifications for:

privileged: true

Privileged workloads require strong justification.

Document:

Workload

Namespace

Owner

Reason

Compensating Controls

24 — Review Privilege Escalation

Check:

allowPrivilegeEscalation

Desired standard for ordinary workloads:

false

unless justified.

25 — Review Linux Capabilities

Review:

capabilities

Look for:

Capabilities Added

Capabilities Dropped

Use of ALL

Desired model:

Drop Unnecessary Capabilities
      ↓
Add Only Required Capabilities

26 — Review Seccomp

Assess:

seccompProfile

Determine whether workloads use an approved seccomp configuration.

A common hardened approach is:

RuntimeDefault

where compatible.

27 — Review Filesystem Security

Assess:

readOnlyRootFilesystem

Ask:

Does the application need
the entire root filesystem writable?

Where possible:

Read-Only Root
      +
Explicit Writable Volumes

28 — Review Host Namespace Access

Identify workloads using:

hostNetwork

hostPID

hostIPC

Each should have:

Technical Requirement

Risk Assessment

Owner

Approval

29 — Review hostPath Volumes

Identify:

hostPath

mounts.

Prioritize:

Sensitive Host Paths

Writable Host Paths

Broad Host Filesystem Access

High-Risk Pattern

Privileged Container
      +
Writable hostPath
      ↓
Potential Node-Level Impact

30 — Review Container Images

Collect:

Image Repository

Registry

Tag

Digest

Owner

Assess:

Approved Registry?

Controlled Version?

Image Scanning?

Image Signing/Verification?

Minimal Image?

Known Vulnerabilities?

31 — Review Mutable Tags

Identify production workloads relying on mutable tags such as:

latest

Evaluate organizational policy.

The objective is:

Deployment
      ↓
Known Image
      ↓
Traceable Build

32 — Review Image Pull Policy

Assess whether image retrieval behavior matches the organization’s deployment and supply-chain requirements.

Do not treat one universal setting as correct for every environment.

Consider:

Immutability

Registry Availability

Tag Strategy

Digest Usage

Deployment Process

33 — Review Resource Controls

Check workloads for:

CPU Requests

CPU Limits

Memory Requests

Memory Limits

Missing resource governance can affect:

Availability

Scheduling

Node Stability

Multi-Tenant Reliability

34 — Review ResourceQuota

List:

kubectl get resourcequota -A

Assess whether important namespaces have appropriate resource governance.

35 — Review LimitRange

List:

kubectl get limitrange -A

Determine whether default/minimum/maximum resource policies are appropriate for the environment.

36 — Review Pod Security Standards

Assess whether the organization uses controls aligned with:

Privileged

Baseline

Restricted

Determine the expected security level for:

Application Namespaces

Platform Namespaces

System Workloads

37 — Review Pod Security Admission

Inspect relevant namespace labels:

kubectl get namespaces --show-labels

Look for Pod Security Admission configuration where applicable.

Assess:

Enforce

Audit

Warn

and the organization’s rollout strategy.

38 — Review Network Architecture

Document:

Ingress

Egress

Service Communication

Namespace Communication

External Connectivity

Cloud Network Controls

Network Model

Internet
   ↓
Ingress
   ↓
Service
   ↓
Pod
   ↓
Internal Services
   ↓
External Dependencies

39 — Review NetworkPolicies

List:

kubectl get networkpolicy -A

Identify namespaces with:

No NetworkPolicy

Then determine whether that represents a genuine security gap.

40 — Review Default-Deny Strategy

Assess whether sensitive namespaces use an appropriate default-deny model.

Conceptually:

Default Deny
      ↓
Explicit Required Communication

This reduces unnecessary connectivity.

41 — Review Ingress Controls

Assess:

Public Exposure

TLS

Authentication

Ingress Controller

Allowed Hosts

Sensitive Services

Administrative Interfaces

Ask:

Which applications are Internet-facing?

42 — Review Egress Controls

Determine whether workloads can establish unnecessary outbound connections.

Review:

Internet Egress

Database Access

Cloud Metadata Access

Internal Services

External APIs

Security Principle

Allow Required Communication

rather than:

Allow Everything

43 — Review Namespace Segmentation

Determine whether:

Development

Testing

Production

Sensitive Applications

are appropriately segmented.

Remember:

Namespace
      ≠
Automatic Network Isolation

NetworkPolicy or equivalent controls are required for network segmentation.

44 — Review Kubernetes Secrets

Inventory metadata without exposing secret values:

kubectl get secrets -A

Do not unnecessarily decode production secrets during a compliance assessment.

Review

Secret Type

Namespace

Owner

Workload Usage

RBAC Access

Rotation

Storage Protection

45 — Review Secret RBAC

Determine which identities can:

get

list

watch

Secrets.

Secret access should receive high scrutiny.

46 — Review Secret Storage

Determine whether the environment implements appropriate protection for Kubernetes data at rest.

Review:

Encryption Configuration

Managed Platform Controls

Key Management

Key Rotation

Access Governance

47 — Review External Secret Management

Determine whether sensitive applications use:

Cloud Secret Manager

Enterprise Vault

External Secrets Integration

Other Approved Secret Platform

where required by organizational architecture.

48 — Review Secret Rotation

Ask:

Who Owns the Secret?

When Was It Rotated?

Can It Be Rotated Without Major Downtime?

What Happens After Exposure?

49 — Review Admission Controls

Identify admission-security mechanisms.

Examples may include:

Pod Security Admission

Kyverno

OPA Gatekeeper

Platform-Specific Controls

Assessment Question

Can insecure workloads
be prevented automatically?

50 — Review Kyverno

Where Kyverno is deployed:

kubectl get clusterpolicies

and, where applicable:

kubectl get policies -A

Assess:

Policy Coverage

Audit vs Enforce

Exceptions

Policy Failures

Ownership

Testing

51 — Review OPA Gatekeeper

Where Gatekeeper is deployed, review its constraint templates and constraints using the resource names available in the installed version.

Assess:

Constraint Coverage

Enforcement

Exceptions

Violations

Ownership

52 — Review Admission Policy Coverage

Look for controls addressing requirements such as:

Privileged Containers

Non-Root

Privilege Escalation

Capabilities

Approved Registries

Host Namespaces

HostPath

Resource Requirements

Policy Coverage Matrix

Requirement	Control	Status
Non-root	Admission policy	Pass/Fail
No privileged containers	Admission policy	Pass/Fail
Registry restriction	Admission policy	Pass/Fail
Resource controls	Admission policy	Pass/Fail
Capability restrictions	Admission policy	Pass/Fail

53 — Review Policy Exceptions

Every exception should answer:

Who Requested It?

Why?

Which Workload?

Which Namespace?

What Risk?

Which Compensating Controls?

Who Approved It?

When Does It Expire?

Red Flag

Permanent Exception
+
No Owner
+
No Expiration

54 — Review Kubernetes Audit Logging

Determine whether Kubernetes API activity is appropriately logged.

Important event categories include:

Authentication

Authorization

Resource Creation

Resource Modification

Resource Deletion

Secret Access

RBAC Changes

pods/exec

55 — Review Log Centralization

Assess whether relevant logs are centralized.

Kubernetes
   ↓
Audit Logs
   +
Node Logs
   +
Container Logs
   +
Application Logs
   +
Cloud Logs
      ↓
Central Logging / SIEM

56 — Review Log Protection

Ask:

Can Workload Administrators Delete Security Logs?

Are Logs Retained?

Are Logs Protected From Modification?

Is Access Monitored?

Are Timestamps Consistent?

57 — Review Detection Coverage

Determine whether the environment can detect:

Unexpected Privileged Workloads

Suspicious RBAC Changes

Secret Access

Unexpected Shell Execution

Suspicious Processes

Unusual API Activity

Unexpected Network Connections

58 — Review Runtime Security

Determine whether runtime monitoring exists.

Examples may include technologies capable of observing:

Processes

System Activity

File Access

Network Behavior

Container Events

The assessment should evaluate capability rather than requiring one specific vendor.

59 — Review Runtime Detection Rules

Ask:

Which Behaviors Are Detected?

Who Owns the Rules?

Where Are Alerts Sent?

How Are Alerts Investigated?

How Are False Positives Tuned?

How Are Detection Gaps Tracked?

60 — Review Runtime Alert Integration

Desired architecture:

Runtime Sensor
      ↓
Security Alert
      ↓
SIEM / Monitoring
      ↓
SOC
      ↓
Investigation Runbook

Detection without response capability provides limited value.

61 — Review Kubernetes Incident Readiness

Determine whether the organization has procedures for:

Compromised Pod

Compromised ServiceAccount

Suspicious RBAC Change

Malicious Image

Node Compromise

Secret Exposure

Runtime Alert

62 — Review Forensic Readiness

Determine whether investigators can obtain:

Kubernetes Audit Logs

Container Logs

Runtime Alerts

Cloud Logs

Network Logs

Workload Manifests

Image Information

RBAC Configuration

Relevant Node Evidence

63 — Review Backup and Recovery

Assess:

Cluster State Backup

Application Data Backup

Configuration Recovery

Secret Recovery

Disaster Recovery

Restore Testing

A backup that has never been tested may not provide reliable recovery assurance.

64 — Review Change Management

Determine how Kubernetes changes reach production.

Expected model:

Change
  ↓
Review
  ↓
Security Validation
  ↓
Approval
  ↓
Deployment
  ↓
Monitoring

65 — Review GitOps / IaC Governance

Where Kubernetes resources are managed through:

GitOps

Helm

Terraform

Kustomize

CI/CD

review:

Repository Access

Pull Request Approval

Pipeline Identity

Secret Handling

Policy Checks

Deployment Authorization

66 — Review Supply-Chain Controls

Assess:

Source
  ↓
Dependencies
  ↓
Build
  ↓
Image
  ↓
Registry
  ↓
Admission
  ↓
Runtime

For each stage ask:

Who Can Modify It?

How Is Integrity Validated?

What Evidence Exists?

67 — Review Node Security

Assess node-level controls appropriate to the platform.

Consider:

Operating System Hardening

Patch Management

Administrative Access

Container Runtime

Endpoint/Runtime Monitoring

Network Exposure

Cloud IAM

Disk Protection

68 — Review Node Access

Determine:

Who Can Access Nodes?

How?

Is MFA Required?

Is Access Logged?

Are Shared Accounts Used?

Is Emergency Access Controlled?

69 — Review Cloud Integration

For managed Kubernetes, review the connection between:

Cloud IAM
      +
Kubernetes RBAC

An identity may have important permissions outside Kubernetes itself.

Cloud Attack Path

Workload
   ↓
Cloud Identity
   ↓
Cloud API
   ↓
Storage / Secrets / Databases

Kubernetes compliance assessments should not ignore cloud workload identities.

70 — Review Workload Identity

Determine how workloads access cloud resources.

Assess:

Dedicated Identity

Least Privilege

Credential Lifetime

Static Keys

Federated Identity

Auditability

Prefer designs that avoid long-lived embedded cloud credentials where supported.

71 — Review Multi-Tenancy

If multiple teams or tenants share a cluster, assess:

Namespace Isolation

RBAC

Network Isolation

Resource Isolation

Admission Controls

Secret Isolation

Node Isolation

Logging

Important

Kubernetes namespaces alone should not automatically be treated as a complete hostile multi-tenant isolation boundary.

72 — Review Security Ownership

Every major security control should have an owner.

Example:

Control	Owner
Cluster configuration	Platform Team
RBAC	Platform + Security
NetworkPolicy	Platform/Application
Admission policies	Security Platform
Runtime detection	Security Operations
Secrets	Application + Security
Compliance evidence	GRC/Security

Without ownership:

Security Gap
      ↓
Nobody Fixes It

73 — Review Security Exceptions

Create an exception register.

Exception ID:

Control:

Workload:

Namespace:

Reason:

Risk:

Compensating Control:

Owner:

Approver:

Created:

Expiration:

Status:

74 — Build the Compliance Scorecard

Summarize each domain.

Domain	Status
Cluster Security	Pass / Partial / Fail
Identity & RBAC	Pass / Partial / Fail
Workload Security	Pass / Partial / Fail
Network Security	Pass / Partial / Fail
Secrets	Pass / Partial / Fail
Admission Controls	Pass / Partial / Fail
Logging	Pass / Partial / Fail
Runtime Security	Pass / Partial / Fail
Incident Readiness	Pass / Partial / Fail

Avoid hiding serious failures behind a simple percentage.

75 — Create Security Findings

Every failed control should be evaluated for risk.

Use:

Control Failure
      ↓
Threat Scenario
      ↓
Potential Impact
      ↓
Likelihood
      ↓
Risk

Finding Template

Finding ID:

Title:

Affected Environment:

Affected Resources:

Control Requirement:

Observation:

Evidence:

Threat Scenario:

Business Impact:

Likelihood:

Severity:

Recommendation:

Owner:

Target Date:

Status:

76 — Example Finding: Excessive RBAC

Finding ID:
K8S-001

Title:
Excessive Kubernetes Administrative Access

Observation:
Multiple identities possess broad
cluster-wide administrative permissions.

Threat Scenario:
Compromise or misuse of one identity
could provide extensive control over
cluster resources.

Impact:
Cluster-wide unauthorized modification,
data exposure, or service disruption.

Severity:
High

Recommendation:
Apply least privilege, remove unnecessary
administrative bindings, use controlled
privileged access, and implement periodic
access reviews.

77 — Example Finding: Missing Network Segmentation

Finding ID:
K8S-002

Title:
Insufficient Kubernetes Network Segmentation

Observation:
Sensitive application namespaces do not
have documented network restrictions.

Threat Scenario:
A compromised workload may communicate
with services that are not required for
its business function.

Impact:
Increased lateral movement opportunities.

Severity:
High

Recommendation:
Implement an appropriate default-deny
strategy and explicitly allow required
application communication.

78 — Example Finding: Workload Hardening

Finding ID:
K8S-003

Title:
Inconsistent Kubernetes Workload Hardening

Observation:
Multiple workloads do not explicitly
implement the organization's expected
container security controls.

Risk Areas:

Non-Root

Privilege Escalation

Capabilities

Filesystem Protection

Seccomp

Recommendation:
Define a standard workload-security
baseline and enforce applicable controls
through admission policy.

79 — Example Finding: Runtime Visibility

Finding ID:
K8S-004

Title:
Insufficient Runtime Threat Detection

Observation:
The environment lacks consistent detection
for suspicious container runtime behavior.

Threat Scenario:
An attacker exploiting an application may
execute post-compromise activity without
timely detection.

Severity:
High

Recommendation:
Implement runtime telemetry and prioritized
behavioral detections integrated with
central security monitoring.

80 — Risk Prioritization

Prioritize findings based on:

Privilege

Exploitability

Internet Exposure

Data Sensitivity

Network Reachability

Identity Permissions

Business Criticality

Existing Compensating Controls

Example

Privileged Container
+
Writable Host Mount
+
Production

should normally receive more attention than:

Missing Non-Security Metadata Label

81 — Identify Attack Paths

Do not treat findings only as isolated problems.

Connect them.

Example:

Internet-Facing Application
        ↓
Application Vulnerability
        ↓
Privileged Container
        ↓
Powerful ServiceAccount
        ↓
Broad Network Access
        ↓
Sensitive Services

Five individual findings may form:

One Critical Attack Path

82 — Build the Remediation Plan

For each finding define:

Finding

Priority

Owner

Action

Dependencies

Target Date

Validation Method

Status

Example

Finding	Priority	Owner	Action
Excessive RBAC	High	Platform	Reduce bindings
Missing NetworkPolicy	High	Platform	Implement segmentation
Privileged workload	High	App Team	Harden workload
Missing runtime detection	High	Security	Implement detections

83 — Validate Remediation

Never close findings based only on:

Developer Says Fixed

Use:

Remediation
      ↓
Collect New Evidence
      ↓
Retest
      ↓
Compare Requirement
      ↓
Close or Reopen

Validation Record

Finding ID:

Original Evidence:

Remediation:

Validation Evidence:

Validation Date:

Validated By:

Result:

Closed:
Yes / No

84 — Handle Accepted Risk

Not every issue can be remediated immediately.

If risk is accepted:

Finding
   ↓
Risk Assessment
   ↓
Business Owner
   ↓
Formal Approval
   ↓
Expiration
   ↓
Periodic Review

Risk acceptance should not become:

Permanent Ignore List

85 — Executive Reporting

Leadership usually needs:

What Is the Overall Risk?

What Are the Top Findings?

Which Systems Are Affected?

What Could Happen?

What Must Be Fixed First?

Who Owns Remediation?

Avoid overwhelming executives with raw Kubernetes YAML.

Executive Summary Template

Assessment:
Kubernetes Security & Compliance Assessment

Overall Risk:
Moderate / High / Critical

Critical Findings:

High Findings:

Medium Findings:

Key Themes:

Immediate Actions:

Strategic Improvements:

Assessment Conclusion:

86 — Technical Reporting

Technical teams need:

Exact Resource

Namespace

Evidence

Expected State

Observed State

Risk

Remediation

Validation Procedure

Provide enough information to reproduce and remediate the issue without exposing unnecessary sensitive information.

87 — Evidence Package

The final evidence package may contain:

01 Scope

02 Architecture

03 Cluster Inventory

04 RBAC Evidence

05 Workload Evidence

06 Network Evidence

07 Secrets Assessment

08 Admission Policies

09 Logging Evidence

10 Runtime Security Evidence

11 Findings

12 Remediation Tracker

88 — Continuous Compliance

A one-time assessment is useful.

But Kubernetes changes constantly.

Developer
   ↓
New Deployment

Platform Team
   ↓
Configuration Change

Security Team
   ↓
New Policy

Kubernetes
   ↓
Version Upgrade

Therefore compliance should become continuous.

Continuous Model

DEFINE
   ↓
AUTOMATE
   ↓
MONITOR
   ↓
DETECT DRIFT
   ↓
REMEDIATE
   ↓
REPORT

89 — Automate Control Validation

Controls that can be reliably automated should increasingly move into:

CI/CD Checks

Admission Policies

Configuration Scanning

Cloud Security Monitoring

Runtime Detection

Compliance Dashboards

Example

Instead of manually discovering:

Privileged Container

after deployment:

Deployment Request
      ↓
Admission Policy
      ↓
Reject

90 — Compliance Drift

A compliant environment today may become non-compliant tomorrow.

Drift can occur because of:

Emergency Changes

Manual Changes

New Applications

Policy Exceptions

Cluster Upgrades

New Administrators

Configuration Errors

Continuous validation helps identify drift.

91 — Assessment Frequency

Assessment frequency should be risk-based.

Possible triggers include:

Scheduled Security Review

Major Cluster Upgrade

Production Launch

Significant Architecture Change

Security Incident

New Compliance Requirement

Acquisition or Migration

92 — Kubernetes Compliance Maturity

Level 1 — Reactive

Manual Checks

Limited Standards

Few Guardrails

Level 2 — Defined

Documented Baseline

Regular Assessments

Assigned Owners

Level 3 — Automated

Policy-as-Code

Automated Validation

Central Monitoring

Level 4 — Continuous

Continuous Compliance

Drift Detection

Integrated Evidence

Risk-Based Remediation

Level 5 — Optimized

Security Engineering

Threat-Informed Controls

Automated Governance

Metrics-Driven Improvement

93 — Key Compliance Metrics

Track meaningful metrics such as:

Privileged Workloads

Workloads Running as Root

Excessive RBAC Bindings

Namespaces Without Required Network Controls

Policy Violations

Expired Exceptions

Unresolved Critical Findings

Mean Time to Remediate

Unsupported Cluster Versions

Runtime Detection Coverage

Metrics should drive action, not merely populate dashboards.

94 — Assessment Completion Checklist

Scope

Cluster

Identity

Workloads

Supply Chain

Network

Secrets

Admission

Pod security controls reviewed
Kyverno reviewed where applicable
Gatekeeper reviewed where applicable
Policy coverage assessed
Exceptions reviewed

Monitoring

Incident Readiness

Incident procedures reviewed
Evidence availability reviewed
Forensic readiness reviewed
Recovery capability reviewed

Reporting

Professional Deliverables

At completion, produce:

Kubernetes Compliance Assessment Report

Control Assessment Matrix

RBAC Review

Workload Security Review

Network Security Review

Admission Policy Review

Runtime Security Review

Evidence Package

Risk Register

Remediation Tracker

Executive Summary

Interview Questions

What is a Kubernetes compliance assessment?
How is compliance different from security?
Why should assessment scope be defined first?
What is a control matrix?
What constitutes good compliance evidence?
Why should assessment access preferably be read-only?
How do you assess Kubernetes version risk?
How do managed Kubernetes responsibilities affect assessments?
What should be reviewed in ClusterRoleBindings?
Why are wildcard RBAC permissions risky?
What is indirect Kubernetes privilege?
Why should ServiceAccounts be reviewed?
What is the risk of unnecessary ServiceAccount tokens?
How would you review workloads for root execution?
Why are privileged containers important compliance findings?
What does allowPrivilegeEscalation control?
Why review Linux capabilities?
Why review seccomp?
What is the risk of hostPath?
Why are host namespaces security-sensitive?
How do Pod Security Standards support compliance?
What is Pod Security Admission?
Why are NetworkPolicies important?
Why does a namespace not automatically provide network isolation?
What is a default-deny strategy?
Why should egress be reviewed?
How should Kubernetes Secrets be assessed?
Why is base64 not sufficient protection?
Why is secret rotation important?
What are admission controls?
How can Kyverno support compliance?
How can OPA Gatekeeper support compliance?
Why must policy exceptions be governed?
Why is Kubernetes audit logging important?
What runtime behaviors should security teams detect?
Why is runtime monitoring part of compliance readiness?
What is forensic readiness?
Why should backup restoration be tested?
How does GitOps improve governance?
Why should container-image provenance be assessed?
How does cloud IAM interact with Kubernetes RBAC?
What is workload identity?
Why is multi-tenancy difficult in Kubernetes?
How should security findings be risk-rated?
What is an attack path?
Why should remediation be independently validated?
What is risk acceptance?
What is compliance drift?
What is continuous compliance?
How would you present Kubernetes security risk to executives?

Runbook Readiness Milestone

You should now be able to approach an unfamiliar Kubernetes environment and follow:

SCOPE
  ↓
REQUIREMENTS
  ↓
ARCHITECTURE
  ↓
IDENTITY
  ↓
WORKLOADS
  ↓
NETWORK
  ↓
SECRETS
  ↓
ADMISSION
  ↓
LOGGING
  ↓
RUNTIME
  ↓
INCIDENT READINESS
  ↓
EVIDENCE
  ↓
FINDINGS
  ↓
REMEDIATION
  ↓
VALIDATION

Final Professional Mental Model

A Kubernetes compliance assessment is not:

Run Scanner
   ↓
Export Findings
   ↓
Done

A professional assessment is:

Understand Business Requirements
        ↓
Understand Architecture
        ↓
Evaluate Security Controls
        ↓
Collect Defensible Evidence
        ↓
Identify Real Risk
        ↓
Connect Attack Paths
        ↓
Prioritize Remediation
        ↓
Validate Improvements

Runbook Outcome

Before this runbook:

You knew how to implement
individual Kubernetes
security controls.

After this runbook:

You can systematically assess
an enterprise Kubernetes environment,

evaluate security controls,

collect evidence,

identify compliance gaps,

analyze attack paths,

document risk,

prioritize remediation,

and validate corrective actions.

You have moved from:

Kubernetes Security Implementation

to:

Kubernetes Security Assurance
and Compliance Assessment.

What’s Next?

➡️ Runbook 02 — Kubernetes Forensics

In the next runbook, you will move from:

Is the Kubernetes Environment
Secure and Compliant?

to:

What Happened Inside
This Kubernetes Environment?

You will build a repeatable forensic workflow covering:

Incident Scoping

Timeline Reconstruction

Kubernetes Audit Logs

Pod and Container Evidence

Workload Configuration

Service Accounts

RBAC Activity

Runtime Evidence

Network Evidence

Node Evidence

Container Images

Evidence Preservation

Root Cause Analysis

Attack Path Reconstruction

Forensic Reporting

The runbook progression becomes:

Runbook 01
Kubernetes Compliance Assessment
        ↓
Evaluate Security Posture

Runbook 02
Kubernetes Forensics
        ↓
Reconstruct Security Events

Runbook 03
Kubernetes Incident Response
        ↓
Contain and Recover

You are now ready to move from Kubernetes security assurance into Kubernetes forensic investigation.