KCSA — Kubernetes Security Audit
Kubernetes Security Audit
A security audit is a systematic evaluation of a Kubernetes cluster’s security posture. For the KCSA exam, you must understand what to audit, which tools to use, and how the audit process works from scoping through remediation.
What Is a Security Audit?
A security audit is a structured assessment of a system to identify vulnerabilities, misconfigurations, and deviations from security best practices. In the Kubernetes context, it involves examining cluster configuration, workload definitions, access controls, network policies, and operational practices.
Security audits serve three key purposes:
- Identify gaps — find misconfigurations and vulnerabilities before attackers do
- Verify compliance — confirm that the cluster meets required standards (CIS, NIST, organizational policies)
- Establish baselines — document the current security posture for continuous improvement
A security audit is not a one-time event — it should be performed regularly, especially after significant changes to the cluster or workloads.
Kubernetes Audit Checklist
A comprehensive Kubernetes security audit covers multiple areas. The following table maps each area to what should be audited and which tools can help.
| Area | What to Audit | Key Questions | Tools |
|---|---|---|---|
| RBAC | Roles, ClusterRoles, Bindings | Are there wildcard (*) permissions? Over-permissive bindings? cluster-admin usage? |
kubectl, rbac-lookup, rakkess |
| Network | Network Policies, exposed services | Are Network Policies defined for every namespace? Any services exposed unnecessarily? | kubectl, Cilium connectivity test |
| Pods | Security contexts, privileged pods | Are containers running as root? Privileged mode? Missing security contexts? | kube-bench, kubesec, Polaris |
| Secrets | Secret management, encryption | Are Secrets encrypted at rest? Who has access to Secrets? Are they mounted unnecessarily? | kubectl, Vault audit logs |
| Images | Image sources, vulnerabilities | Are images scanned? Using latest tag? Pulling from untrusted registries? |
Trivy, Grype, Snyk |
| Compliance | CIS Benchmark, organizational policies | Does the cluster pass CIS Benchmark checks? Are custom policies enforced? | kube-bench, kube-hunter |
| Logging & Monitoring | Audit logs, monitoring coverage | Is Kubernetes API audit logging enabled? Are logs forwarded to a central system? | kubectl, Falco, ELK/Prometheus |
Security Audit Tools
The KCSA exam expects you to know the purpose and capabilities of key security audit tools. You do not need to know how to install or configure them, but you must understand what each tool does and when to use it.
kube-bench
Purpose: Checks cluster configuration against the CIS Kubernetes Benchmark.
| Aspect | Detail |
|---|---|
| Developer | Aqua Security |
| What it checks | Node configuration files, process flags, file permissions |
| Output | PASS, FAIL, WARN, INFO per CIS recommendation |
| Scope | Runs per-node (control plane or worker) |
| Category | Configuration compliance |
kube-bench answers the question: “Does my cluster configuration meet CIS Benchmark standards?”
kube-hunter
Purpose: Performs penetration testing on Kubernetes clusters to identify security weaknesses.
| Aspect | Detail |
|---|---|
| Developer | Aqua Security |
| What it checks | Network exposure, API server access, known CVEs, information disclosure |
| Output | Discovered vulnerabilities with severity ratings |
| Scope | Network-based (can run from inside or outside the cluster) |
| Category | Penetration testing / vulnerability discovery |
kube-hunter can run in three modes:
| Mode | Description | Use Case |
|---|---|---|
| Remote | Scans from outside the cluster network | Simulates external attacker |
| Internal | Runs as a Pod inside the cluster | Simulates compromised pod |
| Network | Scans an entire network range | Discovers exposed Kubernetes services |
kube-hunter answers the question: “What can an attacker see and exploit in my cluster?”
kubesec
Purpose: Performs risk analysis on Kubernetes resource manifests (YAML/JSON).
| Aspect | Detail |
|---|---|
| Developer | controlplane.io |
| What it checks | Pod specs, security contexts, capabilities, volume mounts |
| Output | Risk score (higher = more risk), with specific findings |
| Scope | Static analysis of manifests (does not require a running cluster) |
| Category | Manifest risk scoring |
Example kubesec findings:
- Running as root (+1 risk)
- Privileged container (+3 risk)
hostNetwork: true(+1 risk)- Read-only filesystem (-1 risk, i.e., reduced risk)
runAsNonRoot: true(-1 risk)
kubesec answers the question: “How risky is this Kubernetes manifest from a security perspective?”
Polaris
Purpose: Validates Kubernetes resources against best practices and custom policies.
| Aspect | Detail |
|---|---|
| Developer | Fairwinds |
| What it checks | Health checks, resource requests/limits, security context, image tags, networking |
| Output | Dashboard with pass/warning/danger ratings; CLI/CI support |
| Scope | Running cluster or static manifests |
| Category | Best practices validation |
Polaris checks go beyond security to include operational best practices:
| Category | Example Checks |
|---|---|
| Security | Running as root, privileged mode, read-only filesystem |
| Reliability | Liveness/readiness probes, resource limits defined |
| Efficiency | CPU/memory requests set, no excessive resource requests |
Polaris answers the question: “Does this workload follow Kubernetes best practices?”
Tool Comparison
Understanding which tool to use for which purpose is critical for the exam.
| Tool | Type | Input | Requires Running Cluster? | Focus |
|---|---|---|---|---|
| kube-bench | CIS compliance checker | Node config | Yes (runs on nodes) | Configuration vs CIS Benchmark |
| kube-hunter | Penetration tester | Network access | Yes (scans live cluster) | Exploitable vulnerabilities |
| kubesec | Manifest scanner | YAML/JSON files | No (static analysis) | Security risk scoring |
| Polaris | Best practices validator | Cluster or manifests | Either | Broad best practices (security + ops) |
If the exam asks “which tool checks configuration against CIS?” → kube-bench. If the exam asks “which tool performs penetration testing?” → kube-hunter. If the exam asks “which tool scores manifest security risk?” → kubesec. If the exam asks “which tool validates Kubernetes best practices?” → Polaris.
The Security Audit Process
A structured audit follows a repeatable process. The five phases ensure thoroughness and accountability.
┌─────────┐ ┌──────────┐ ┌──────────┐ ┌────────────┐ ┌──────────┐
│ SCOPE │──▶│ ASSESS │──▶│ REPORT │──▶│ REMEDIATE │──▶│ VERIFY │
└─────────┘ └──────────┘ └──────────┘ └────────────┘ └──────────┘
Phase 1: Scope
Define what will be audited and what standards apply.
- Which clusters, namespaces, or workloads are in scope?
- Which compliance frameworks apply (CIS, NIST, organizational policy)?
- What is the timeline and resource allocation?
Phase 2: Assess
Run tools and perform manual checks to gather findings.
- Execute kube-bench for CIS compliance
- Run kube-hunter for vulnerability discovery
- Scan manifests with kubesec for risk scoring
- Review RBAC bindings for over-permissive roles
- Check network policies for coverage gaps
- Verify Secret encryption and access controls
- Review image scanning results and policies
Phase 3: Report
Document findings in a structured format.
| Finding Field | Purpose |
|---|---|
| ID | Unique identifier for tracking |
| Severity | Critical, High, Medium, Low, Informational |
| Category | RBAC, Network, Pod Security, Images, etc. |
| Description | What was found |
| Affected Resources | Specific namespaces, pods, roles, etc. |
| CIS/NIST Reference | Mapping to applicable standard |
| Recommendation | How to fix the issue |
| Risk | What happens if unaddressed |
Phase 4: Remediate
Fix identified issues in priority order (Critical → High → Medium → Low).
- Apply configuration changes (update API server flags, kubelet config)
- Tighten RBAC roles (remove wildcards, reduce scope)
- Add Network Policies to uncovered namespaces
- Enable Secret encryption at rest
- Update container images and add security contexts
Phase 5: Verify
Confirm that remediations are effective.
- Re-run kube-bench to verify CIS compliance improved
- Re-run kube-hunter to confirm vulnerabilities are mitigated
- Review updated RBAC bindings
- Test Network Policies for correct enforcement
- Update audit documentation with final results
Audit Reporting Format
A well-structured audit report communicates findings clearly to both technical and non-technical stakeholders.
Executive Summary
Audit Date: 2025-02-01
Cluster: production-us-east-1
Scope: Full cluster audit (CIS Benchmark + RBAC + Network)
Overall Score: 72% compliant (43/60 checks passed)
Critical Issues: 3
High Issues: 7
Medium Issues: 12
Low Issues: 5
Findings by Severity
| Severity | Count | Examples |
|---|---|---|
| Critical | 3 | etcd encryption disabled, cluster-admin bound to default SA, anonymous auth enabled |
| High | 7 | Missing Network Policies in 4 namespaces, 12 pods running as root |
| Medium | 12 | Kubelet read-only port enabled, missing resource limits |
| Low | 5 | Non-specific image tags, missing liveness probes |
Trend Tracking
Track audit results over time to demonstrate security improvement:
| Audit Date | Compliance Score | Critical | High | Medium | Low |
|---|---|---|---|---|---|
| 2024-Q1 | 58% | 8 | 15 | 20 | 12 |
| 2024-Q2 | 65% | 5 | 11 | 16 | 9 |
| 2024-Q3 | 72% | 3 | 7 | 12 | 5 |
Trend data demonstrates continuous improvement — a key goal of any security program and a requirement for frameworks like ISO 27001.
Key Takeaways for the Exam
| Concept | What to Remember |
|---|---|
| Security audit | Systematic evaluation of cluster security posture — not a one-time event |
| Audit areas | RBAC, Network, Pods, Secrets, Images, Compliance, Logging |
| kube-bench | Checks cluster configuration against CIS Benchmark (PASS/FAIL/WARN/INFO) |
| kube-hunter | Penetration testing tool — finds exploitable vulnerabilities from attacker’s perspective |
| kubesec | Risk-scores Kubernetes manifests — static analysis, no running cluster needed |
| Polaris | Best practices validator — covers security AND operational practices |
| Audit process | Scope → Assess → Report → Remediate → Verify |
| Audit report | Should include severity, affected resources, compliance mapping, and recommendations |
| Continuous auditing | Regular audits show improvement trends and maintain compliance |
Next: Compliance Automation
