Wiki · Concept · Last reviewed June 25, 2026

Kubernetes AuthorizationConfiguration

Kubernetes AuthorizationConfiguration is the structured file format for configuring the API server authorizer chain.

Category: Concept Published: June 25, 2026 Modified: June 25, 2026 Last reviewed: June 25, 2026 Tags: Kubernetes, authorization, webhooks, CEL, AI governance

Definition

Kubernetes AuthorizationConfiguration is a kube-apiserver configuration file for defining the authorization chain. Kubernetes documentation marks the authorization configuration file feature as stable in Kubernetes v1.32 and enabled by default. The documented example uses apiVersion: apiserver.config.k8s.io/v1, kind: AuthorizationConfiguration, and an ordered authorizers list.

Authorization is the step after authentication. Kubernetes documentation says the API server may authorize requests through modes including AlwaysAllow, AlwaysDeny, ABAC, RBAC, Node, and Webhook. The structured file does not replace those authorizers; it gives operators a declarative way to order and parameterize them, including support for multiple authorization webhooks.

How It Works

The API server is pointed at the file with --authorization-config. Kubernetes documentation says operators must choose either file-based configuration or command-line authorization flags: setting both --authorization-config and authorization webhook command-line flags is not allowed, and the API server exits during startup if they are combined.

With file-based configuration, each authorizer item can define its type and parameters. For webhook authorizers, the documented fields include cache durations, cache toggles, timeout, subjectAccessReviewVersion, matchConditionSubjectAccessReviewVersion, failure policy, connection information, and CEL matchConditions. The feature lets the authorizer chain include multiple webhooks and use CEL rules to pre-filter requests before sending them to an external authorization service.

Kubernetes documentation also describes reload behavior. The API server reloads the authorization configuration when it observes a file change, and also checks on a 60 second schedule if no change event is seen. The same page warns that all control-plane nodes should have the same file contents. On reload, non-webhook authorizer types must remain unchanged; Node and RBAC authorizers may be reordered, but cannot be added or removed.

Agent Context

AI platforms often place many actors behind the same Kubernetes API server: model deployment systems, experiment runners, evaluation workers, CI bots, data pipelines, tool sandboxes, observability collectors, and human incident responders. RBAC is usually the local policy engine, but some decisions need external context: tenant contracts, risk tier, model release state, approval tickets, quarantine status, or data-use restrictions.

AuthorizationConfiguration is relevant because it can place those external decisions into a visible chain. A webhook can be scoped with CEL so it only sees the requests it is supposed to judge, such as changes to sensitive namespaces, model-serving resources, or high-risk workloads. That reduces needless disclosure to the webhook and makes the access-control design easier to audit.

Governance Use

A governance record should preserve the authorization configuration path, file hash, authorizer order, authorizer names, modes, webhook endpoints, kubeconfig references, failure policies, cache settings, timeout values, SubjectAccessReview versions, CEL match conditions, owning team, approval ticket, rollout time, and rollback plan. It should also record which requests are intentionally left to RBAC, Node authorization, or an external webhook.

Review should focus on three questions. First, what happens when a webhook is unreachable? A Deny failure policy protects sensitive resources but can break availability; NoOpinion can preserve availability but may defer too much to later authorizers. Second, what data is sent to each webhook? Match conditions should keep unrelated requests away from external systems. Third, who can bypass the chain? Kubernetes documentation warns that the system:masters group grants unrestricted access and bypasses authorization restrictions imposed by RBAC or webhooks.

Limits

AuthorizationConfiguration is not an identity provider. It relies on the identity produced by authentication, so it pairs naturally with Kubernetes AuthenticationConfiguration but does not replace it. It is also not a universal policy language. RBAC, Node authorization, and webhook authorizers still perform the actual decisions.

The file also does not eliminate privilege escalation paths. Kubernetes documentation warns that users who can create or edit workloads may escalate in a namespace by mounting secrets, using more privileged service accounts, or using related controller behavior. Structured authorization can put more judgment into the chain, but broad workload-creation rights still need careful review.

Source Discipline

Claims about feature state, configuration-file exclusivity, reload behavior, authorizer modes, system:masters, webhook fields, and workload privilege escalation should cite Kubernetes authorization documentation. Claims about goals such as multiple webhooks, ordered authorizers, failure policy, CEL pre-filtering, and automatic reload should cite KEP-3221. Claims about v1.32 graduation should cite the Kubernetes v1.32 release blog.

Spiralist Reading

Spiralism reads AuthorizationConfiguration as the table of judges inside the control plane.

The question is not only whether a request is allowed. It is who was asked, in what order, with what evidence, and what happened when a judge was silent. A machine institution becomes safer when its permissions have a public route through named authorities rather than an invisible collapse into default power.

Sources

Return to Wiki