Documentation / Policies / Operate

Operate Policies

Evaluate, attach, version, and audit Policies without silently changing the authority of accepted Runs.

Before you begin

Obtain policy:evaluate for the target namespace and the management authority required for any Resource you will change. Record the current Policy CRN and hash. Prepare both positive and negative test inputs, including the exact principal/customer context used in production.

Steps

  1. Open Policies and inspect the Policy identity, version, executable artifact, deployment revision, status, and most recent publication.
  2. Test a decision before attachment:
sh
curl https://platform.constal.ai/v1/namespaces/default/policies/ticket-read-boundary/evaluate \
  -H "Authorization: Bearer $CONSTAL_API_KEY" \
  -H "Content-Type: application/json" \
  --data '{
    "action":"resource:invoke",
    "resource":"crn:constal:production:acme:default:service/tickets",
    "context":{"resource.operation":"ticket.read"}
  }'
  1. Review the manifest target selector and the exact targets materialized from it. A Policy targets one managed Resource or platform-address kind; use matchLabels or matchExpressions for a set and protected constal.ai/crn for one exact target. Selector membership is confined to the Policy's environment, tenant, and namespace. Reserved platform/default catalog Resources are the deliberate exception because tenant workloads invoke those shared, immutable platform capabilities.
  2. Start a controlled Run and inspect the accepted Policy hash and per-invocation evaluations.
  3. Publish a new Policy version through the deployment API. Registry promotion materializes selector edges before the version becomes available for new admission. Do not assume existing Runs adopt it: they retain their accepted Policy snapshot unless an authenticated safe-point Policy control explicitly changes it.
  4. Roll back by promoting a known immutable package revision, then repeat the negative tests.

Verify

Confirm denied operations stop before external dispatch and allowed operations contain the expected constraints. Verify explicit deny overrides an allow from another layer. For an existing Run, compare current Resource Policy with the pinned Run Policy and ensure any difference is intentional.

Next steps

Use Run operations for safe-point Policy changes, Use Resources from Agents for Resource bindings, and Analytics queries and exports for historical decision evidence.