Every request to the interface server is authenticated, then authorised, then admitted. The first stage is the one with the most surprising design decision in the whole system: the cluster has no record of its human users at all, and understanding why explains most of what follows.

There are no user objects

One absence shapes everything.

The cluster stores roles and bindings, but it stores no users and no groups. A user is simply a string that an authenticator produced, and a group is another string. Bindings refer to those strings, and nothing validates that the subject of a binding corresponds to anyone who exists.

Two consequences follow. A binding can be written for a user who has never existed, and it will sit there harmlessly until someone with that name authenticates, which makes typos in subject names silently ineffective rather than rejected. And removing a person's access cannot be done inside the cluster, because the cluster never knew about them; it is done wherever the authenticator gets its identities.

The authentication methods

Four mechanisms in practical use.

Client certificates, where the subject's common name becomes the username and its organisation fields become groups. Bearer tokens issued for service accounts. An external identity provider, where the cluster validates a signed token and reads the username and groups from configured claims. And an authentication webhook, where the cluster asks an external service to validate an opaque token.

The method chosen determines what revocation means, which is the question most worth asking. A certificate cannot be revoked, only allowed to expire, which is why certificates are a poor choice for humans. An identity provider's token expires in minutes and the provider decides whether to issue another, which is why that is the right choice.

Certificates and the revocation problem

One detail is frequently learned the hard way.

There is no certificate revocation list. Once a client certificate is signed by the cluster's authority, it is valid until it expires, and the only way to invalidate it is to rotate the signing authority, which invalidates every certificate at once.

So a certificate issued to a person with a year's validity is a year of access that cannot be withdrawn. The reasonable uses are short-lived certificates issued automatically, and the cluster's own components. For humans, an identity provider with short tokens is the only arrangement where leaving the organisation actually removes access, and clusters configured otherwise usually discover this during an offboarding review.

Groups, and where authorisation really happens

One indirection does the real work.

Bindings should name groups rather than individuals, so that joining a team grants access and leaving removes it, with no cluster change. The groups come from the authenticator: certificate organisation fields, a claim in a token, or a webhook's response.

This is the arrangement that keeps authorisation maintainable, because the cluster then contains a stable mapping from group to permissions, and the volatile mapping from person to group lives in the identity system where joiners and leavers are already handled. A cluster with dozens of bindings naming individuals is a cluster whose access list is wrong and nobody knows by how much.

The authorisation modules and their order

One rule governs the combination.

Several authorisation modules may be configured, and they run in order. Any module that allows the request ends the evaluation. A module that does not allow it passes to the next. If none allows, the request is forbidden.

The important property is that there is no deny. A module cannot forbid something another module allows, which means permissions are purely additive and the question of whether someone can do something is a union over every binding that applies to them. That makes answering it harder than it looks and makes the idea of an exception to a broad permission impossible to express.

The node authoriser

One module exists for a specific reason.

Requests from node agents are authorised by a dedicated module that grants each agent access to exactly the objects relevant to the pods scheduled on its node: those pods, their configuration maps, their secrets, their claims.

Without it, every node agent would need permission to read every secret in the cluster, which would make a single compromised node a cluster-wide secret disclosure. With it, compromising a node exposes only what that node's pods already had. This is worth knowing because it is the model to imitate: scope access to what the holder already has access to in practice, rather than to the class of object.

Permission checks before you act

One facility answers questions directly.

The cluster can be asked whether a given subject may perform a given action, which is how tools check their own permissions and how an operator answers whether a user can do something without trying it.

Two forms matter. The self check, asking whether the current credentials permit an action, which is what a well-behaved tool uses to give a clear error rather than a forbidden response mid-operation. And the full check, asking about another subject, which requires elevated permission and is the correct way to audit access. Both are far more reliable than reading bindings, because they evaluate the real union.

Impersonation, for testing and for danger

One feature is indispensable and must be restricted.

A sufficiently privileged user can make a request as another user or group, which means an administrator can verify exactly what a role permits by acting as a subject bound to it.

That makes impersonation the best tool for testing authorisation, and it also makes the permission to impersonate equivalent to the permission to do anything any user can do. So it belongs with cluster administrators only, it should be audited, and the audit log records both the impersonator and the impersonated, which is the detail that makes it reviewable rather than a hole.

Anonymous requests and the system groups

One configuration detail is worth checking on any cluster.

Unauthenticated requests may be allowed through as an anonymous user in a system group, which exists so that health endpoints and version discovery work without credentials.

What matters is what that anonymous identity can reach, because a binding granting a broad role to the group containing all authenticated subjects is a common mistake, and the group containing unauthenticated ones is worse. Checking what the anonymous and all-authenticated groups can do is a five-minute audit worth doing on every cluster, and it occasionally finds a binding someone added to make a tool work.

What authentication implies for design

One principle follows from the model.

Because the cluster has no users, no revocation and no deny, authorisation design must put the volatile parts outside the cluster and keep the cluster's own configuration stable and additive.

Concretely: identities and group membership in an identity provider with short-lived tokens, a stable set of roles in the cluster, bindings naming groups, and no reliance on being able to withdraw a credential quickly. A design fighting any of those properties will work until the first time someone leaves the organisation in a hurry.

What the audit log records about identity

One record is the only reliable history.

Each audit entry carries the authenticated username, the groups, the impersonated subject if any, the authorisation decision and which module made it, along with the object and verb.

That makes the audit log the answer to who did this, and also to who could have, since a decision recorded as allowed by a particular module tells you which binding to look for. The configuration determines how much is kept, and the setting worth getting right is that metadata for every request is recorded at minimum, because an audit policy that omits read requests cannot answer whether a secret was read, which is usually the question asked.

Credentials that are not people at all

One category is larger than the human one.

Most requests to the interface server come from software: controllers, operators, delivery agents, monitoring, and the cluster's own components. Each authenticates as a service account, with a token rather than a certificate, and each has a role sized by whoever installed it.

These are the accounts worth auditing first, because there are more of them, they hold permissions nobody reviews, and a monitoring agent granted read access to every object in the cluster is a credential with more reach than any engineer has. The rest of this lesson is largely about them.