Platform Access Model

A principal is the identity a platform authenticates and names when it decides whether a call is allowed: a person's login, a workload such as a batch job or service, or a group that holds grants for the humans inside it.

Creating a new key does not disable the old one. Revoke the exposed credential first so it stops authenticating immediately, then issue replacements, then read back what the leaked credential actually called before it was stopped.

Federated workforce logins keep one copy of each person, in the company directory: cloud access follows group membership, and disabling the directory account cuts every federated sign-in at once. Local platform logins are extra credentials nobody remembers to delete.

Attaching an identity to a workload means running your own code as that identity. If any stronger identity can be attached, the team can launch code that borrows its permissions, so the attach grant is worth the strongest identity it reaches.

Each axis cuts a different dimension of blast radius: actions limit what the caller may do, resources limit what it may touch, conditions limit the circumstances in which the grant applies. Narrowing one leaves the other two wide.

An identity-attached grant travels with the caller and cannot name a principal, because the principal is whatever it is attached to. A resource-attached grant lives with the thing being called and names the principal explicitly. Inside one account either side may allow; across an account boundary both normally must.

Copying a credential leaves no trace. The platform records calls that presented the key, never who holds it, and every use — a clone, a build, a log line, a pasted message — creates another copy nobody counted.

The founding owner credential is the identity a cloud account was created with, and the platform reserves a short list of account-level actions for it — closing the account, changing its registration and billing details, and recovering from a permission configuration that locked everyone else out.

A usage window shows what was called, never what is needed. It misses work that did not run inside it — periodic jobs, failure and recovery paths, rarely-taken branches. Cover it with a window longer than the longest business cycle, a declared list of rare operations, and a watched rollout.

The machine's whole credential set — identifier, secret and session token — in plain text, usable from anywhere until it expires. Nothing binds it to the machine, so the attacker then calls the platform directly as that workload.

Check which principal the failed write actually ran as. Your session and the job are two different principals, so the grants that covered you need not cover it — and across an account boundary the store's owner must name the job's identity, which no change on your side can supply.

Each node stops holding anything worth stealing. It asks its own issuer for a signed assertion and exchanges that for a short-lived platform credential per call, while the platform's trust sits on the issuer rather than on a secret you distributed.

Removal is all downside for whoever does it: an outage if they are wrong, no visible reward if they are right, and usually no way to prove nothing still calls it. The cost is standing access with no remaining function, unmonitored precisely because nothing legitimate uses it.

The same one the checkout service gets. The credential endpoint answers a machine, not a process or a local user, so everything running on that box receives the machine's identity and its full set of permissions.

Not granting produces an implicit deny, which any later allow overturns. An explicit deny is a rule that outranks every allow on either side, so it survives someone else adding a grant — and only editing or removing the deny itself undoes it.

The platform stores only a registration: which outside issuer it will accept, how narrowly, and which platform identity a matching caller may take on. It stores no secret belonging to the caller and nothing to rotate.

Write access to the permission system is write access to your own limits: the principal appends an allow for every action, or attaches a stronger document to itself, and is administrator on the next call. Nothing else in the estate had to change.

It reaches everything every identity it may issue for can do. Issuing credentials is authentication material, not authorization, so no permission changes anywhere — the holder simply authenticates as a stronger principal and acts as it.

That a forged fetch is one-shot and shape-constrained. The attacker controls a URL, not the method and not the headers, and cannot carry a value returned by one request into the next one.

The job resolves its short-lived credential once at start-up and holds those values for the whole process. When the session expires mid-run, every later call is refused for authentication, not permissions. Re-resolve before the expiry the source returned.

A break-glass login is safe to keep only when it cannot be used quietly: a named trigger, an approval by a second person, a session that expires on its own, an alarm nobody can suppress, rotation afterwards, and a rehearsal recent enough to prove it still works.

The leaver leg of joiner-mover-leaver failed: nothing reconciled the account's own principals back to the company directory, so something created inside the account outlived the person. Evidence is a dated reconciliation naming every principal, its matched owner, the reviewer, and what was removed.

Three kinds: a caller nothing signs for, a caller that cannot reach its issuer and the platform when it needs to act, and a caller whose issuer belongs to someone else. The first two keep a stored credential; the better fix is a component you operate in front.

Name the verb classes that are administrator regardless of how narrow they look — writing permissions, attaching an identity, issuing credentials, taking on an identity — cap every self-service principal with a ceiling it cannot write past, and review reachability rather than documents.

Decide by how the grant is expressed and where the consequence is. Grants scoped by a rule the new resource automatically satisfies stay narrow without maintenance; strictness is then spent on the places where a mistake is unrecoverable, and relaxed where it is not.

Not as one number. Classify callers by what an expiry costs them and what a leaked credential would cost you, set a short default with a documented ceiling, and grant exceptions that carry an owner and a review date.

Because each hop is narrow and correct on its own, and escalation is a property of the path, not of any single grant. Reachability has to be computed across the whole set; no document names the principal two hops away.

Count what is granted against what is exercised. Per principal, the permissions allowed but never used in a window, and the share of principals holding a wildcard on any axis, give two numbers that can be trended, attributed to an owner, and argued with.

It blocks anything a routing hop away — a container on an address-translated network, a proxy relaying an outside request, a neighbouring machine — because the reply dies in transit. Code in the host's own network namespace is untouched.