KCSA — Mitigation Strategies

11 minute read

Threat-to-Mitigation Mapping

The KCSA exam frequently tests your ability to connect threats to the correct Kubernetes security control. This comprehensive table maps every major Kubernetes threat to its mitigation and the specific feature or tool that implements it.

Threat	Mitigation	K8s Feature / Tool
Container escape	Run as non-root, read-only root filesystem, drop all capabilities	`securityContext` (Security Context)
Privilege escalation	Least-privilege RBAC, prevent privileged pods	RBAC, Pod Security Standards (PSS)
Lateral movement	Default-deny network rules, microsegmentation	`NetworkPolicy`
Credential theft	Short-lived tokens, disable auto-mount, external secrets	Projected SA tokens, HashiCorp Vault
Malicious images	Image signing and vulnerability scanning	Cosign (Sigstore), Trivy, Admission Webhooks
Denial of Service	Resource limits per container, quotas per namespace	`LimitRange`, `ResourceQuota`
etcd compromise	Encryption at rest, TLS, restrict network access	`EncryptionConfiguration`, mTLS
API server attack	Strong authentication, RBAC, audit logging	OIDC, RBAC, `--audit-policy-file`
Kubelet exposure	Disable anonymous auth, webhook authorization	Kubelet config, Node Authorization
Exposed Dashboard	Never expose publicly, require auth	`kubectl proxy`, OIDC, NetworkPolicy
Cloud metadata (IMDS)	Block metadata IP, use workload identity	NetworkPolicy, IRSA / Workload Identity
Namespace breakout	Policy enforcement per namespace	NetworkPolicy + RBAC + PSS + ResourceQuota
Admission bypass	Fail-closed webhook, cover all resource types	`failurePolicy: Fail`, broad resource matching
Supply chain	Signed images, private registries, SBOM	Cosign, Notation, Syft

This table is your single most important study reference for the Kubernetes Threat Model domain. Memorize the three-column mapping: Threat → Mitigation → Tool.

Defense-in-Depth for Kubernetes

Defense-in-depth means applying multiple layers of security controls so that if one layer fails, others still protect the system. In Kubernetes, these layers map directly to cluster architecture.

Layer Model

┌─────────────────────────────────────────────────────────┐
│  Layer 1: Cloud / Infrastructure                        │
│  - Cloud IAM, VPC, Security Groups, Private endpoints   │
├─────────────────────────────────────────────────────────┤
│  Layer 2: Cluster                                       │
│  - API server auth, RBAC, Audit logging, Admission      │
├─────────────────────────────────────────────────────────┤
│  Layer 3: Namespace                                     │
│  - NetworkPolicy, ResourceQuota, Pod Security Standards  │
├─────────────────────────────────────────────────────────┤
│  Layer 4: Workload                                      │
│  - Security Context, Image policy, Service mesh mTLS    │
├─────────────────────────────────────────────────────────┤
│  Layer 5: Container                                     │
│  - Non-root, read-only FS, seccomp, AppArmor           │
├─────────────────────────────────────────────────────────┤
│  Layer 6: Code / Application                            │
│  - Input validation, dependency scanning, SAST/DAST     │
└─────────────────────────────────────────────────────────┘

Detailed Layer Breakdown

Layer	Controls	What It Protects Against
Cloud / Infrastructure	VPC isolation, private API endpoint, node hardening, IAM policies, security groups	External access, cloud-level attacks, network exposure
Cluster	API server authentication (OIDC), RBAC authorization, audit logging, admission controllers	Unauthorized API access, RBAC escalation, undetected changes
Namespace	NetworkPolicy (default deny), ResourceQuota, LimitRange, Pod Security Standards	Lateral movement, resource exhaustion, privilege abuse
Workload	Security Context, image scanning, signed images, service mesh (mTLS)	Container escape, malicious images, unencrypted traffic
Container	Non-root user, read-only root filesystem, dropped capabilities, seccomp profile, AppArmor	Host access, filesystem tampering, kernel exploitation
Application	Input validation, WAF, dependency scanning, runtime protection (Falco)	Application-layer attacks, vulnerable dependencies, runtime anomalies

Defense-in-depth means that even if an attacker compromises one layer (e.g., exploits a vulnerable application), they face additional security controls at every subsequent layer (e.g., NetworkPolicy blocks lateral movement, PSS prevents privilege escalation).

Security Context — Container-Level Mitigation

The securityContext is the primary Kubernetes-native mechanism for hardening individual containers and pods.

Pod-Level Security Context

apiVersion: v1
kind: Pod
metadata:
  name: hardened-pod
spec:
  securityContext:
    runAsNonRoot: true
    runAsUser: 1000
    runAsGroup: 3000
    fsGroup: 2000
    seccompProfile:
      type: RuntimeDefault
  containers:
    - name: app
      image: myapp:1.0@sha256:abc123...
      securityContext:
        allowPrivilegeEscalation: false
        readOnlyRootFilesystem: true
        capabilities:
          drop:
            - ALL

Key Security Context Fields

Field	Purpose	Recommended Value
`runAsNonRoot`	Prevents running as root	`true`
`runAsUser`	Sets the user ID	Non-zero (e.g., `1000`)
`readOnlyRootFilesystem`	Prevents writing to the container filesystem	`true`
`allowPrivilegeEscalation`	Prevents gaining additional privileges	`false`
`capabilities.drop`	Removes Linux capabilities	`["ALL"]`
`privileged`	Disables all isolation	`false` (never set to `true`)
`seccompProfile`	Applies syscall filtering	`RuntimeDefault` or custom profile

Pod Security Standards (PSS) — Namespace-Level Mitigation

Pod Security Standards define three profiles that are enforced at the namespace level via Pod Security Admission.

Profile	Description	Use Case
Privileged	No restrictions	System-level workloads (monitoring agents, CNI)
Baseline	Prevents known privilege escalations	General workloads (default recommendation)
Restricted	Heavily restricted, follows hardening best practices	Security-sensitive workloads

Applying PSS to a Namespace

apiVersion: v1
kind: Namespace
metadata:
  name: production
  labels:
    pod-security.kubernetes.io/enforce: restricted
    pod-security.kubernetes.io/audit: restricted
    pod-security.kubernetes.io/warn: restricted

What Each Mode Does

Mode	Behavior
enforce	Rejects pods that violate the policy
audit	Logs violations but allows the pod to be created
warn	Shows a warning to the user but allows the pod

Use enforce: restricted for production namespaces. Use audit and warn first when migrating existing workloads to catch violations without breaking deployments.

RBAC — Authorization Mitigation

RBAC is the primary defense against unauthorized actions in the cluster.

Least-Privilege RBAC Principles

Use Roles over ClusterRoles — Scope permissions to a namespace whenever possible
Avoid wildcards — Explicitly list verbs, resources, and API groups
Use resourceNames — Restrict access to specific named resources
Separate ServiceAccounts — Each workload should have its own SA with minimal permissions
Disable default SA auto-mount — Set automountServiceAccountToken: false on the default SA

# GOOD: Minimal, specific permissions
apiVersion: rbac.authorization.k8s.io/v1
kind: Role
metadata:
  name: pod-reader
  namespace: frontend
rules:
  - apiGroups: [""]
    resources: ["pods"]
    verbs: ["get", "list"]
    # Even better: restrict to specific resourceNames if applicable

# BAD: Overly permissive
apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRole
metadata:
  name: too-much-access
rules:
  - apiGroups: ["*"]
    resources: ["*"]
    verbs: ["*"]

RBAC Audit Commands

# Check what a ServiceAccount can do
kubectl auth can-i --list --as=system:serviceaccount:default:my-sa

# Find all ClusterRoleBindings granting cluster-admin
kubectl get clusterrolebindings -o json | \
  jq '.items[] | select(.roleRef.name=="cluster-admin") | .metadata.name'

# List all subjects with cluster-admin
kubectl get clusterrolebindings -o json | \
  jq '.items[] | select(.roleRef.name=="cluster-admin") | .subjects[]'

NetworkPolicy — Network Mitigation

NetworkPolicies are the primary defense against lateral movement.

Default-Deny Policy

Every namespace should start with a default-deny policy:

# Default deny ALL ingress and egress traffic
apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: default-deny-all
  namespace: production
spec:
  podSelector: {}
  policyTypes:
    - Ingress
    - Egress

After applying default-deny, explicitly allow only the traffic your workloads need.

Allow Specific Traffic

# Allow frontend pods to reach backend pods on port 8080
apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: allow-frontend-to-backend
  namespace: production
spec:
  podSelector:
    matchLabels:
      app: backend
  policyTypes:
    - Ingress
  ingress:
    - from:
        - podSelector:
            matchLabels:
              app: frontend
      ports:
        - protocol: TCP
          port: 8080

Block Cloud Metadata (IMDS)

# Block access to cloud metadata endpoint
apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: deny-cloud-metadata
  namespace: production
spec:
  podSelector: {}
  policyTypes:
    - Egress
  egress:
    - to:
        - ipBlock:
            cidr: 0.0.0.0/0
            except:
              - 169.254.169.254/32

NetworkPolicy requires a CNI plugin that supports it (Calico, Cilium, Weave). The default kubenet CNI does NOT enforce NetworkPolicies — they are silently ignored.

Resource Limits — DoS Mitigation

Resource limits prevent containers from consuming excessive resources, mitigating DoS attacks.

LimitRange (Per-Container Defaults)

apiVersion: v1
kind: LimitRange
metadata:
  name: default-limits
  namespace: production
spec:
  limits:
    - default:
        cpu: "500m"
        memory: "256Mi"
      defaultRequest:
        cpu: "100m"
        memory: "128Mi"
      type: Container

ResourceQuota (Per-Namespace Caps)

apiVersion: v1
kind: ResourceQuota
metadata:
  name: namespace-quota
  namespace: production
spec:
  hard:
    pods: "50"
    requests.cpu: "10"
    requests.memory: "20Gi"
    limits.cpu: "20"
    limits.memory: "40Gi"
    secrets: "20"
    services.nodeports: "0"  # Block NodePort services

Setting services.nodeports: "0" in a ResourceQuota is an effective way to prevent teams from accidentally creating NodePort services — a common attack surface expansion.

Encryption at Rest — etcd Mitigation

Encrypting data at rest in etcd protects Secrets and other sensitive data even if etcd storage is compromised.

EncryptionConfiguration

apiVersion: apiserver.config.k8s.io/v1
kind: EncryptionConfiguration
resources:
  - resources:
      - secrets
      - configmaps
    providers:
      - aescbc:
          keys:
            - name: key1
              secret: <base64-encoded-32-byte-key>
      - identity: {}  # Fallback for reading unencrypted data

The API server must be started with --encryption-provider-config pointing to this file. After enabling encryption, run kubectl get secrets --all-namespaces -o json | kubectl replace -f - to re-encrypt existing Secrets.

Encryption Providers

Provider	Description	Recommended
`identity`	No encryption (default)	No — only for migration
`aescbc`	AES-CBC with PKCS#7 padding	Yes — good balance of security and performance
`aesgcm`	AES-GCM (must rotate keys frequently)	Conditional — requires key rotation infrastructure
`kms`	External Key Management Service	Best — integrates with cloud KMS (AWS KMS, GCP KMS)
`secretbox`	XSalsa20+Poly1305	Yes — strong, simpler than AES

For production clusters, use the KMS provider with a cloud KMS service. This provides hardware-backed key management, automatic key rotation, and audit logging of key usage.

Audit Logging — Detection Mitigation

Audit logging records all API requests, providing visibility into who did what and when.

Audit Policy Levels

Level	What It Records
`None`	Nothing logged
`Metadata`	Request metadata (user, verb, resource, timestamp)
`Request`	Metadata + request body
`RequestResponse`	Metadata + request body + response body

Example Audit Policy

apiVersion: audit.k8s.io/v1
kind: Policy
rules:
  # Log Secret access at RequestResponse level
  - level: RequestResponse
    resources:
      - group: ""
        resources: ["secrets"]
  # Log RBAC changes at Request level
  - level: Request
    resources:
      - group: "rbac.authorization.k8s.io"
        resources: ["clusterroles", "clusterrolebindings", "roles", "rolebindings"]
  # Log all other requests at Metadata level
  - level: Metadata
    omitStages:
      - RequestReceived

Audit logging is essential for detecting threats AND for meeting compliance requirements. Without audit logs, you cannot detect unauthorized API access — and you cannot prove it didn’t happen (repudiation).

CIS Kubernetes Benchmark

The CIS (Center for Internet Security) Kubernetes Benchmark provides prescriptive configuration recommendations for hardening Kubernetes clusters.

Benchmark Categories

Section	Scope	Examples
1. Control Plane	API server, etcd, scheduler, controller manager	Disable anonymous auth, enable audit logging, TLS everywhere
2. etcd	etcd configuration	Client cert auth, peer TLS, restrict file permissions
3. Control Plane Config	Auth, admission, encryption	Enable admission controllers, encryption at rest
4. Worker Nodes	Kubelet, proxy	Disable anonymous kubelet auth, rotate certificates
5. Policies	RBAC, PSS, NetworkPolicy, Secrets	Least-privilege roles, restrict namespace access

Automated Assessment

Use kube-bench to automatically assess CIS Benchmark compliance:

# Run kube-bench on a node
kube-bench run --targets master,node

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

kube-bench outputs [PASS], [FAIL], [WARN] for each CIS check, making it easy to identify gaps. Run it regularly as part of your security assessment process.

Security Controls by KCSA Domain

This table maps security controls to the KCSA exam domains, helping you see how Kubernetes Threat Model mitigations connect to the broader exam.

Security Control	KCSA Domain	Threat It Addresses
RBAC	Kubernetes Security Fundamentals	Unauthorized access, privilege escalation
NetworkPolicy	Kubernetes Security Fundamentals	Lateral movement, data exfiltration
Pod Security Standards	Kubernetes Security Fundamentals	Container escape, privilege escalation
Security Context	Kubernetes Security Fundamentals	Container escape, host access
Admission Controllers	Platform Security	Policy bypass, malicious workloads
Image Scanning	Platform Security	Vulnerable images, supply chain
Encryption at Rest	Platform Security	etcd compromise, Secret exposure
Audit Logging	Compliance & Security Frameworks	Repudiation, undetected access
CIS Benchmark	Compliance & Security Frameworks	Configuration drift, hardening gaps
Service Mesh (mTLS)	Platform Security	Traffic interception, spoofing
Runtime Monitoring	Platform Security	Active attacks, anomalous behavior
Workload Identity	Cloud Native Security	Cloud credential theft, IMDS attacks

Incident Response Basics

When a security incident occurs in a Kubernetes cluster, follow a structured response process.

The Four Phases

Phase	Actions	Kubernetes Context
1. Detect	Identify the incident, assess scope	Audit logs, Falco alerts, monitoring dashboards
2. Respond	Contain the threat, prevent further damage	Isolate pod (NetworkPolicy), revoke credentials, cordon node
3. Recover	Restore normal operations	Redeploy workloads, rotate Secrets, restore from backup
4. Learn	Post-incident review, improve defenses	Update threat model, improve policies, add monitoring

Kubernetes-Specific Response Actions

Isolate a compromised pod:

# Apply a NetworkPolicy that blocks all traffic to/from the compromised pod
apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: isolate-compromised
  namespace: affected-ns
spec:
  podSelector:
    matchLabels:
      app: compromised-app
  policyTypes:
    - Ingress
    - Egress

Cordon a compromised node:

# Prevent new pods from being scheduled on the node
kubectl cordon <node-name>

# Optionally drain the node (migrate existing pods to healthy nodes)
kubectl drain <node-name> --ignore-daemonsets --delete-emptydir-data

Revoke ServiceAccount tokens:

# Delete the ServiceAccount to invalidate all its tokens
kubectl delete serviceaccount compromised-sa -n affected-ns

# Recreate with minimal permissions
kubectl create serviceaccount new-sa -n affected-ns

Do NOT delete the compromised pod or node before collecting forensic evidence. Capture pod logs, container filesystem snapshots, and node state before cleanup.

Mitigation Priority Matrix

When implementing mitigations, prioritize based on impact and effort:

Priority	Mitigation	Impact	Effort
1 (Critical)	Disable anonymous auth (API server + kubelet)	Very High	Low
2 (Critical)	Enable RBAC with least-privilege roles	Very High	Medium
3 (Critical)	Enable etcd TLS + encryption at rest	Very High	Medium
4 (High)	Apply default-deny NetworkPolicy	High	Medium
5 (High)	Enforce Pod Security Standards (Restricted)	High	Medium
6 (High)	Enable audit logging	High	Low
7 (High)	Scan and sign container images	High	Medium
8 (Medium)	Block cloud metadata (IMDS)	Medium	Low
9 (Medium)	Implement ResourceQuota per namespace	Medium	Low
10 (Medium)	Deploy runtime monitoring (Falco)	Medium	High

Key Takeaways for the Exam

Concept	What to Remember
Threat-to-mitigation mapping	Know which K8s feature mitigates which threat (the comprehensive table above)
Defense-in-depth	Six layers: Cloud → Cluster → Namespace → Workload → Container → Application
Security Context	`runAsNonRoot`, `readOnlyRootFilesystem`, `drop ALL capabilities`, `allowPrivilegeEscalation: false`
PSS	Three profiles: Privileged, Baseline, Restricted; three modes: enforce, audit, warn
NetworkPolicy	Default-deny first, then allow specific traffic; requires compatible CNI
CIS Benchmark	Automated with kube-bench; covers control plane, nodes, and policies
Incident Response	Detect → Respond → Recover → Learn; preserve evidence before cleanup
Encryption at rest	KMS provider is best; aescbc/secretbox are acceptable alternatives

The exam tests your ability to select the correct mitigation for a given threat scenario
Know the Kubernetes-native features (Security Context, PSS, NetworkPolicy, RBAC) — these are the primary answer choices
Understand the priority — authentication and RBAC come first, then network, then workload hardening
CIS Benchmark and audit logging are tested in both Threat Model and Compliance domains

Next: Practice Questions →

Share on

Twitter Facebook LinkedIn