CodersSecret

Module 2 of 16

Kubernetes Foundations for Security

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

3.5 hours3 labsFree
Watch as Slides Course overview Lab code

Start here

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

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

Where this shows up

  • 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

Keep these close

  • 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

What usually breaks

  • 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

Threats 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

Questions to answer before shipping

  • 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?

Key terms

Vocabulary used in this module

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

Labs

Hands-on labs

25 minBeginner

Explore Kubernetes Security Components

Map the Kubernetes control plane from a security perspective.

  1. Deploy a Kind cluster
  2. Inspect API server flags and security settings
  3. List all ClusterRoleBindings and identify overly broad permissions
  4. Check if etcd encryption is enabled
View lab on GitHub
30 minBeginner

Create Least-Privilege RBAC Policies

Design and deploy RBAC roles following least-privilege principles.

  1. Create a namespace-scoped Role for a monitoring agent
  2. Bind it to a specific ServiceAccount
  3. Test that the SA can only read pods (not create/delete)
  4. Attempt to escalate privileges and observe the denial
View lab on GitHub
35 minIntermediate

Exploit Insecure RBAC Configuration

Demonstrate how misconfigured RBAC leads to privilege escalation.

  1. Deploy a pod with an overly permissive service account
  2. Use kubectl from inside the pod to list secrets
  3. Escalate to cluster-admin by creating a new ClusterRoleBinding
  4. Document the attack chain and fix the RBAC configuration
View lab on GitHub

Recap

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

Related resources

Keep learning across CodersSecret

Related guides

Read practical engineering walkthroughs that connect this lesson to real systems.

Cheatsheets

Keep command references and production checklists close while you practice.

Interactive labs

Practice infrastructure decisions through short, scenario-driven exercises.

Glossary terms

Build the vocabulary needed to explain architecture clearly in reviews.