Authentication, authorization, and admission

The triple-A pipeline runs on every authenticated request. This page is a tour of how the three stages are composed inside kube-apiserver and where the source code lives.

The pipeline

graph LR
    Req[HTTP request] --> AuthN[Authenticator]
    AuthN -->|user.Info| AuthZ[Authorizer]
    AuthZ -->|allowed| MAdmit[Mutating admission]
    MAdmit --> VAdmit[Validating admission]
    VAdmit --> Strat[Strategy + Storage]
    Strat --> Etcd[(etcd)]
    AuthN -.reject.-> R401[401]
    AuthZ -.reject.-> R403[403]
    MAdmit -.reject.-> R422[422]
    VAdmit -.reject.-> R422

Authentication

The authentication chain is built in pkg/kubeapiserver/authenticator/config.go. It is a list of authenticator.Request instances tried in order; the first one that returns (user.Info, true, nil) wins.

Built-in authenticators:

• X509 client certificates (staging/src/k8s.io/apiserver/pkg/authentication/request/x509).
• Bearer tokens read from a static file (staging/src/k8s.io/apiserver/pkg/authentication/request/bearertoken). Largely deprecated.
• Service account tokens (pkg/serviceaccount/). Two flavours: legacy auto-generated (deprecated) and projected bound tokens.
• OpenID Connect (OIDC) (staging/src/k8s.io/apiserver/pkg/authentication/token/oidc). Validates JWTs from a remote IdP.
• Webhook (staging/src/k8s.io/apiserver/pkg/authentication/request/webhook). Delegates to an external HTTP service.
• Bootstrap tokens (used by kubeadm during init/join).
• Anonymous (last in the chain; turns unauthenticated requests into the system:anonymous user).

The structured authentication config (the file passed via --authentication-config) is parsed by staging/src/k8s.io/apiserver/pkg/apis/apiserver/v1, which lets cluster admins declare multiple JWT issuers, claim mappings, and prefixes without dropping back to flags.

Authorization

The authorization chain is built in pkg/kubeapiserver/authorizer/config.go. It is a list of authorizer.Authorizer instances; the first one that returns Allow wins. --authorization-mode=Node,RBAC sets the order.

Built-in authorizers:

• AlwaysAllow / AlwaysDeny — testing only.
• ABAC — legacy, file-driven. Avoid.
• RBAC — staging/src/k8s.io/apiserver/pkg/authorization/rbac/. Stores Role, ClusterRole, RoleBinding, ClusterRoleBinding. Checks request attributes against a transitive set of permitted verbs/resources.
• Node authorizer — plugin/pkg/auth/authorizer/node/. Restricts kubelet identities to nodes/pods/secrets/configmaps that belong to their node, computed from a graph of object references.
• Webhook — staging/src/k8s.io/apiserver/pkg/authorization/webhook/. Sends SubjectAccessReview to an external service.

A new structured authorization config (--authorization-config) lets admins declare an ordered list of authorizers and per-authorizer config in YAML.

Admission

Admission runs after authorization and before storage. It is a chain of mutating admission plugins followed by a chain of validating admission plugins.

Built-in plugins live under plugin/pkg/admission/:

Plugin	Purpose
noderestriction	Restrict kubelet writes to its own Node and Pods
serviceaccount	Inject SA tokens, default SAs
podsecurity	Apply Pod Security Standards (uses staging/src/k8s.io/pod-security-admission)
resourcequota	Enforce ResourceQuota
limitranger	Default container resource requests/limits
priority	Resolve priorityClassName to numeric priority
defaulttolerationseconds	Default node.kubernetes.io/not-ready tolerations
eventratelimit	Throttle Event creation
namespacelifecycle	Block writes to terminating namespaces
mutatingwebhook / validatingwebhook	Dynamic admission via external webhooks
validatingadmissionpolicy	CEL-based declarative validation (the modern alternative to webhooks)
storageobjectinuseprotection	Block PV/PVC delete while in use
runtimeclass	Validate RuntimeClass references
certificatesubjectrestriction / certificateapproval / certificatesigning	Restrict CertificateSigningRequest behaviours

The admission chain order is set in pkg/kubeapiserver/options/plugins.go and selected per-binary by the --enable-admission-plugins and --disable-admission-plugins flags. The webhook plugins talk to remote MutatingWebhookConfiguration and ValidatingWebhookConfiguration resources via staging/src/k8s.io/apiserver/pkg/admission/plugin/webhook/.

ValidatingAdmissionPolicy (CEL)

ValidatingAdmissionPolicy and ValidatingAdmissionPolicyBinding resources let admins write declarative validation rules in CEL. The implementation is in staging/src/k8s.io/apiserver/pkg/admission/plugin/policy/validating/. Mutating policy via CEL is in development behind a feature gate.

Compared to webhooks, CEL admission is:

• In-process (no extra hop)
• Type-checked against the resource schema at registration
• Cheaper and easier to reason about for simple field-level rules

Audit

Every authenticated request is recorded by the audit subsystem (staging/src/k8s.io/apiserver/pkg/audit/). Audit policies (audit.k8s.io/v1 Policy objects) decide which requests get logged at which stage and at which level. Sinks include log file, webhook, and a dynamic backend.

Putting it together

The order in kube-apiserver is fixed:

1. TLS termination
2. Filter chain — panic recovery, request info, cache control, authentication, audit, impersonation, max-in-flight + flow control, authorization
3. Per-handler admission (mutating then validating)
4. Strategy hooks (validate, default, transitions)
5. Storage write to etcd
6. Watch fan-out

A reader investigating an unexpected 403, 422, or 409 should walk this list from top to bottom; almost every request-rejection has a logged trail in audit + apiserver logs at --v=3 or higher.