DevOps & Kubernetes Security Labs - KCSA

Practice Kubernetes security controls with hands-on, PBQ-style labs: RBAC policy design, NetworkPolicy micro-segmentation, Pod Security Standards, and supply-chain scanning - aligned to the Kubernetes & Cloud Security Associate (KCSA) 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

KCSA Security Labs - Module 3

GUI-first labs (policy builders, consoles, dashboards) plus strict terminal validation - build real-world Kubernetes security intuition: least privilege, segmentation, and workload hardening.

Lab 7: Kubernetes RBAC Policy Manager
Kubernetes Security / GUI
Scenario: Least Privilege for CI
FinBank is onboarding a CI service account that deploys apps to the payments namespace. Your task is to design an RBAC policy that allows read-only visibility into workloads (pods and deployments) while preventing access to sensitive resources like secrets.
KCSA Lab

Learning Objectives:

  • RBAC: Role vs ClusterRole, RoleBinding, subjects
  • Least privilege: verbs + resources aligned to job function
  • Verification: use kubectl auth can-i to test access
  • Audit mindset: make permissions explicit and reviewable

📋 Step-by-Step Instructions

  1. Step 1: Set target (namespace + service account)
    Goal: Configure the RBAC policy target.

    In the RBAC Policy Manager tab, set:
    Scope = Role Namespace = payments ServiceAccount = ci-bot
    Then click Set Target.
    Tip: Prefer Role (namespaced) unless you truly need cluster-wide permissions.
  2. Step 2: Choose resources
    Goal: Select only the required API resources.

    Select pods and deployments. Then click Save Resources.
    Security note: Do not grant secrets access for a read-only CI identity.
  3. Step 3: Choose verbs (read-only)
    Goal: Select minimal verbs for visibility.

    Select get, list, watch. Then click Save Verbs.
    Tip: watch is common for controllers/dashboards; omit it if not needed.
  4. Step 4: Generate RBAC YAML
    Click Generate YAML to render a reviewable policy.
  5. Step 5: Apply RBAC (role + binding)
    Click Apply RBAC. This simulates creating the Role and RoleBinding.
    Tip: In production, store RBAC YAML in Git and review changes via PR.
  6. Step 6: Verify access via terminal
    In the Terminal tab, run:
    kubectl auth can-i list pods -n payments --as system:serviceaccount:payments:ci-bot
    Expected: yes. Secrets should remain denied (shown in the RBAC console).

KCSA Lab Environment

RBAC Policy Manager
Terminal
🔒 RBAC Policy Manager Cluster: kcsa-lab
Policy Scope
Scope—
Namespace—
ServiceAccount—
Access Snapshot
Allowed Rules0
Denied: secretsYes
AppliedNo
RBAC Builder (GUI)
Resources
Verbs
📜 Recent Activity
[system]RBAC console ready. No policy applied.
root@k8s-admin:~#
Progress: 0/6 tasks completed
Score: 0/100
🎉 After Completing All Steps:

1. Click "Validate Configuration" for a detailed RBAC checklist.
2. Click "View Architecture" to see the RBAC decision flow (AuthN -> AuthZ -> Admission).
3. Reset the lab if you want to re-practice least privilege design.
0%

Lab Completed!

Least privilege achieved - RBAC validated.

Lab 8: Kubernetes NetworkPolicy Builder
Kubernetes Security / GUI
Scenario: Micro-Segmentation
ShopNow runs a three-tier app in the store namespace: frontend -> api -> db. Your goal is to enforce segmentation so only the approved paths work:

frontend -> api : 8080 api -> db : 5432
KCSA Lab

Learning Objectives:

  • Default deny: understand baseline isolation with NetworkPolicy
  • Selectors: podSelector + namespaceSelector patterns
  • Ports: restrict traffic to explicit ports
  • Validation: simulate flows and verify expected allow/deny

📋 Step-by-Step Instructions

  1. Step 1: Set the policy target
    In NetworkPolicy Builder, set:
    Namespace = store Target Pods = app=api
    Then click Set Target.
  2. Step 2: Add default deny ingress
    Enable Default Deny Ingress and click Add Baseline Policy.
    Tip: NetworkPolicy is allow-list based. Without policies, everything is allowed (CNI-dependent).
  3. Step 3: Allow frontend -> api on 8080
    Configure an ingress rule:
    from: app=frontend port: 8080/TCP
    Then click Add Ingress Rule.
  4. Step 4: Allow api -> db on 5432
    Configure an egress rule:
    to: app=db port: 5432/TCP
    Then click Add Egress Rule.
  5. Step 5: Generate YAML and apply
    Click Generate YAML, then Apply Policy.
  6. Step 6: Verify via terminal
    In the Terminal tab, run:
    kubectl get networkpolicy -n store
    Expected: policies exist and segmentation is enforced (see simulator).

KCSA Network Policy Lab

NetworkPolicy Builder
Terminal
🧱 NetworkPolicy Builder CNI: calico-sim
Policies
Namespace—
Target—
AppliedNo
Rules
Default DenyNo
Ingress Rules0
Egress Rules0
Policy Builder (GUI)
Traffic Simulator (expected flows)
frontend -> api :8080
Not simulated
api -> db :5432
Not simulated
frontend -> db
Not simulated
api -> internet
Not simulated
📜 Recent Activity
[system]NetworkPolicy console ready. No segmentation applied.
root@k8s-admin:~#
Progress: 0/6 tasks completed
Score: 0/100
🎉 After Completing All Steps:

1. Validate to see baseline + rule checklist.
2. Click "View Architecture" to see allowed and blocked paths.
3. Use Reset to re-practice segmentation quickly.
0%

Lab Completed!

Segmentation enforced - flows validated.

Lab 9: Pod Security & Image Scanning
Kubernetes Security / Mixed
Scenario: Harden the prod namespace
SecureSoft must harden workloads in the prod namespace. You will enforce Pod Security Standards (restricted), attempt to deploy a non-compliant pod (expect denial), deploy a compliant pod, and run an image vulnerability scan.
KCSA Lab

Learning Objectives:

  • Pod Security: enforce baseline / restricted behavior by namespace labels
  • Admission thinking: understand deny reasons and remediation
  • Supply chain: scan images and interpret severity
  • Dashboards: read security signals quickly

📋 Step-by-Step Instructions

  1. Step 1: Create the namespace
    kubectl create namespace prod
  2. Step 2: Enforce restricted Pod Security
    kubectl label ns prod pod-security.kubernetes.io/enforce=restricted --overwrite
    Tip: Use namespace labels to enforce consistent guardrails for workloads.
  3. Step 3: Attempt to apply a non-compliant pod (expect deny)
    kubectl apply -n prod -f bad-pod.yaml
    Expected: denied due to privileged settings (shown in terminal output).
  4. Step 4: Apply a compliant pod
    kubectl apply -n prod -f good-pod.yaml
  5. Step 5: Scan an image for vulnerabilities
    trivy image nginx:alpine
    Tip: Treat HIGH/CRITICAL as release blockers until triaged.
  6. Step 6: Review security center signals
    Switch to the Security Center tab and confirm the dashboard shows restricted enforcement, denied attempts, and scan results.

KCSA Security Center

Terminal
Security Center
root@k8s-admin:~#
🛡️ Security Center Namespace: prod
Pod Security Standards
Enforce—
Denied Attempts0
Compliant Pods0
Supply Chain Scan
Image—
HIGH0
CRITICAL0
Vulnerability Summary
Latest scan findings
No scan results yet.
📜 Recent Activity
[system]Security Center ready. Enforce labels not set.
Progress: 0/6 tasks completed
Score: 0/100
🎉 After Completing All Steps:

1. Validate to see admission + scan checklist.
2. View Architecture to review the security pipeline from admission to runtime.
0%

Lab Completed!

Workloads hardened - scan complete.

⚠️ Reset Lab?

This will clear all your progress for this lab including terminal history, completed tasks, and dashboard data. This action cannot be undone.