Provisioning Policy Scope
Overview
The scope of this policy determines its applicability to specific workspaces and stages.
If multiple policies are applicable that define a limit (for example, multiple applicable policies all define the allowed regions), the most specific policy defining that limit will take precedence.
The specificity order is as follows, from most to least specific:
- Policy with both a specific stage and workspace
- Policy with a specific workspace and all stages
- Policy with a specific stage and all workspaces
- Policy with all stages and all workspaces
When multiple policies have the same level of specificity, the least restrictive intersection of those policies will apply.
📚 Explore the examples sections for more details on policy scope.
📚 For more details on key points, refer to the overview section.
📚 Explore the properties section for additional information on each UI property.
CLI Instructions
Follow the instructions in the details section.
Web Interface Instructions
Steps
- Fill in the scope details as outlined in the properties section.
- Click Continue to proceed
Screenshot(s)
Properties
| Field | Description |
|---|---|
| Stage | The stage(s) where this provisioning policy is applied. A [stage]/wayfinder/admin/stages/stages-overview is used to isolate and test resources at the infrastructure level. Adding a stage to a provisioning policy restricts its availability to that specific stage, such as production or non-production. |
| Workspace | The workspace(s) where the provisioning policy is applied. A workspace is where teams provision and manage applications, environments, clusters, and cloud resources. By adding a provisioning policy to a specific workspace restricts how and where workspace owners and members can provision clusters. |
Examples
Stage and Workspace Combinations
| Stage toggle | Workspace toggle | Policy Active? | Details |
|---|---|---|---|
| OFF | OFF | ✔️ (all) | The policy is active across all workspaces and stages whenever a user attempts to create or provision a cluster. |
| OFF | ON (no selections) | ✖️ | The policy is inactive and will not be applied. |
| OFF | ON (with selections) | ✔️ (selected) | The policy is active in the selected workspaces across all stages. |
| ON (no selections) | OFF | ✖️ | The policy inactive and will not be applied. |
| ON (with selections) | OFF | ✔️ (selected) | The policy is active in the selected stages across all workspaces. |
| ON (with selections) | ON (with selections) | ✔️ (selected) | The policy is active in the selected stages and selected workspaces. |
| ON (no selections) | ON (no selections) | ✖️ | The policy is inactive and will not be applied. |
Policy Applicability Examples
Each policy rule (e.g., the region where a cluster can be provisioned) is scoped individually, with the most specific policy governing that rule winning.
The table below shows whether a cluster provisioning policy rule will apply to a user in a specific workspace who is trying to provision a cluster in a particular stage (prod/non-prod).
| Policy Stage Toggle | Policy Workspace Toggle | User's Workspace | Cluster's Stage | Policy Applies? |
|---|---|---|---|---|
| Off | dev1 selected | sales | prod | no (workspace doesn't match) |
| non-prod selected | dev1 selected | dev1 | prod | no (stage doesn't match ) |
| non-prod selected | Off | dev1 | prod | no (stage doesn't match) |
| prod selected | dev1 selected | dev1 | prod | yes |
| prod selected | Off | dev1 | prod | yes |
| prod selected | Off | sales | prod | yes |
Winning Rule Examples
Assume two scoped policy rules apply to a user's workspace and the stage where the cluster is to be provisioned (see previous examples).
The tables below illustrate the end result.
Example 1
| Policy | Scope | Rule |
|---|---|---|
| policy1 | All workspaces, all stages | Allowed regions: uksouth, ukwest |
| policy2 | Workspace: ws1, all stages | Allowed regions: europenorth |
Result: regions limited to europenorth (policy 2 is more specific)
Example 2
| Policy | Scope | Rule |
|---|---|---|
| policy1 | workspace: ws1, all stages | Allowed regions: uksouth, ukwest |
| policy2 | workspace: ws1, all stages | Allowed regions: europenorth |
Result: regions limited to uksouth, ukwest, europenorth (both policies have same specificity)
Example 3
| Policy | Scope | Rule |
|---|---|---|
| policy3 | workspace: ws1, all stages | Max cluster cost per month: $800 |
| policy4 | workspace: sand, all stages | Max cluster cost per month: $2000 |
- Result for ws1: Max cluster cost per month: $800
- Result for sand: Max cluster cost per month: $2000
Taking the results from Examples 2 and 3, the user will be allowed to provision a cluster with the following conditions:
- ws1:
- Allowed regions: ukwest, uksouth, europenorth (from policy1 and policy2),
- Max cluster cost per month: $800 (from policy3)
- sand
- Allowed regions: no restrictions
- Max cluster cost per month: $2000 (from policy4)