Skip to main content

Module 2: Kubernetes Foundations for Security

Understanding Kubernetes architecture, RBAC, and the API attack surface from a security perspective

3.5 hours. 3 hands-on labs. Free course module.

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 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.

KUBERNETES API REQUEST FLOW (SECURITY VIEW)kubectl / PodAPI ServerAuthenticationAuthorization (RBAC)AdmissionMutating + ValidatingetcdTLSRBAC OKAdmittedCommon Attack SurfacesMisconfigured RBACcluster-admin to default SAExposed API ServerAnonymous auth enabledetcd Without EncryptionSecrets stored in plaintextPrivilege EscalationPod with hostPID/hostNetworkNo Admission ControlNo policy enforcementDefault Service AccountsAuto-mounted tokens everywhere
Architecture diagram for Module 2: Kubernetes Foundations for Security.

Lesson Content

Before you can secure Kubernetes, you must understand how it works — specifically, how requests flow through the API server, how authentication and authorization decisions are made, and where the attack surface lies.

Kubernetes Architecture Through a Security Lens

Every Kubernetes interaction goes through the API Server. The API Server authenticates the request (who are you?), authorizes it via RBAC (are you allowed?), runs admission controllers (should this be modified or rejected?), and then writes to etcd (the cluster state store). Each step is a security boundary. Each step can be misconfigured.

RBAC Deep Dive

Role-Based Access Control is Kubernetes' primary authorization mechanism. It consists of Roles (what permissions exist), RoleBindings (who gets those permissions), ClusterRoles (cluster-wide permissions), and ClusterRoleBindings (cluster-wide assignments).

# Least-privilege Role: read pods in one namespace only
apiVersion: rbac.authorization.k8s.io/v1
kind: Role
metadata:
  namespace: production
  name: pod-reader
rules:
  - apiGroups: [""]
    resources: ["pods"]
    verbs: ["get", "list", "watch"]
---
# Bind to a specific service account
apiVersion: rbac.authorization.k8s.io/v1
kind: RoleBinding
metadata:
  namespace: production
  name: read-pods
subjects:
  - kind: ServiceAccount
    name: monitoring-agent
    namespace: production
roleRef:
  kind: Role
  name: pod-reader
  apiGroup: rbac.authorization.k8s.io

Kubernetes Admission Flow

Admission controllers run AFTER authentication and authorization but BEFORE the object is persisted. They can mutate requests (MutatingAdmissionWebhook) or reject them (ValidatingAdmissionWebhook). This is where policy engines like OPA Gatekeeper and Kyverno plug in.

The Kubernetes Attack Surface

  • API Server: Exposed without auth? Anonymous access enabled? Insecure port open?
  • etcd: Unencrypted? Accessible without mTLS? Secrets stored in plaintext?
  • Kubelet: Anonymous auth enabled? Read-only port exposed?
  • Service Accounts: Default SA with auto-mounted tokens? Overly broad ClusterRoleBindings?
  • Pods: Running as root? hostPID? hostNetwork? Privileged containers?

Real-World Use Cases

  • Hardening RBAC for SOC 2 compliance
  • Detecting privilege escalation via overpermissioned service accounts
  • Configuring admission control for multi-tenant clusters
  • Auditing API server access for security investigations

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

Security Risks to Watch

  • cluster-admin bound to default service account
  • etcd accessible without mTLS
  • Kubelet read-only port (10255) exposed
  • Anonymous API authentication enabled

Think Like an Engineer

  • How would you audit RBAC across 50 namespaces with 200 service accounts?
  • What is the minimum RBAC needed for a CI/CD pipeline to deploy safely?

Production Story

A platform team discovered that 12 of their 30 namespaces had service accounts with cluster-admin — all created during initial setup and never scoped down. A single compromised pod in any of those namespaces could read every secret in the cluster. One RBAC audit and cleanup fixed it, but the vulnerability had been open for 18 months.

Career Relevance

RBAC design is the #1 Kubernetes security skill. Every production cluster audit starts with RBAC review. Engineers who can design least-privilege RBAC are essential for any organization running Kubernetes at scale.

Key Terms

RBAC
Role-Based Access Control — Kubernetes authorization mechanism
ClusterRole
Cluster-wide set of permissions (dangerous if bound broadly)
Admission Controller
Plugin that intercepts API requests after auth but before persistence
etcd
Key-value store holding all Kubernetes cluster state including secrets
Service Account
Identity assigned to pods for API server authentication

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

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