Kubernetes Pod Runtime Identity

Kubernetes Pod Runtime Identity refers to the set of attributes that establish who or what a Pod is, and what it is permitted to do, at the moment its containers execute on a node. This identity spans the security context applied to the Pod and its containers, the service account credentials mounted into the Pod, the Linux user and group under which processes run, and the kernel-level capabilities and namespaces that isolate the Pod from the host and from other workloads. Runtime identity is distinct from scheduling metadata: it governs behavior after placement rather than where placement occurs.

Service Account Identity

Default and Custom Service Accounts

Every Pod is associated with a ServiceAccount, either the default account in its namespace or one explicitly referenced via serviceAccountName. This account determines the Pod's identity when it communicates with the Kubernetes API server.

apiVersion: v1
kind: Pod
metadata:
  name: runtime-identity-example
spec:
  serviceAccountName: content-processor
  containers:
    - name: app
      image: registry.example.com/app:2.1.0

Token Projection

Kubernetes mounts a time-bound, audience-scoped service account token into the Pod's filesystem using a projected volume. This token is what workloads present to the API server or to external identity-aware systems to prove their identity.

spec:
  containers:
    - name: app
      image: registry.example.com/app:2.1.0
      volumeMounts:
        - name: kube-api-access
          mountPath: /var/run/secrets/tokens
  volumes:
    - name: kube-api-access
      projected:
        sources:
          - serviceAccountToken:
              path: token
              expirationSeconds: 3600
              audience: api

Security Context

Pod-Level Security Context

The Pod-level securityContext sets defaults inherited by every container, including the numeric user ID (runAsUser), group ID (runAsGroup), and supplemental group memberships (fsGroup) applied to mounted volumes.

spec:
  securityContext:
    runAsUser: 10001
    runAsGroup: 10001
    fsGroup: 10001
    runAsNonRoot: true

Container-Level Overrides

Individual containers may override the Pod-level defaults and add finer controls such as readOnlyRootFilesystem, allowPrivilegeEscalation, and Linux capability adjustments.

containers:
  - name: app
    securityContext:
      readOnlyRootFilesystem: true
      allowPrivilegeEscalation: false
      capabilities:
        drop:
          - ALL
        add:
          - NET_BIND_SERVICE

Kernel and Namespace Isolation

Linux Namespaces

By default, each Pod's containers share a network namespace, an IPC namespace, and a UTS namespace, giving them a common localhost addressing space and hostname, while the PID namespace is typically per-container unless shareProcessNamespace is enabled.

Seccomp and AppArmor Profiles

Runtime identity also includes the syscall filtering profile applied to the Pod. A seccomp profile restricts which system calls a container's processes may invoke, reducing the kernel attack surface exposed to a compromised process.

spec:
  securityContext:
    seccompProfile:
      type: RuntimeDefault

Identity Propagation to Cloud Providers

Workload Identity Federation

On managed clusters, a Pod's Kubernetes service account token can be exchanged for cloud-provider credentials through workload identity federation, allowing the Pod to authenticate to external APIs (object storage, managed databases, secret managers) without embedding long-lived static keys.

Annotation-Based Binding

apiVersion: v1
kind: ServiceAccount
metadata:
  name: content-processor
  annotations:
    cloud.provider.com/identity-binding: "projects/example/serviceAccounts/content-processor@example.iam"

Runtime Identity Diagram

The runtime identity established at container start determines both what a Pod's processes can do on their host node and what actions the Pod is authorized to perform against the cluster API and any federated external identity systems.