Kubernetes Security Identity and Access

Kubernetes Security Identity and Access is the layer of the platform responsible for determining who or what is making a request to the cluster, and what that identity is permitted to do once recognized. Every interaction with a Kubernetes cluster, whether from a human operator, an automated pipeline, or a Pod calling the API on its own behalf, passes through this identity and authorization model before any action is taken, forming the primary security boundary around the cluster's control plane.

Authentication

Establishing Identity

Authentication determines who is making a request. Kubernetes does not manage user accounts directly; instead, it recognizes several categories of authentication mechanisms, all of which ultimately resolve to a username and set of group memberships that the rest of the system reasons about.

Client Certificates

Requests presenting a valid X.509 client certificate, signed by a certificate authority the API server trusts, are authenticated using the certificate's Common Name as the username and its Organization fields as group memberships, a mechanism commonly used for administrative and cluster-component identities.

Bearer Tokens

Static tokens, OpenID Connect (OIDC) tokens issued by an external identity provider, or Service Account tokens can all be presented as bearer tokens in a request's Authorization header, with OIDC integration being the standard mechanism for tying cluster access to an organization's broader identity provider.

Service Accounts

A ServiceAccount provides an identity for processes running inside the cluster, most commonly Pods, allowing them to authenticate to the API server without human credentials. Every namespace has a default ServiceAccount, and Pods are automatically associated with one unless a different ServiceAccount is specified.

apiVersion: v1
kind: ServiceAccount
metadata:
  name: codartium-controller
  namespace: codartium-team

spec:
  serviceAccountName: codartium-controller
  containers:
    - name: controller
      image: codartium/controller:1.0.0

Authorization

RBAC as the Standard Model

Role-Based Access Control (RBAC) is the predominant authorization mode in Kubernetes, granting permissions by binding a set of allowed verbs on a set of resources, a Role or ClusterRole, to a user, group, or ServiceAccount, through a RoleBinding or ClusterRoleBinding.

Roles and ClusterRoles

A Role grants permissions scoped to a single namespace; a ClusterRole grants permissions across the entire cluster or against cluster-scoped resources, and can also be bound within a single namespace via a RoleBinding to reuse a common permission set without duplicating rule definitions.

apiVersion: rbac.authorization.k8s.io/v1
kind: Role
metadata:
  namespace: codartium-team
  name: pod-reader
rules:
  - apiGroups: [""]
    resources: ["pods"]
    verbs: ["get", "list", "watch"]
---
apiVersion: rbac.authorization.k8s.io/v1
kind: RoleBinding
metadata:
  name: read-pods
  namespace: codartium-team
subjects:
  - kind: ServiceAccount
    name: codartium-controller
    namespace: codartium-team
roleRef:
  kind: Role
  name: pod-reader
  apiGroup: rbac.authorization.k8s.io

Principle of Least Privilege

RBAC rules should grant only the specific verbs and resources a given identity genuinely requires, since any granted permission represents a capability that could be misused if that identity's credentials are compromised; broad wildcard rules across all resources and verbs are generally reserved for a small number of cluster administrator identities.

kubectl auth can-i delete pods --as system:serviceaccount:codartium-team:codartium-controller -n codartium-team
kubectl get rolebindings,clusterrolebindings --all-namespaces -o wide

Admission Control

The Final Gate

After authentication and authorization succeed, a request passes through a chain of admission controllers before being persisted, providing a final opportunity to validate or modify the request based on policy that goes beyond simple resource-and-verb permission checks.

Mutating and Validating Webhooks

Beyond built-in admission controllers, clusters can register custom mutating and validating admission webhooks, external services that the API server calls during the admission phase, enabling organization-specific policy enforcement, such as requiring specific labels, rejecting privileged containers, or injecting default configuration, without modifying Kubernetes itself.

apiVersion: admissionregistration.k8s.io/v1
kind: ValidatingWebhookConfiguration
metadata:
  name: codartium-policy-check
webhooks:
  - name: require-resource-limits.codartium.io
    rules:
      - apiGroups: [""]
        apiVersions: ["v1"]
        operations: ["CREATE"]
        resources: ["pods"]
    clientConfig:
      service:
        name: policy-webhook
        namespace: codartium-security
        path: /validate
    admissionReviewVersions: ["v1"]
    sideEffects: None

Pod-Level Security

Security Context

A Pod or container's securityContext controls runtime security-relevant behavior, such as the user ID a process runs as, whether privilege escalation is permitted, and whether the root filesystem is mounted read-only, directly constraining what a compromised container process could do even after gaining code execution.

securityContext:
  runAsNonRoot: true
  runAsUser: 10001
  readOnlyRootFilesystem: true
  allowPrivilegeEscalation: false
  capabilities:
    drop: ["ALL"]

Pod Security Admission

Pod Security Admission enforces one of three predefined security profiles, privileged, baseline, or restricted, at the namespace level, rejecting or warning on Pods that violate the configured profile, providing a standardized alternative to writing bespoke admission policy for common Pod hardening requirements.

apiVersion: v1
kind: Namespace
metadata:
  name: codartium-team
  labels:
    pod-security.kubernetes.io/enforce: restricted

Auditing

The API server can be configured to record an audit log of every request it processes, including the requesting identity, the action taken, and the outcome, providing the forensic record necessary to investigate suspicious activity or verify that access controls are functioning as intended across the cluster's lifetime.