A useful Kubernetes security lab must prove that preventive controls reject unsafe workloads and that investigators can explain what happened when a control is bypassed. Installing security tools without exercising policy and evidence does not demonstrate capability.
Direct answer
Build the lab in six layers: cluster and namespace boundaries, identities and RBAC, workload security, network policy, software-supply-chain controls, and audit/runtime evidence. Use synthetic applications and short-lived credentials. Never connect an instructional attack lab to production.
The Kubernetes project publishes both a cluster security checklist and an application security checklist. These are useful baselines because they connect API permissions, Pod Security Standards, network controls, secrets and audit protection.
Lab architecture
Create at least three namespaces:
- a restricted application namespace;
- a controlled test namespace for policy violations; and
- a monitoring namespace with separately protected access.
Use one intentionally vulnerable reference service, one hardened version and a repeatable deployment pipeline. Keep the cloud account and cluster disposable, budget-limited and isolated from organizational networks.
Exercise 1: workload identity and RBAC
Start with no broad permissions. Give each service account only the API actions its workload needs. Disable automatic service-account token mounting when a pod does not need Kubernetes API access.
Test the difference between:
- reading a permitted ConfigMap;
- attempting to read a Secret;
- creating a workload;
- modifying a Role or RoleBinding;
- accessing another namespace.
The lab evidence should include the request identity, policy decision, API response and audit event. The official checklist warns that workload creation permissions can be highly powerful because they may lead to node or credential access.
Exercise 2: Pod Security and security context
Apply Pod Security Admission in warn or audit mode first, inspect violations, then enforce the selected baseline. Test privileged containers, host namespaces, writable root filesystems, added capabilities and disallowed volume patterns.
Configure a non-root user, dropped capabilities, an appropriate seccomp profile and read-only filesystem where the application supports it. Kubernetes documents the available pod and container security-context controls.
Record exceptions explicitly. A blanket relaxation for one incompatible workload weakens every workload in that scope.
Exercise 3: network boundaries
Begin with default-deny ingress and egress where the networking implementation supports enforcement. Add only the flows the service needs: frontend to API, API to database, approved DNS and specific external dependencies.
Prove both positive and negative behavior. A NetworkPolicy file is not evidence until connectivity tests show allowed traffic succeeds and disallowed traffic fails.
Exercise 4: image and delivery controls
Build an image from a pinned base, generate dependency and vulnerability results, publish through a controlled registry and verify provenance or signature before admission. Test an untrusted registry, mutable tag, unsigned artifact and image with a known policy violation.
Decide which finding blocks deployment and which creates a time-bound exception. A scanner that produces thousands of unactioned findings is not an effective control.
Exercise 5: secrets and configuration
Keep secrets out of Git, image layers and ordinary ConfigMaps. Use a controlled secret store or a lab equivalent, short-lived access and encryption appropriate to the environment. Test accidental exposure through environment output, pod descriptions, logs and crash information.
Exercise 6: audit and runtime investigation
Generate a controlled incident: misuse a service account, execute an unexpected process or make a denied API request. Use audit, identity, workload and network signals to build a timeline. The learner should explain the initial access, attempted action, control response, affected objects and containment step.
Protect audit logs from general workload access, as the Kubernetes security checklist recommends. Otherwise the actor being investigated may be able to alter the evidence.
What the learner should submit
- threat model and trust boundaries;
- RBAC and workload-identity matrix;
- policy definitions and negative test results;
- network connectivity evidence;
- artifact and admission evidence;
- incident timeline and remediation backlog.
Practical workshop route
The Cloud and AI Threat Lab introduces attack-path mapping and telemetry decisions. The full security program adds a hardened Kubernetes delivery path and a team incident exercise.
Frequently asked questions
Is RBAC sufficient for Kubernetes security?
No. RBAC governs API actions but must be combined with admission controls, workload security, network boundaries, secrets management, supply-chain controls and runtime detection.
Should a lab use a managed Kubernetes service?
It can, if the account is isolated and spending is controlled. A local cluster is suitable for many policy exercises, but managed-cloud identity and control-plane logging may require a disposable cloud environment.
Does passing a vulnerability scan prove the workload is secure?
No. Scanning addresses one evidence category. Configuration, authorization, network behavior, secrets, application logic and runtime response must also be tested.
View the Cloud and AI Security curriculum or enquire about team delivery.