Module 2: Kubernetes Foundations for Security Slides

Slide Outline

1. Kubernetes Foundations for Security - Understanding Kubernetes architecture, RBAC, and the API attack surface from a security perspective
2. Learning Objectives - 4 outcomes for this module
3. Why This Module Matters - Kubernetes RBAC misconfigurations are consistently in the top 3 causes of Kubernetes security incidents. Understanding t
4. Kubernetes Architecture Through a Security Lens - Lesson section from the full module
5. RBAC Deep Dive - Lesson section from the full module
6. Kubernetes Admission Flow - Lesson section from the full module
7. The Kubernetes Attack Surface - Lesson section from the full module
8. Real-World Use Cases - Hardening RBAC for SOC 2 compliance, Detecting privilege escalation via overpermissioned service accounts
9. Common Mistakes to Avoid - 5 mistakes covered
10. Production Notes - 3 practical notes
11. Security Risks to Watch - 4 risks covered
12. Hands-On Labs - 3 hands-on labs
13. Key Takeaways - 5 points to remember

Learning Objectives

• Understand Kubernetes architecture through a security lens
• Master RBAC design and common misconfigurations
• Map the Kubernetes API attack surface
• Debug authentication and authorization failures

Why This Module Matters

Kubernetes RBAC misconfigurations are consistently in the top 3 causes of Kubernetes security incidents. Understanding the API request flow and designing least-privilege RBAC is not optional — it is the foundation of every secure Kubernetes deployment.

Production Notes

• Always disable auto-mounting of service account tokens: automountServiceAccountToken: false. Only mount when the pod actually needs API access.
• Audit RBAC regularly with tools like kubectl-who-can or rbac-police. Permissions accumulate over time.
• Enable audit logging on the API server to track who accessed what and when.

Common Mistakes

• Granting cluster-admin to the default service account
• Not disabling auto-mounting of service account tokens
• Leaving the kubelet read-only port (10255) exposed
• Not encrypting etcd at rest
• Using wildcards (*) in RBAC rules for convenience

Key Takeaways

• Every K8s request flows through: AuthN -> AuthZ (RBAC) -> Admission -> etcd
• RBAC should follow least privilege — never use cluster-admin for workloads
• Default service accounts with auto-mounted tokens are a common attack vector
• Admission controllers are where policy enforcement happens
• etcd must be encrypted at rest — it stores all cluster secrets

Hands-On Labs

1. Explore Kubernetes Security Components

   Map the Kubernetes control plane from a security perspective.

   25 min - Beginner

   • Deploy a Kind cluster
   • Inspect API server flags and security settings
   • List all ClusterRoleBindings and identify overly broad permissions
   • Check if etcd encryption is enabled

   View lab files on GitHub

2. Create Least-Privilege RBAC Policies

   Design and deploy RBAC roles following least-privilege principles.

   30 min - Beginner

   • Create a namespace-scoped Role for a monitoring agent
   • Bind it to a specific ServiceAccount
   • Test that the SA can only read pods (not create/delete)
   • Attempt to escalate privileges and observe the denial

   View lab files on GitHub

3. Exploit Insecure RBAC Configuration

   Demonstrate how misconfigured RBAC leads to privilege escalation.

   35 min - Intermediate

   • Deploy a pod with an overly permissive service account
   • Use kubectl from inside the pod to list secrets
   • Escalate to cluster-admin by creating a new ClusterRoleBinding
   • Document the attack chain and fix the RBAC configuration

   View lab files on GitHub