A team can create workloads and attach any existing identity to them, but holds no administrator permission — why is that grant administrator access anyway?
answer
- a grant that reads as deployment plumbing
- who runs the code afterwards
- using a permission without holding it
- the strongest attachable identity is the ceiling
- put a condition on the attach action
basics
~20 sAttaching 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.
solid answer
~40 sThe platform lets a workload carry an identity, and code inside that workload receives short-lived credentials for it. Creating the workload and choosing its identity are two ordinary-looking actions, but the second one decides whose permissions your code runs with — and you never need to hold a permission to use it, only to start a process that holds it. So this team's effective access is not what its own principal is granted; it is the union of every identity it may attach, with the strongest one setting the ceiling. The path is: create a workload, attach the strong identity, supply your own start-up code, act, delete the workload. Nothing in the grant set changed, which is exactly why review misses it.
code
json · 9 lines{
"effect": "allow",
"actions": [
"workload.create",
"workload.attachIdentity"
],
"resources": ["workloads/team-checkout/*"],
"condition": {}
}go deeper
Remember that a workload runs with an identity, and the code inside it gets that identity's permissions automatically. Whoever decides which identity goes on the workload decides what the code can do.
Explain the mechanics: create and attach are separate actions, the attach call names an identity as a value rather than a resource, and the caller supplies the code. Show why the union of attachable identities is the real ceiling.
Demonstrate that you would look for this in a real grant set — the second pass that asks what a principal can cause something else to do — and that you would close it with a condition on the attach action rather than an alert.
Frame it as the cost of self-service: teams must attach identities to ship, so the standard has to say which identities are attachable and keep management permissions off anything a product workload is allowed to carry.
## The action nobody reads as a permission A cloud platform lets a workload carry an identity of its own. A virtual machine, a container task, a scheduled job or an event-driven function is launched with an identity attached, and code inside it then receives **short-lived credentials** from the platform, with no key stored on disk. That is the normal and recommended way to run anything. Creating the workload and choosing which identity it carries are separate actions in the management API, and on a self-service platform a product team holds both — it cannot deploy otherwise. The first action reads as capacity. The second reads as plumbing. It is not plumbing. **Choosing which identity a workload carries is choosing whose permissions your code runs with**, and you never have to hold a permission in order to use it; you only have to be able to start a process that holds it. So this team's effective access is not what its own principal is granted. It is the union of everything it may attach, and the strongest attachable identity sets the ceiling. ## Why it survives review - The grant names no administrative action at all. It names a create action and an attach action, both of them ordinary and both of them necessary. - The `resource` in the grant is the workload, which the team genuinely owns. The stronger identity appears only as a *value the team may supply*, never as a resource in that document. - The strong identity was created by somebody else for a legitimate purpose — a deployment identity, a data-processing identity, the identity a platform tool runs as. Its own document is correct. - The two documents are read by different people at different times. Neither one is wrong on its own, and the defect exists only in their combination. ## The path, step by step 1. Create a workload of a kind the team is already entitled to create. 2. Attach an identity stronger than the team's own principal. 3. Supply the code, image or start-up command — which the team also controls, because it is their workload. 4. Read the credentials the platform hands the workload, or simply act from inside it. 5. Delete the workload. The grant set is unchanged and nothing was escalated on paper. Step 3 is what separates this from an ordinary deployment. Attaching a strong identity to a workload somebody else defines is a design decision. Attaching it to a workload whose code you write is an identity hand-over. ## What the borrowed identity is and is not worth The running code holds exactly the borrowed identity's permissions. It does not also keep the team's own — this is a substitution, not a sum, though in practice the attacker can run two workloads and use both. Any `condition` attached to the borrowed identity still applies, so a grant that only allows a call from a particular network path or on a particular resource remains narrow after the hand-over. The credentials the workload receives expire, but the platform keeps renewing them for as long as the workload runs, so a short lifetime alone buys very little here. ## What actually closes it | Control | What it does | What it does not do | |---|---|---| | A `condition` on the attach action naming which identities may be attached | Refuses the call at attach time, so the path never opens | Help at all if the named set still contains a stronger identity | | Keeping management permissions off the identities workloads are meant to carry | Removes the prize | Prevent the attach call itself | | A ceiling above the principal that no local grant can exceed | Caps what a borrowed identity is worth inside that scope | Apply where the ceiling was never set | | An alert on workloads launched with an unexpected identity | Tells you it happened, after it happened | Prevent anything — a detective control is not a preventive one | Platforms differ in whether attaching an identity is a distinct permission at all, and in whether that action supports a condition naming the attachable set; some separate it precisely because of this path. What does not differ is the reasoning: wherever a caller may name the identity a workload will run as, that caller's ceiling is the strongest name it may supply. ## How to find it in a grant set Read the grant set twice. The first pass asks what this principal may do. The second asks what this principal may cause *something else* to do — attach an identity, write a permission, mint a credential, take on a session. Only the second pass finds this one, and it is the pass that gets skipped, because the first ends on a reassuring sentence: no administrative action is granted anywhere.
- What would you change in that grant to close the path without blocking the team?Add a condition to the attach action naming the identities that may be attached — usually the team's own workload identities — so the platform refuses the call when any other identity is supplied. That keeps self-service deployment intact and removes the ability to name an identity the team could not otherwise use. Then check that the permitted set contains nothing stronger than the team's own principal.
- The team says it only ever attaches its own identities, so the condition is unnecessary. Is that a reasonable argument?No. The grant is what the platform enforces; intent is not. If the only identities they use are their own, the condition costs them nothing and turns the claim into something the platform checks on every call. It also survives the next engineer, who will not know the convention.
- Does shortening the lifetime of the credentials the workload receives help here?Barely. The platform refreshes those credentials for as long as the workload runs, and the attacker controls the workload, so they hold a continuously renewed session. Short lifetimes limit a credential that leaks out of the workload; they do not limit whoever can attach the identity in the first place.
It is the difference between holding the master key and being allowed to hand the master key to a robot you built and programmed yourself. You never touch the key, and the doors still open.
saying these in an interview costs you the question
- Says creating workloads is harmless without administrative permissions
- Assumes you must hold a permission to use it
- Reads the attach action as deployment plumbing rather than a grant
- Reviews only what the team's principal can do directly
- Thinks an attached identity is limited to the workload's stated job
- Offers an alert on unexpected attachments as the fix