Docs

Policies

What this screen is for

A policy is where permissions are chosen and, crucially, where they are limited. A policy is made of statements; each statement lists permissions and can restrict them to specific clusters (resources) and environments (conditions).

This is the only place scoping exists. A permission selected without scoping applies everywhere — every cluster, every environment.

Before you start

To do this You need
See the tab platform-settings.permission-policy.read
Create a policy platform-settings.permission-policy.create
Edit a policy platform-settings.permission-policy.update
Delete a policy platform-settings.permission-policy.delete

Register your clusters and environments first, in Infrastructure. A statement cannot be scoped to something that does not exist yet, and this is the usual reason a first-day policy ends up unscoped.

Opening it

  1. Settings › People & Access
  2. Select the Policies tab.

The interface

📸 Screenshot Placeholder: The policy editor with one statement expanded. Mark: (1) the permission tree, (2) the cluster selector, (3) the environment selector, (4) the statement summary line, (5) Save.

# Control What it does When you’d use it
1 Permission tree Selects permissions, grouped by plugin and resource Every policy
2 Cluster selector Limits the statement to specific clusters Any policy touching infrastructure
3 Environment selector Limits it to dev, staging, production — one or several Any policy touching deployments
4 Statement summary Reads back what the statement covers, e.g. “2 cluster(s)” Confirming the scope before saving
5 Save Writes the policy Finishing

The summary line is the fastest check you have. If it does not mention clusters or environments, the statement is unscoped.

Walkthroughs

Create a scoped policy

Requires platform-settings.permission-policy.create.

  1. Settings › People & Access › Policies, click Add Policy.
  2. Name it after what it allows, e.g. Dev Deploy, not after who gets it.
  3. In the statement, select the permissions from the tree.
  4. Select the clusters the statement applies to.
  5. Select the environments — one or several.
  6. Read the summary line and confirm it names both.
  7. Save.

Widen or narrow an existing policy

Requires platform-settings.permission-policy.update.

  1. Open the policy, adjust permissions or scope, and save.
  2. The change reaches every role carrying that policy, and therefore every user holding those roles. Check which roles use it before editing.

Delete a policy

Requires platform-settings.permission-policy.delete.

Roles referencing it lose what it granted. Check the roles first — a role left with no policies grants nothing and gives no warning that it used to.

Scenario

Letting the on-call team restart production workloads without giving them production deployments.

The distinction is narrow, which is exactly the kind of case policies exist for.

  1. Create a policy named Prod Oncall.
  2. In the statement, select only the specific operational permissions on-call needs. Do not select the deployment permissions.
  3. Scope resources to the production cluster only.
  4. Set the environment condition to production only.
  5. Confirm the summary names one cluster and one environment.
  6. Save, then attach it to an On-Call role — on its own, not alongside a broader deployment policy, or the broader one wins.
  7. Verify in Access Explorer that a production deployment permission still resolves as denied for an on-call user.

Step 7 matters because permissions are additive: a user holding two roles gets the union. Narrowing one policy achieves nothing if another grants the same thing.

When it doesn’t work

Symptom Cause How to check Fix
Policy grants more than intended The statement has no cluster or environment scope Read the statement summary line Add the cluster resource and the environment condition
Cluster or environment missing from the selector It is not registered yet Infrastructure Register it, then edit the policy
Narrowing a policy changed nothing Another role the user holds grants the same permission Access Explorer for that user Permissions are additive — audit every role they hold
An env-by-branch permission behaves oddly across environments Flat names expand to per-environment variants at check time See the platform permission model Scope explicitly rather than relying on the flat name
Policy edited, user sees no change Session permission cache — Ask them to reload

Next