Admin access

Who may change the deployment, as against who may use it. This is the second of the two authorization systems, and the one people arrive at by asking a question about the first. Authorization is the page that argues why they are separate. This one says which guide you want.

The caller here is a person or a workload rather than an application holding a key, identity comes from a provider you already run, and the default is deny. A Cedar policy cannot read a request body. A CEL condition cannot authorize an API call. Neither can reach the other, and that keeps each one small enough to be right.

Authentication: who the caller is

pistra verifies tokens and issues none. There is no user database, no password and no session on the server, so a role comes from what your directory asserts about somebody’s group membership. Workloads need none of that registration, because they already hold a token their own platform minted. → Connect your identity provider

There is no shared admin token to distribute or rotate either. pistra login runs the authorization-code flow with PKCE against that same provider, and the device flow when there is no browser to open. → Sign in from the command line

Authorization: what that caller may then do

Admin authorization is a Cedar policy file that denies by default. Its vocabulary is checked when the file compiles rather than when a rule first fires, because Cedar skips a policy that errors. A typo inside a forbid would mean that forbid silently stopped forbidding. → Restrict what an admin caller can do

When the provider does not answer

Everything above assumes an identity provider that is reachable. The local Unix socket is the door for when it is not. It has no issuer, no bearer token and no secret anywhere, because the credential is filesystem access. It has to be open beforehand to be a break-glass door at all, so it is filed with the other day-two jobs rather than here. → Reach the admin API without your identity provider

Reference

Every action a Cedar policy may name, by resource class, is in the policy reference. The audit trail reference says what each decision records, including which policy @id decided, and what it means when none did.