Kubernetes Identity and Access Guidelines

Kubernetes Identity and Access Guidelines describe the practices for controlling who and what can act on cluster resources — covering human user authentication, workload identity via ServiceAccount, and the authorization model governed by Role-Based Access Control (RBAC) — so that both people and Pods are granted only the permissions their actual role requires, and every privileged action can be traced back to a specific, accountable identity.

Authentication Fundamentals

Kubernetes Delegates Human Authentication

Kubernetes has no built-in user database for humans; authentication is delegated to an external identity provider (OIDC, a cloud IAM system, client certificates) that the API server is configured to trust. This means identity and access guidelines for human operators are really about how that external identity system is integrated and mapped into Kubernetes' authorization layer, not about Kubernetes managing credentials directly.

ServiceAccounts as Workload Identity

Every Pod runs under a ServiceAccount, which is Kubernetes' native identity for workloads rather than humans. Unless specified, Pods run under a namespace's default ServiceAccount, which should never be granted meaningful permissions — every workload that genuinely needs to talk to the Kubernetes API should be given its own dedicated ServiceAccount scoped to exactly what it needs.

RBAC Design

Least Privilege as the Baseline

Every Role or ClusterRole should grant the minimum set of verbs (get, list, watch, create, update, delete) on the minimum set of resources actually required, rather than broad wildcard grants. A workload that only needs to read ConfigMaps should never be granted create or delete on Secrets simply because it was easier to copy a broader existing role.

Namespaced Roles vs. ClusterRoles

Role and RoleBinding scope permissions to a single namespace; ClusterRole and ClusterRoleBinding scope permissions cluster-wide (or, when bound with a RoleBinding, can grant a ClusterRole's permissions within just one namespace). Cluster-wide bindings should be reserved for genuinely cluster-scoped needs — most workload and team permissions belong at the namespace level, where the blast radius of an overly broad grant is naturally contained.

Avoiding Wildcard Grants

Roles using resources: ["*"] or verbs: ["*"] collapse the entire point of RBAC into a single all-or-nothing grant, and are a common finding in security reviews precisely because they're easy to write and hard to justify against actual need — every wildcard should be treated as a red flag requiring specific justification, not a convenient default.

Aggregated ClusterRoles for Extensibility

aggregationRule allows a ClusterRole to automatically compose permissions from other ClusterRoles matching a label selector, useful for building up broad administrative roles (like the built-in admin, edit, view roles) from smaller, independently maintained pieces without needing to edit a single monolithic role definition every time a new resource type needs to be included.

Service Account Token Management

Bound, Time-Limited Tokens

Modern Kubernetes issues ServiceAccount tokens as bound, time-limited, audience-scoped tokens by default (via the TokenRequest API) rather than the long-lived, unbounded tokens automatically mounted in older versions. Where legacy long-lived token Secrets still exist for a ServiceAccount, they should be identified and migrated away from, since a leaked long-lived token remains valid indefinitely.

Disabling Automatic Token Mounting Where Unneeded

automountServiceAccountToken: false should be set on Pods (or at the ServiceAccount level) that never actually call the Kubernetes API, removing a credential from the Pod's filesystem that would otherwise sit unused as a potential target if the Pod is compromised.

Workload Identity Federation

Avoiding Long-Lived Cloud Credentials in Pods

For workloads that need to call cloud provider APIs, workload identity federation (mapping a Kubernetes ServiceAccount to a cloud IAM identity via OIDC trust) eliminates the need to store long-lived cloud credentials as Kubernetes Secrets entirely — the Pod's ServiceAccount token itself becomes the credential, inheriting the same short-lived, audience-scoped properties, and removing an entire class of credential-leakage risk.

Auditing and Accountability

Audit Logging of API Server Activity

The API server's audit log records who performed which action against which resource, and should be enabled and retained with a policy that captures at minimum all write operations and access to sensitive resources (Secrets, RBAC objects themselves). Without this, a security incident involving unauthorized access has no reliable forensic trail to reconstruct what happened.

Periodic Access Review

RBAC bindings accumulate over time as team membership and workload ownership change; a periodic review process — auditing who holds which ClusterRoleBindings, and whether ServiceAccounts still match an active, still-necessary workload — prevents privilege from silently persisting long after the reason for granting it has expired.

Human Access Patterns

Avoiding Shared or Static Cluster-Admin Credentials

Direct, standing cluster-admin access should be reserved for a small, explicitly justified set of operators, with break-glass procedures for emergency access rather than routine use. Day-to-day operations should go through role-scoped access mapped from the external identity provider's group membership, so that access changes when someone's role changes without requiring manual Kubernetes-side cleanup.

Example Configuration

apiVersion: v1
kind: ServiceAccount
metadata:
  name: codartium-api-sa
  namespace: codartium
automountServiceAccountToken: false
---
apiVersion: rbac.authorization.k8s.io/v1
kind: Role
metadata:
  name: codartium-configmap-reader
  namespace: codartium
rules:
  - apiGroups: [""]
    resources: ["configmaps"]
    verbs: ["get", "list", "watch"]
---
apiVersion: rbac.authorization.k8s.io/v1
kind: RoleBinding
metadata:
  name: codartium-api-configmap-binding
  namespace: codartium
subjects:
  - kind: ServiceAccount
    name: codartium-api-sa
    namespace: codartium
roleRef:
  kind: Role
  name: codartium-configmap-reader
  apiGroup: rbac.authorization.k8s.io

Practical Consequences

Disciplined identity and access management produces a cluster where every action is attributable to a specific, appropriately scoped identity, where a compromised workload's API access is bounded to what it legitimately needed, and where credential leakage carries limited and time-bound consequences. Neglecting these guidelines commonly manifests as workloads running with far broader API access than their function requires, long-lived tokens that remain valid long after they should have been rotated, or a security incident that cannot be reconstructed because no audit trail exists to show what an unauthorized identity actually did once inside the cluster.