RBAC, Security & Identity

No built-in users

User objects do not exist in the Kubernetes API. Human identities are strings (e.g. jane@corp.com) produced by an authenticator and referenced in RBAC bindings. Group is likewise a string list—system:authenticated, system:masters, or LDAP/OIDC-mapped groups.

ServiceAccount token auto-mount

By default, every pod gets a projected or legacy Secret volume mounting the pod's ServiceAccount token at /var/run/secrets/kubernetes.io/serviceaccount/token. The token authenticates as that ServiceAccount when calling the API—powerful if the SA has broad RBAC.

TokenRequest API

Prefer bound tokens via TokenRequest (subresource of ServiceAccount): audience-scoped, time-limited, and revocable when the pod is deleted. Projected volumes with expirationSeconds rotate automatically—no long-lived Secret objects.

Disable automount

For workloads that never call the API, disable token injection at two levels:

• automountServiceAccountToken: false on the ServiceAccount
• automountServiceAccountToken: false on the Pod spec (overrides SA default)

apiVersion: v1
kind: ServiceAccount
metadata:
  name: batch-worker
  namespace: etl
automountServiceAccountToken: false
---
apiVersion: v1
kind: Pod
metadata:
  name: worker
  namespace: etl
spec:
  serviceAccountName: batch-worker
  automountServiceAccountToken: false
  containers:
    - name: worker
      image: my-registry/etl:2.1

$ kubectl auth whoami
$ kubectl get serviceaccount default -o yaml
$ kubectl create token default -n app --duration=1h --audience=api
$ kubectl get --raw /apis/authentication.k8s.io/v1/tokenreviews \
  -d '{"apiVersion":"authentication.k8s.io/v1","kind":"TokenReview","spec":{"token":"TOKEN"}}'$ oc whoami
$ oc whoami --show-token=false
$ oc create token default -n app --duration=1h
$ oc get oauth cluster -o yaml

Core objects

Subjects, verbs, resources, names

• Subjects: User, Group, ServiceAccount (kind + name + namespace for SA)
• Verbs: get, list, watch, create, update, patch, delete, deletecollection, plus subresource verbs like escalate, bind
• Resources: plural API resource names (pods, deployments); use pods/log for subresources
• resourceNames: restrict rule to specific object names—cannot combine with list/watch on collections

Aggregated ClusterRoles

aggregationRule on a ClusterRole merges rules from other ClusterRoles matching label selectors. Built-in roles like admin, edit, view aggregate CRDs and controller-specific permissions as operators install.

Least privilege

Start from view or a custom read-only Role; add verbs incrementally. Namespace-scoped Roles beat ClusterRoleBindings for app teams. Avoid wildcard rules (resources: ["*"], verbs: ["*"]) except in tightly controlled automation SAs.

flowchart TD
  REQ["API request\n(verb + resource + namespace)"] --> AUTH{"Authenticated?"}
  AUTH -->|No| E401["401 Unauthorized"]
  AUTH -->|Yes| SUB["Resolve user, groups, SA"]
  SUB --> BIND["Collect RoleBindings +\nClusterRoleBindings for subject"]
  BIND --> RULES["Union rules from bound Roles"]
  RULES --> MATCH{"Any rule matches?\napiGroup + resource + verb\n+ namespace scope"}
  MATCH -->|Yes| ALLOW["RBAC: allow → admission chain"]
  MATCH -->|No| E403["403 Forbidden"]
  ALLOW --> ADM["Mutating / Validating admission"]

apiVersion: rbac.authorization.k8s.io/v1
kind: Role
metadata:
  name: deploy-reader
  namespace: payments
rules:
  - apiGroups: ["apps"]
    resources: ["deployments"]
    verbs: ["get", "list", "watch"]
  - apiGroups: [""]
    resources: ["pods", "pods/log"]
    verbs: ["get", "list"]
---
apiVersion: rbac.authorization.k8s.io/v1
kind: RoleBinding
metadata:
  name: deploy-reader-binding
  namespace: payments
subjects:
  - kind: ServiceAccount
    name: ci-deploy
    namespace: payments
  - kind: Group
    name: payments-devs
roleRef:
  apiGroup: rbac.authorization.k8s.io
  kind: Role
  name: deploy-reader

$ kubectl auth can-i create deployments -n payments
$ kubectl auth can-i delete pods --as=system:serviceaccount:payments:ci-deploy -n payments
$ kubectl auth can-i --list -n payments
$ kubectl get role,rolebinding,clusterrole,clusterrolebinding -A | grep payments
$ kubectl describe clusterrole edit$ oc auth can-i create deployments -n payments
$ oc auth can-i --list -n payments
$ oc adm policy who-can delete pods -n payments
$ oc describe clusterrole admin

PSP deprecated

PSP was an admission plugin requiring cluster-wide PSP objects and RBAC to use them—operationally brittle. Migrate to PSA labels plus SCC on OpenShift; recreate PSP constraints as Kyverno/Gatekeeper policies if you need exceptions.

PSA profiles

Modes: enforce, audit, warn

• enforce — reject violating pods (hard gate)
• audit — allow but emit audit log event
• warn — allow but return warning to client (kubectl stderr)

Rollout pattern: warn → audit → enforce per namespace tier.

Namespace labels

apiVersion: v1
kind: Namespace
metadata:
  name: payments
  labels:
    pod-security.kubernetes.io/enforce: restricted
    pod-security.kubernetes.io/enforce-version: latest
    pod-security.kubernetes.io/audit: restricted
    pod-security.kubernetes.io/warn: restricted

OPA Gatekeeper & Kyverno

PSA covers pod security standards only. Gatekeeper (OPA) and Kyverno enforce org policy: required labels, banned image registries, ingress TLS, resource limits, label mutating defaults. They run as admission webhooks—synchronous, so keep policies fast and scoped with namespace selectors.

$ kubectl label namespace payments \
  pod-security.kubernetes.io/enforce=restricted \
  pod-security.kubernetes.io/warn=restricted --overwrite
$ kubectl get ns payments --show-labels
$ kubectl auth can-i use podsecuritypolicies -A 2>/dev/null || echo "PSP removed"
$ # Dry-run violating pod
kubectl apply -f bad-pod.yaml --dry-run=server$ oc label namespace payments \
  pod-security.kubernetes.io/enforce=restricted --overwrite
$ oc get ns payments --show-labels
$ oc get constraints 2>/dev/null || oc get validatingwebhookconfigurations | grep -i gatekeeper

Common SCC profiles

Admission

SCC admission runs after authentication/RBAC. The pod's ServiceAccount must be able to use an SCC whose constraints match the pod's securityContext. OpenShift selects the most restrictive applicable SCC that still admits the pod.

Common SCC errors

• unable to validate against any security context constraint — no SCC matches; SA lacks use on a fitting SCC
• runAsUser: Invalid value 0 — pod requests root but only restricted-v2 applies
• host volumes are not allowed — hostPath blocked unless privileged or custom SCC
• capabilities — adding NET_BIND_SERVICE may require nonroot-v2 or custom SCC

Grant SCC to ServiceAccount

$ # SCC is OpenShift-only — no kubectl equivalent
$ kubectl get pods -n legacy -o yaml | grep -A3 securityContext$ oc get scc
$ oc describe scc restricted-v2
$ oc adm policy add-scc-to-user anyuid -z legacy-sa -n legacy
$ oc adm policy remove-scc-from-user anyuid -z legacy-sa -n legacy
$ oc get pod failing-pod -n legacy -o yaml | grep -i scc
$ oc auth can-i use scc/anyuid --as=system:serviceaccount:legacy:legacy-sa

SCC vs PSA

PSA evaluates pod spec against Kubernetes Pod Security Standards via namespace labels. SCC additionally enforces OpenShift UID ranges (runAsUser strategy), SELinux contexts, volume types, and seccomp defaults. A pod can pass SCC but fail PSA restricted, or vice versa—test both.

OAuth server & oauth-config

Cluster OAuth config lives in the OAuth cluster resource (config.openshift.io). Identity providers are defined under spec.identityProviders—type LDAP with bind DN, URL, and attribute mappings.

# Fragment — OAuth cluster spec.identityProviders (LDAP)
- name: corp-ldap
  mappingMethod: claim
  type: LDAP
  ldap:
    url: ldaps://ldap.corp.example:636
    bindDN: cn=ocp-bind,ou=svc,dc=corp,dc=example
    bindPassword:
      name: ldap-bind-password
    insecure: false
    ca:
      name: ldap-ca
    attributes:
      id: ["dn"]
      email: ["mail"]
      name: ["cn"]
      preferredUsername: ["uid"]

LDAP attributes

Group sync — oc adm groups sync

LDAP groups map to OpenShift Group objects via a sync config file. Cron or an operator runs oc adm groups sync to reconcile membership—RBAC bindings reference OpenShift group names, not LDAP DNs directly.

apiVersion: v1
kind: LDAPSyncConfig
url: ldaps://ldap.corp.example:636
bindDN: cn=ocp-bind,ou=svc,dc=corp,dc=example
bindPassword: "/etc/secrets/ldap/bindPassword"
ca: /etc/secrets/ldap/ca.crt
insecure: false
rfc2307:
  groupsQuery:
    baseDN: ou=groups,dc=corp,dc=example
    scope: sub
    derefAliases: never
    filter: (objectClass=groupOfNames)
  groupUIDAttribute: dn
  groupNameAttributes: [cn]
  groupMembershipAttributes: [member]
  usersQuery:
    baseDN: ou=users,dc=corp,dc=example
    scope: sub
    derefAliases: never
  userUIDAttribute: dn
  userNameAttributes: [uid]
  tolerateMembersNotFound: false
  tolerateMembersOutOfScope: false

$ # Vanilla K8s: configure OIDC on API server flags or use webhook token auth
$ kubectl config set-credentials oidc-user \
  --auth-provider=oidc \
  --auth-provider-arg=idp-issuer-url=https://login.corp.example \
  --auth-provider-arg=client-id=kubernetes$ oc get oauth cluster -o yaml
$ oc login -u jane --server=https://api.ocp.corp:6443
$ oc adm groups sync --sync-config=ldap-sync.yaml --confirm
$ oc get groups | grep payments
$ oc adm policy add-cluster-role-to-group edit payments-devs

Audit policy levels

Backends

• Log file — --audit-log-path with rotation (--audit-log-maxage, --audit-log-maxbackup)
• Webhook — stream to SIEM (Splunk, Elastic, Loki ingest)
• Batch — buffer and flush (trade latency for throughput)

apiVersion: audit.k8s.io/v1
kind: Policy
rules:
  - level: None
    users: ["system:kube-proxy", "system:kubelet"]
    verbs: ["get", "watch", "list"]
  - level: Metadata
    resources:
      - group: ""
        resources: ["secrets", "configmaps"]
  - level: RequestResponse
    verbs: ["create", "update", "patch", "delete"]
    resources:
      - group: "rbac.authorization.k8s.io"
  - level: Metadata
    omitStages: [RequestReceived]
  - level: Request
    namespaces: ["payments", "cards"]

OpenShift audit log paths

On OCP, API server audit logs are written on control plane nodes under /var/log/kube-apiserver/audit.log (path may vary by release). Use oc adm node-logs to fetch without SSH.

$ # On self-managed clusters — tail API server audit log (path varies)
sudo tail -f /var/log/kubernetes/audit/audit.log | jq -c '.user.username,.verb,.objectRef'
$ # Filter RBAC changes
grep 'rbac.authorization.k8s.io' /var/log/kubernetes/audit/audit.log | tail -20$ oc adm node-logs --role=master --path=kube-apiserver/audit.log | tail -50
$ oc adm node-logs master-0 --path=kube-apiserver/audit.log | grep payments-devs
$ oc get cluster -o yaml | grep -A5 audit