Deny assignments

A deny assignment names principals, actions and a scope, and blocks those actions for those principals there. Denies are checked before anything else: a matching deny refuses the call even when a role — Owner, Platform Owner, or an active just-in-time grant — would allow it.

How a deny applies

A deny blocks a call when all of these hold:

• the caller, or a group the caller is a direct member of, is among its denied principals;
• neither the caller nor any of those groups is among its excluded principals;
• the action is among its denied actions, and not among the actions excluded from the deny;
• the call is at the deny's scope — or below it, when the deny applies to child scopes.

Denied actions follow the same wildcard rules as roles — see Actions and data actions. Denying apps/write also denies apps/delete.

Create a deny assignment

You need rbac/members/write on the boundary; Owner and Platform Owner have it.

1. In the portal at https://portal.example.com, open Access control (IAM), go to Deny assignments and choose Add.
2. Details:
   • Name (required, up to 128 characters) and an optional Description.
   • Scope — filled in with the boundary, /boundaries/<boundary-id>. To deny inside one resource group or on one resource, extend it: /boundaries/<boundary-id>/resourcegroups/web or /boundaries/<boundary-id>/resourcegroups/web/resources/apps/shop.
   • Apply to child scopes (resource groups and resources) — on by default. Turned off, the deny applies at exactly the scope and not below it.
3. Principals & Actions:
   • Denied principals — search and add at least one.
   • Excluded principals (exempt from this deny) — optional; principals the deny must never apply to, even through a group they belong to.
   • Denied actions — at least one, from the checklist or as a pattern.
   • Excluded from deny (NotActions) — optional; actions to take back out of the denied ones, for example to deny apps/* but keep apps/read.
4. Choose Create.

The deny is in force within a minute or two.

Who can be named

Unless you are a Platform Owner, every denied and excluded principal must be a user who is a member of the boundary's tenant; groups, service accounts and managed identities are refused. A denied principal that does not qualify is refused with "One or more principals are not members of this tenant.", an excluded one with "Excluded principal not a member of this tenant." A Platform Owner can name any principal. The platform's own service principals can never be named.

Data actions

The portal lists control-plane actions only. A deny can also block data actions — reading secret values, logs, terminals — when it is created through the API or the CLI, with dataActions and notDataActions next to actions:

stsh iam deny create --file deny.json

{
  "name": "No secret values for contractors",
  "actions": ["secretvault/write"],
  "dataActions": ["secretvault/readSecrets"],
  "scope": "/boundaries/<boundary-id>",
  "principals": ["<user-principal-id>"],
  "applyToChildScopes": true
}

Every deny needs at least one control-plane action in actions, even one that is mostly about data.

Remove a deny assignment

A deny assignment cannot be changed. To change one, create the new deny and delete the old: on the Deny assignments tab choose the bin next to it and confirm with Delete. Access the deny blocked comes back, if a role grants it.

Denies also affect what the platform writes into Kubernetes, but far less completely: a deny made in the portal does not take away the Kubernetes rights of Owner, Contributor, Reader or any other role with data actions. An operator can read the rules in Kubernetes RBAC.