Environments
What this screen is for
The Environments tab defines the deployment targets your teams work against — typically dev, staging and production — on the clusters you have registered.
Environments are what the Deploy area exposes, and what permission policies are scoped to. Until they exist, a policy cannot restrict anyone to dev.
Before you start
| To do this | You need |
|---|---|
| See the tab | platform-settings.environment.read |
| Create an environment | platform-settings.environment.create |
| Edit one | platform-settings.environment.update |
| Delete one | platform-settings.environment.delete |
Register and validate a cluster first. An environment on an unvalidated cluster inherits its problems.
Opening it
- Settings › Infrastructure
- Select the Environments tab.
The interface
📸 Screenshot Placeholder: The Environments tab listing dev, staging and production. Mark: (1) Add button, (2) search field, (3) the cluster column, (4) the environment type, (5) the row actions.
| # | Control | What it does | When you’d use it |
|---|---|---|---|
| 1 | Add | Opens the environment dialog | Defining a new target |
| 2 | Search | Filters the list | Installs with many environments |
| 3 | Cluster | Which registered cluster it runs on | Understanding blast radius |
| 4 | Environment type | dev, staging, or production | This is what policies scope to |
| 5 | Row actions | Edit, delete | Maintenance |
The environment type is not decoration. Permission policies condition on these exact values, and the backend expands flat permission names into per-environment variants using them. Getting the type wrong makes a policy apply to the wrong tier.
Walkthroughs
Create an environment
Requires platform-settings.environment.create.
- Settings › Infrastructure › Environments, click Add.
- Choose the cluster it runs on.
- Set the environment type — dev, staging, or production.
- Save.
- Go to Policies and confirm the new environment appears in the scope selector.
Delete an environment
Requires platform-settings.environment.delete.
Check first whether any policy is scoped to it. Deleting the environment does not update those policies, and a statement scoped to something that no longer exists is a confusing thing to inherit.
Scenario
Adding a second staging environment for a team that needs isolation.
Two teams keep colliding on one shared staging.
- Confirm the target cluster is registered and Valid.
- Settings › Infrastructure › Environments — create the new environment on that cluster, with type staging.
- Go to Policies. Existing staging policies are conditioned on the environment type, so they may now cover both staging environments — which is the opposite of the isolation you wanted.
- Narrow the affected statements: scope them by cluster as well as by environment type, so each team reaches only its own.
- Verify both teams in Access Explorer before telling them it is ready.
Step 3 is the trap. Adding an environment can silently widen existing policies, because the condition matches a type, not a specific environment.
When it doesn’t work
| Symptom | Cause | How to check | Fix |
|---|---|---|---|
| Cannot create an environment | No validated cluster | Clusters | Register and validate a cluster |
| Environment absent from a policy’s scope selector | Just created, or the policy was not reopened | The Policies tab | Reopen the policy |
| A new environment unexpectedly widened access | Policies condition on environment type, not on a specific environment | The affected policy statements | Add a cluster resource to narrow them |
| Deployments target the wrong tier | The environment type was set incorrectly | The environment type column | Correct the type, then re-check the policies |
| Policy scoped to a deleted environment | Deleting an environment does not update policies | The policy statements | Edit the policy |