DevOps & Kubernetes Security Labs - CKS

Master Kubernetes cluster security with hands-on, PBQ-style labs: Pod Security Standards & admission control, Network Policies & cluster isolation, and image scanning & supply chain security - aligned to the Certified Kubernetes Security Specialist (CKS) exam objectives.

These labs cover all DevOps & container certifications including:

KCNA DCA KCSA Terraform Associate CKAD
CKA CKS AWS DevOps Professional Azure DevOps AZ-400 Google Prof. Cloud DevOps

CKS Security Labs - Module 7

Kubernetes security labs with pod security admission, network isolation policies, and image vulnerability scanning - build real cluster security skills aligned to the CKS exam.

Lab 19: Pod Security Standards & Admission
Kubernetes / GUI + Terminal
Scenario: Enforce Pod Security Standards
The security team requires all pods in the production namespace to comply with the restricted Pod Security Standard. Configure the namespace labels for PSA enforcement, create a compliant pod spec (non-root, read-only filesystem, drop all capabilities), and verify that non-compliant pods are rejected.
CKS Lab

Learning Objectives:

  • Pod Security Standards: privileged, baseline, restricted levels
  • PSA labels: enforce, audit, warn modes on namespaces
  • SecurityContext: runAsNonRoot, readOnlyRootFilesystem, capabilities
  • Admission testing: verify non-compliant pods are rejected

Step-by-Step Instructions

  1. Step 1: Configure PSA labels
    In the Security Console tab, set:
    Namespace = production PSS Level = restricted Mode = enforce
    Then click Apply PSA Labels.
  2. Step 2: Configure SecurityContext
    Set the pod security context:
    runAsNonRoot = true readOnlyRootFilesystem = true Drop capabilities = ALL
    Then click Set SecurityContext.
    Tip: The restricted PSS requires non-root, read-only FS, and drop ALL capabilities.
  3. Step 3: Generate compliant Pod YAML
    Click Generate YAML to render the PSA labels + compliant pod spec.
  4. Step 4: Apply configuration
    Click Apply to create the namespace labels and compliant pod.
  5. Step 5: Verify PSA enforcement
    In the Terminal tab, test a non-compliant pod:
    kubectl run bad-pod --image=nginx --namespace=production
    Expected: Pod should be rejected because it runs as root and violates restricted PSS.
  6. Step 6: Verify compliant pod
    Confirm the compliant pod is running:
    kubectl get pods -n production
    Expected: secure-app pod in Running state.

CKS Lab Environment

Security Console
Terminal
Pod Security Admission Controller Cluster: cks-lab
PSA Namespace Labels
Pod SecurityContext
Namespace PSA
Namespace--
PSS Level--
Mode--
Pod Security
NonRootNo
ReadOnly FSNo
Drop CapsNo
AppliedNo
Activity Log
[system]Pod Security Admission controller ready. No PSA labels configured.
root@k8s-secure:~#
Progress: 0/6 tasks completed
Score: 0/100
After Completing All Steps:

1. Click "Validate Configuration" for a PSA compliance checklist.
2. Click "View Architecture" to see the PSA enforcement flow.
3. Reset the lab to re-practice pod security patterns.
0%

Lab Completed!

Pod Security Standards enforced successfully.

Lab 20: Network Policies & Cluster Isolation
Kubernetes / Terminal + GUI
Scenario: Microsegmentation with Network Policies
The payments namespace handles sensitive financial data. Create a default-deny ingress policy, then allow traffic only from the api-gateway pods in the frontend namespace on port 8443. Verify that other pods cannot reach the payments service.
CKS Lab

Learning Objectives:

  • Default deny: block all ingress traffic by default
  • Label selectors: allow traffic from specific pods
  • Namespace selectors: cross-namespace policy rules
  • Port filtering: restrict to specific ports

Step-by-Step Instructions

  1. Step 1: Create default-deny policy
    In the Terminal tab, apply a default-deny ingress policy:
    kubectl apply -f deny-all-ingress.yaml
    Tip: A default-deny policy blocks ALL ingress traffic to pods in the namespace.
  2. Step 2: Create allow policy for api-gateway
    In the Network Policy Console tab, configure:
    Source Namespace = frontend Source Pod Label = app=api-gateway Port = 8443
    Then click Create Allow Policy.
  3. Step 3: Generate NetworkPolicy YAML
    Click Generate YAML to render the allow policy manifest.
  4. Step 4: Apply network policies
    Click Apply to create the network policy in the cluster.
  5. Step 5: Test allowed traffic
    In the Terminal, verify api-gateway can reach payments:
    kubectl exec -n frontend api-gateway -- curl -s payments.payments:8443/health
    Expected: 200 OK - connection allowed by network policy.
  6. Step 6: Test denied traffic
    Verify unauthorized pods are blocked:
    kubectl exec -n default test-pod -- curl -s --max-time 3 payments.payments:8443/health
    Expected: Connection timed out - traffic blocked by default-deny.

CKS Lab Environment

Terminal
Network Policy Console
root@k8s-secure:~#
Network Policy Manager Namespace: payments
Allow Ingress Rule
Policies
Default DenyNo
Allow Rules0
AppliedNo
Traffic Tests
Allowed (api-gw)--
Denied (default)--
IsolationNot verified
Activity Log
[system]Network policy manager ready. No policies configured.
Progress: 0/6 tasks completed
Score: 0/100
After Completing All Steps:

1. Click "Validate Configuration" for a network isolation checklist.
2. Click "View Architecture" to see the traffic flow diagram.
3. Reset the lab to re-practice network policy patterns.
0%

Lab Completed!

Network policies configured with microsegmentation.

Lab 21: Image Scanning & Supply Chain Security
Kubernetes / GUI + Terminal
Scenario: Container Image Vulnerability Scanning
Before deploying to production, all container images must pass vulnerability scanning. Scan the webapp:latest image using Trivy, identify critical/high CVEs, rebuild with a secure base image (alpine), configure an ImagePolicyWebhook to block unscanned images, and verify the pipeline rejects vulnerable deployments.
CKS Lab

Learning Objectives:

  • Image scanning: use Trivy to find CVEs in container images
  • Base image hardening: switch to minimal/distroless base images
  • Admission webhooks: block unscanned or vulnerable images
  • Supply chain: verify image signatures and provenance

Step-by-Step Instructions

  1. Step 1: Scan vulnerable image
    In the Terminal tab, scan the original image:
    trivy image webapp:latest
    Tip: Look for CRITICAL and HIGH severity vulnerabilities in the scan results.
  2. Step 2: Select secure base image
    In the Image Console tab, configure:
    Base Image = alpine:3.19 Scan Policy = block-critical
    Then click Rebuild Image.
  3. Step 3: Scan rebuilt image
    In the Terminal, scan the secure image:
    trivy image webapp:secure
  4. Step 4: Configure ImagePolicyWebhook
    Click Enable Webhook to configure the admission webhook that blocks unscanned images.
  5. Step 5: Test blocked deployment
    In the Terminal, try deploying the vulnerable image:
    kubectl run vuln-app --image=webapp:latest -n production
    Expected: Rejected by ImagePolicyWebhook - image has critical vulnerabilities.
  6. Step 6: Deploy secure image
    Deploy the scanned secure image:
    kubectl run secure-app --image=webapp:secure -n production
    Expected: Pod created successfully - image passed vulnerability scan.

CKS Lab Environment

Terminal
Image Console
root@k8s-secure:~#
Image Security Scanner Registry: internal
Image Rebuild
webapp:latest
Critical CVEs--
High CVEs--
Base Imageubuntu:20.04
StatusNot scanned
webapp:secure
Critical CVEs--
High CVEs--
Base Image--
StatusNot built
Activity Log
[system]Image security scanner ready. No images scanned.
Progress: 0/6 tasks completed
Score: 0/100
After Completing All Steps:

1. Validate to see image scanning + webhook checklist.
2. Click "View Architecture" to see the supply chain security pipeline.
3. Use Reset to re-practice image security patterns.
0%

Lab Completed!

Image scanning and supply chain security configured.

Module 1: KCNA Module 2: DCA Module 3: KCSA Module 4: Terraform Module 5: CKAD Module 6: CKA Module 7: CKS Module 8: AWS DevOps Module 9: AZ-400 Module 10: Google DevOps