allow runs it, approve runs it
once a human has approved that exact action, and deny refuses it. There is no fourth value, and
an action the policy does not list is denied.
How a decision is reached
runnable
when: is a mapping of <argument>_<op>
keys, all of which must hold: eq, neq, in, lt, lte, gt, gte. A rule with no
when: always matches, which is how the last line becomes the default for that action. An
action with a bare decision: and no rules decides the same way for every argument.
Granting reader runs on its own; granting admin is refused for everybody; anything else
waits for a person.
What the policy cannot see
The policy sees the action’s name and its arguments and nothing else. It cannot see the principal:agent_eq, user_eq and every other principal-addressing condition is refused when
the file loads, not silently matched. That is deliberate and it is the second principle on the
Why page: how much autonomy iam.grant_role has is the same for everyone; who may
propose it at all is the job of authority.
The guarantee it supports
Per-action policy, and fail closed. A rule cannot widen anything by omission: a missing rule means the default, a missing action means denied, and a missing or malformed file means noControl at all.
What it does not do
A decision is not an authorization.allow says the action may run without a person; it does
not say this principal may propose it, which authority decides first. And a decision is not an
outcome: an allowed action can still be refused at reservation because its effect key is held,
or end AMBIGUOUS because the remote did not answer.
Next
- Approval binding: what
approvesets in motion. - Authority and delegation: the axis the policy cannot see.
- Policy YAML reference · Get started.