PoliciesAdministrators

How policies reach clusters

The objects a policy becomes in each cluster, how to check whether it is in force, and how the platform retries clusters it could not reach.

Tenants write policies through the Policies module, module-policies in stackship-system, which keeps them in its own database. The three admission rules — Required labels, Allowed registries and Disallow the latest tag — are then carried into each cluster the policy applies to. Allowed compute plans never leaves the control plane: the modules that create resources ask the Policies module about it.

The objects in a cluster

For each cluster in the policy's scope, the module writes a cluster-scoped Policy resource (policies.platform.stackship.se) named policy-<policy id>, labelled platform.stackship.se/boundary=<boundary id>. It writes it as the platform, not as the person who saved the policy.

The operator in that cluster turns the resource into:

a ValidatingAdmissionPolicy named stackship-<policy id>, holding the rule, with failure policy Fail: an expression that cannot be evaluated refuses the object;
while the policy is enabled, a ValidatingAdmissionPolicyBinding of the same name with action Deny, which selects the namespaces labelled platform.stackship.se/boundary=<boundary id>.

Disabling a policy deletes the binding and leaves the admission policy, which then evaluates nothing. Deleting the Policy resource makes the operator delete both.

Check a policy in a cluster

The resource's status says what the operator made of it:

bash

kubectl get policies.platform.stackship.se policy-<policy-id> -o jsonpath='{.status.phase}'

Phase	Meaning
`Enforcing`	Admission policy and binding are installed
`Inert`	Installed but not bound — the policy is disabled
`Unsupported`	The cluster does not serve `ValidatingAdmissionPolicy`, which needs Kubernetes 1.30 or later. Nothing is enforced; the operator checks again every hour
`Error`	The resource could not be turned into an admission policy, or applying it failed; the `Ready` condition's message says why

The portal shows none of this: a policy on an Unsupported cluster looks the same as one that enforces. Tenants learn a policy's cluster state only from you.

Retries

A save writes to every cluster at once; a cluster that refuses or cannot be reached is recorded, and the save still succeeds. Every five minutes the module re-applies every policy to every cluster its boundary spans, so such a cluster catches up. Only one replica runs such a pass at a time.

The pass only adds and updates; it never removes. A policy leaves a cluster only when someone narrows its scope or deletes it. So when a boundary stops spanning a cluster, its policies stay installed there until each is saved again or deleted. A delete is refused, and the policy kept, until every cluster it is installed in has removed it.

Setting	Default	Meaning
`Policies__ConvergeIntervalMinutes`	`5`	Minutes between re-apply passes
`Policies__ConvergeOnce`	`false`	Run one pass and stop re-applying

Both are environment variables of the module-policies deployment; the installer does not offer them.

Kyverno

Installing the Policies module also installs Kyverno 3.4.5, which the platform uses for guards of its own. Tenant policies are not Kyverno policies; they are the Kubernetes admission objects above.