Kubernetes Access Control

Kubernetes processes an API request through authentication, authorization, and admission control. Authentication establishes an identity; authorization determines whether that identity may perform an action; admission can validate or mutate the accepted object. These are separate controls and should be configured and audited separately.

Authenticate with OIDC #

OpenID Connect (OIDC) lets the API server validate bearer tokens issued by an external identity provider. The API server is configured with the issuer URL, client ID, and optional username and group claim mappings. The issuer must be reachable by the API server and its TLS certificate must validate.

The identity provider owns user lifecycle and multi-factor authentication; Kubernetes receives a username and groups from a valid token. Do not use a shared static token for people. In kubectl, use an approved OIDC login plugin or an exec credential provider so short-lived tokens are refreshed without storing long-lived credentials in kubeconfig files.

Authorize with RBAC #

RBAC grants verbs on resource types through Role and ClusterRole objects, then attaches those permissions through bindings. A Role is namespace-scoped; a ClusterRole can grant cluster-scoped access or be bound within a namespace.

apiVersion: rbac.authorization.k8s.io/v1
kind: Role
metadata:
  name: deployment-reader
  namespace: payments
rules:
  - apiGroups: ["apps"]
    resources: ["deployments"]
    verbs: ["get", "list", "watch"]
---
apiVersion: rbac.authorization.k8s.io/v1
kind: RoleBinding
metadata:
  name: developers-can-read-deployments
  namespace: payments
subjects:
  - kind: Group
    name: payments-developers
    apiGroup: rbac.authorization.k8s.io
roleRef:
  kind: Role
  name: deployment-reader
  apiGroup: rbac.authorization.k8s.io

Grant the narrowest verbs, resources, namespaces, and non-resource URLs needed. Avoid cluster-admin, wildcard verbs, and wildcard resources except for tightly controlled platform administration. Check a proposed grant with kubectl auth can-i.

Control Resources and Service Accounts #

ResourceQuota limits aggregate namespace consumption; LimitRange supplies or constrains per-container requests and limits. A quota alone does not guarantee fair scheduling: workloads should specify CPU and memory requests, and namespaces need operational monitoring.

Service accounts are workload identities. Disable automatic token mounting where it is not needed, use projected short-lived tokens, and bind each workload service account to a minimal role. Never give an application the default service account’s broad permissions. Admission policies, Pod Security Standards, network policies, and image controls complement RBAC; none replaces it.