Kubernetes

Kubernetes Security: Identity, Auth & Access Control

How service accounts, RBAC, TLS, and OIDC integration secure the container orchestration plane — and where things commonly go wrong.

10 min read

The Control Plane Is the Crown Jewel

Kubernetes clusters manage critical infrastructure. If an attacker gains control of the API server, they own everything running in the cluster. Kubernetes security starts with who can talk to the API server and what they can do.

Authentication in Kubernetes

Every API request goes through authentication first. Kubernetes supports multiple strategies (K8s auth docs):

Client Certificate Auth (X.509)

The most common bootstrap method. The cluster CA signs certificates for users and components (PKI blog):

  • kubectl uses a certificate + key in ~/.kube/config
  • kubelet uses its own certificate to talk to the API server
  • Certificate revocation is manual — one reason this scales poorly (K8s PKI docs)

Bearer Tokens

  • Static tokens — Simple, but rotate them like passwords
  • ServiceAccount tokens — Auto-generated via TokenRequest API, mounted into pods, tied to RBAC, time-bound (default 1 hour)
  • Bootstrap tokens — Used by kubeadm for initial cluster setup

OIDC Integration

The production-grade approach: delegate authentication to an external identity provider (K8s OIDC docs, hardening guide):

sequenceDiagram
    participant User
    participant Kubectl
    participant KAS as API Server
    participant IdP as OIDC Provider<br/>(Azure AD / Okta / Keycloak)
    participant etcd
    participant Kubelet

    User->>Kubectl: kubectl get pods
    Kubectl->>IdP: GET /authorize (OIDC token)
    IdP->>User: Login prompt
    User->>IdP: Authenticate
    IdP->>Kubectl: id_token (signed JWT)
    Kubectl->>KAS: API request + Bearer id_token
    KAS->>IdP: Verify token signature (JWKS)
    IdP->>KAS: Signature valid
    KAS->>KAS: Extract user/groups from claims
    KAS->>KAS: Evaluate RBAC bindings
    KAS->>etcd: Read/Watch resources
    etcd->>KAS: Pod data
    KAS->>Kubectl: Pod list response
    Kubectl->>User: Display pods

With OIDC, users authenticate using their corporate identity (Azure AD, Okta, Keycloak). The API server trusts the provider’s signatures. This means offboarding is handled externally — disable the user in the IdP, and they lose access immediately. Token lifetimes are short (typically 1 hour), enforced by the TokenRequest API.

Authorization: RBAC

Kubernetes uses Role-Based Access Control (RBAC) to determine what authenticated users can do (RBAC docs):

graph LR
    classDef user fill:#e8f0fe,stroke:#0071e3,stroke-width:1px,color:#1d1d1f
    classDef binding fill:#f0edff,stroke:#5856d6,stroke-width:1px,color:#1d1d1f
    classDef role fill:#f5f5f7,stroke:#d2d2d7,stroke-width:1px,color:#1d1d1f
    classDef svc fill:#fef2f2,stroke:#ef4444,stroke-width:1px,color:#1d1d1f

    User --> RB["RoleBinding<br/>production: pods/*"]
    SA["ServiceAccount<br/>(my-app-sa)"] --> RB
    RB --> Role["Role<br/>get, list, watch pods"]
    Role --> Resources["pods<br/>(namespace: production)"]

    CRB["ClusterRoleBinding"] --> ClusterRole["ClusterRole<br/>get, list nodes"]
    ClusterRole --> NodeResources["nodes<br/>(cluster-wide)"]

    class User,SA user
    class RB,CRB binding
    class Role,ClusterRole role
    class SA svc

Roles are namespaced; ClusterRole applies cluster-wide. Bind them to users, groups, or service accounts with RoleBinding / ClusterRoleBinding.

Common Pitfalls

  1. Overly permissive service accounts — Many pods run as default with no explicit RBAC. Attackers who compromise a pod can enumerate the cluster. Follow least-privilege: create dedicated service accounts for each workload.
  2. No network policies — By default, all pods can reach all pods (K8s network policies). An attacker who breaches one service has lateral movement. Use Calico, Cilium, or OVN to enforce micro-segmentation.
  3. Secrets in environment variables — Prefer volume mounts or a vault sidecar. For cloud clusters, use external secrets operator.
  4. Running as root — Use securityContext.runAsNonRoot: true (pod security standards).
  5. No audit logging — The API server can log every request (audit logging); this is invaluable for incident response.

The KMS Connection

Kubernetes supports encryption at rest for etcd via a KMS provider plugin. Secrets are encrypted before being written to etcd, and the encryption keys are managed externally (AWS KMS, Azure Key Vault, GCP Cloud KMS, HashiCorp Vault). This means even if someone dumps etcd, they can’t read your secrets.

Kubernetes security is a layered discipline. Strong authentication (OIDC + client certs), fine-grained RBAC, network policies, and KMS-backed encryption form the baseline for any production cluster.

References