PoliciesUsers

Create a policy

Choose a rule, fill in what it allows or requires, name the policy, pick its clusters and decide whether it enforces at once.

Requires: policies/write

Creating a policy needs policies/write in the boundary; the Owner and Contributor roles have it. A policy applies to the boundary you are working in.

Open the dialog

In the portal at https://portal.example.com, open Policies under Security in the sidebar and choose Create policy. The Create policy dialog asks, from the top, what the policy enforces, its parameters, its name and description, its scope, and whether to enforce it.

Choose the rule

Pick one rule under What this policy enforces. A policy holds exactly one rule; create several policies to combine rules.

Rule	Parameters
Allowed compute plans	The plans resources may use
Required labels	Label keys, each with an optional required value
Allowed registries	Registry prefixes images may come from
Disallow the latest tag	None

Before you enforce an admission rule, read what it checks in Rule reference: it also applies to the pods and jobs the platform creates for your resources.

Fill in the parameters

Allowed compute plans

Allowed compute plans lists the plans this boundary offers, grouped by the resource type that offers them — apps, container instances, functions, PostgreSQL, SQL Server, Qdrant and Valkey. Tick the plans to allow; choose at least one.

Important

A ticked plan is allowed for every resource type, and the policy restricts every resource type to the ticked names. Ticking only app plans therefore also blocks creating a Valkey store or a database whose plans have other names. Tick the plans of every resource type you want to keep available.

If the plans cannot be loaded, the dialog offers a text list instead, where you type plan names. A name that matches no plan allows nothing. A plan that is already on the policy but no longer offered stays listed under No longer offered.

Required labels

Add a row per label with Add label: a Label key and, optionally, a Required value. With the value empty, the label only has to be present; with a value, it has to have exactly that value. Each key may appear once.

Allowed registries

Under Allowed registry prefixes, add one prefix per row with Add, such as ghcr.io/acme. An image is allowed when it is a prefix itself or continues it after a /: ghcr.io/acme allows ghcr.io/acme/web:1.4 but not ghcr.io/acme-tools/web:1.4.

Disallow the latest tag

This rule has nothing to fill in.

Name and description

Name — 3 to 63 characters: lowercase letters, digits and hyphens, starting and ending with a letter or digit. It must be unique in the boundary and is how the policy is addressed. The name cannot be changed in the portal after the policy is created.
Description — optional, at most 256 characters.

Scope

Scope is All clusters by default: every cluster the boundary spans, including clusters it spans later. Pick a single cluster to limit the policy to that one.

Allowed compute plans ignores the scope: it applies to the whole boundary, whichever cluster is chosen.

Enforce or not

Enforce this policy is on by default. Switch it off to install the policy without it blocking anything, and switch it on later from the list — see Enforce or disable a policy.

Create it

Choose Create policy. The platform stores the policy and writes it to each cluster in its scope straight away, and the toast Policy created appears — also when a cluster could not take it. A cluster that cannot be reached at that moment gets the policy at the platform's next retry, by default within five minutes. The policy appears in the list with its rule, scope and state.

With the API

There is no stsh command that creates a policy; use stsh api or any HTTP client with POST /boundaries/<boundary-id>/resources/policies:

bash

stsh api POST /boundaries/<boundary-id>/resources/policies -d '{
  "name": "no-latest",
  "description": "Pin every image",
  "ruleKind": "DisallowLatestTag",
  "clusterId": null,
  "enabled": true,
  "parameters": {}
}'

ruleKind is AllowedComputePlans, RequiredLabels, AllowedRegistries or DisallowLatestTag.
parameters carries exactly the member of that rule — allowedComputePlans (a list), requiredLabels (an object of key to value, "" for any value) or allowedRegistries (a list) — and nothing for DisallowLatestTag.
In allowedComputePlans, an entry can name the resource type it applies to, such as valkey/small. Such an entry applies only to that type, and a policy whose entries all name other types says nothing about a type. The portal writes plain plan names only.
enabled left out means enabled. clusterId left out or null means all clusters.
The API checks only that the name is not blank and is unique in the boundary; the portal's name rules above are the portal's.

The answer is 201 with the policy, including a projections list with one entry per cluster the policy was written to: applied, and a message when it was not. The list is empty for Allowed compute plans, which is never written to a cluster. Refusals are listed in API errors.