Module 10 Exercises: Hardening the Cluster

In Module 10, we learned that security is not a single product, but a series of layers. You learned about RBAC, ServiceAccounts, Pod Security Standards, and Encryption. These exercises will help you build those layers one by one.

---

Exercise 1: The "Junior Developer" Role

1. Task: Create a Role named junior-dev-role in the ai-lab namespace.
   • Permissions: Allow only get, list, and watch for Pods.
   • Forbidden: They should NOT be able to see Secrets or ConfigMaps.
2. Binding: Bind this role to a user named junior@example.com.
3. Verification: Use kubectl auth can-i to verify:
   • Can junior list pods? (Should be yes)
   • Can junior delete pods? (Should be no)
   • Can junior list secrets? (Should be no)

---

Exercise 2: Identity Theft Prevention

1. Creation: Create a ServiceAccount named silent-agent.
2. Task: Deploy a pod that uses this ServiceAccount but has Automounting disabled.
3. Verification: kubectl exec into the pod and try to find the directory /var/run/secrets/kubernetes.io/serviceaccount/.
4. Analysis: If a hacker gets into this pod, what credentials do they find? How does this protect your API Server?

---

Exercise 3: Triggering a Security Rejection

1. Preparation: Label a namespace secure-zone with pod-security.kubernetes.io/enforce: restricted.
2. The Attack: Create a Pod YAML that tries to run as the root user (UID 0) or uses hostPath storage.
3. Action: Apply the YAML to the secure-zone namespace.
4. Observation: Copy the exact error message returned by the API Server. How does it explain why the pod was blocked?

---

Exercise 4: Building a Hardened SecurityContext

1. Goal: Write a securityContext section for a container that passes the Restricted standard.
2. Requirements:
   • The application must run as a non-root user (UID 1001).
   • The root filesystem must be Read-Only.
   • All Linux capabilities must be dropped.
3. Thinking Task: If the root filesystem is read-only, how can the application write temporary log files or cache data? (Hint: See Module 6.1 and emptyDir).

---

Solutions (Self-Check)

Exercise 1 Answer:

• kubectl auth can-i list pods --as junior@example.com -n ai-lab (yes)
• kubectl auth can-i delete pods --as junior@example.com -n ai-lab (no)
• kubectl auth can-i list secrets --as junior@example.com -n ai-lab (no)

Exercise 2 Solution:

The directory will not exist! The hacker finds zero Kubernetes credentials, making it impossible for them to move laterally through your cluster via the API.

Exercise 3 Hint:

The error will explicitly mention the "Restricted" policy violation. This proves that your Admission Controller is doing its job as a "Bouncer."

Exercise 4 Logic:

To handle temporary writes in a read-only environment:

1. Mount an emptyDir volume at /tmp.
2. Tell your application to write logs/cache to /tmp instead of /var/log.
3. Result: You have a hardened container that can still function!

---

Summary of Module 10

Congratulations! You are now a Kubernetes Security Specialist.

• You can design precise RBAC policies.
• You can secure pod identities with ServiceAccounts.
• You can enforce cluster-wide hardening with Pod Security Standards.
• You understand the "Supply Chain" risks of container images.
• You know why Encryption at Rest is mandatory for compliance.

In Module 11: CI/CD with Kubernetes, we will move from defense to offense: learning how to automate the delivery of these secure applications at scale.