Rule reference

Allowed compute plans

Checked by the platform when a resource is created, and when a change moves it to another plan, for:

• apps, container instances (each component's plan), PostgreSQL, SQL Server, Qdrant and Valkey.

A resource that already runs on a plan keeps it, and can be changed in other ways, even after a policy stops allowing that plan; only a move to another plan is checked.

A refused request answers 422 with the code compute_plan_not_allowed and a message naming the plan, such as Compute plan 'large' is not allowed in this boundary: a boundary policy disallows it. Allowed plans: small, medium. The portal shows that message, and its plan pickers show plans the policies do not allow as disabled, with the reason.

If the platform cannot read the boundary's policies, it refuses every create and plan change that this rule covers with 503 and the code compute_plan_policy_unavailable rather than allow it. Try again shortly.

Caution

Functions are not checked. The function plan picker greys out plans a policy does not allow, but a function created or changed through the API or the CLI gets any plan.

How plans combine:

• A plan name in a policy applies to every resource type. An API entry qualified with a type, such as valkey/small, applies to that type only.
• With several enforcing policies of this rule, a plan must be allowed by all of them that say something about the resource type.
• A policy that applies but whose names match no plan of that type allows nothing: every create of that type is refused.
• The policy's scope is ignored: the rule applies in every cluster of the boundary.

Admission rules

Required labels, Allowed registries and Disallow the latest tag are checked by Kubernetes in each cluster the policy is installed in. They check:

• Pods, Deployments, ReplicaSets, StatefulSets, DaemonSets, Jobs and CronJobs,
• when they are created or changed,
• in the namespaces labelled with the policy's boundary.

That includes what the platform creates there for your resources — the workloads of apps, static web apps, functions and container instances, and the jobs that build apps, static web apps and functions — not only what you deploy yourself.

Objects that already exist are not checked again until they change. A pod that has to be created anew — after a rollout or a scale-up, or when a pod is deleted or moved to another node — is checked, and if it breaks the rule it is not created, so a running workload can lose copies while a policy it breaks is in force. Check what your workloads use before you enforce a new rule.

A refused object is not created or not changed, and the refusal names the policy, for example Policy 'no-latest' (DisallowLatestTag) denied image nginx: it is tagged latest or carries no tag. If the check itself fails, the object is refused as well.

Caution

Admission rules need Kubernetes 1.30 or later. On an older cluster a policy is stored and written to the cluster, but enforces nothing — and neither the portal nor the API shows that. Ask your platform operator which Kubernetes version your clusters run.

Required labels

Every checked object must carry each listed label. With a required value the label must have exactly that value; with an empty value any value will do. The labels are read from the object itself, so a Deployment needs them on the Deployment and its pods on the pods.

Refusals read Policy 'owner-label' (RequiredLabels) requires the label team. or, with a value, … requires label team=web, found api (<unset> when the label is missing).

Allowed registries

Every container and init container image must be one of the listed prefixes or continue one after a /. The image is compared exactly as it is written in the pod:

Prefix	Allowed	Refused
ghcr.io/acme	ghcr.io/acme/web:1.4	ghcr.io/acme-tools/web:1.4
docker.io/library	docker.io/library/nginx:1.27	nginx:1.27

A trailing / on a prefix is ignored. List every registry the boundary's workloads use, including those of the images the platform runs for your resources.

Refusals read Policy 'trusted' (AllowedRegistries) denied image nginx:1.27: it is not under ghcr.io/acme.

Disallow the latest tag

Every container and init container image must carry an explicit tag other than latest, or a digest:

Image	Result
nginx:1.27	Allowed
nginx@sha256:…, nginx:latest@sha256:…	Allowed — a digest always is
nginx:latest	Refused
nginx, registry:5000/api	Refused — no tag means latest

Warning

A function built from code uploaded in the portal is built by a job that uses an image tagged latest. While this rule is enforced in the function's boundary, those builds are refused.

Refusals read Policy 'no-latest' (DisallowLatestTag) denied image nginx:latest: it is tagged latest or carries no tag.