Skip to main content

Policy Lifecycle

The verdictan policy command group manages two different document families:

Document familyPurposeCommands
Runtime gateway configProvider routing, request policies, runtime behavior, and tests in policy-config.yamllint, test, push, deploy
IAM policy documentControl-plane allow/deny statements for actions and resource VDTslint, diff, apply, evaluate, export

Do not apply an IAM policy bundle as a gateway configuration. Do not deploy a gateway policy-config.yaml as an IAM policy. verdictan policy lint --mode auto detects the family, but the mutation commands are different.

Runtime gateway workflow​

1. Validate and test locally​

verdictan config validate --file policy-config.yaml
verdictan policy lint --mode runtime --file policy-config.yaml
verdictan policy test --pack-dir .
verdictan gateway check --config policy-config.yaml

Before a remote rollout, run a local, agent-bound gateway. Send a representative request:

verdictan gateway run \
  --agent policy-review \
  --policy-config policy-config.yaml \
  --listen 127.0.0.1:41002

2. Publish a version for one gateway​

verdictan policy push \
  --file policy-config.yaml \
  --gateway-id gw_source \
  --change-detail "Enable reviewed DLP chain"

push creates a configuration version for the source gateway and makes that version active. It does not roll the version out to other gateways.

3. Roll out to target gateways​

verdictan policy deploy \
  --file policy-config.yaml \
  --source-gateway-id gw_source \
  --target-gateway-id gw_canary_1 \
  --target-gateway-id gw_canary_2 \
  --change-detail "Canary rollout"

In text mode, the command creates the rollout and then polls for application on each target. The default timeout is 60 seconds and the default polling interval is 1,000 ms. If the deployment environment warrants different values, use --timeout-secs and --poll-interval-ms.

With --json, the command prints the rollout-creation response and returns without polling. That response shows an accepted rollout. It does not prove application. Before automation marks the deployment complete, query the target gateways. Verify that each gateway reports the returned source version.

Use a canary target first. After application, verify the active configuration version and a representative governed request on the target. If an upload succeeds, that result alone is not runtime verification.

IAM policy workflow​

An IAM policy file can hold one policy or a bundle. Each policy contains statements with an allow or deny effect, action patterns, resource VDT patterns, and optional conditions.

1. Export a reviewable baseline​

Export all remote IAM policies:

verdictan policy export --file iam-policies.yaml

Select policies by repeatable ID or name flags:

verdictan policy export \
  --file evidence-policies.yaml \
  --name "Evidence Reader" \
  --format yaml

If you do not supply selectors, the command exports all policies. --format accepts yaml or json. If you do not supply it, the destination extension sets the format.

2. Lint and diff​

verdictan policy lint --mode abac --file iam-policies.yaml
verdictan policy diff --file iam-policies.yaml

diff fetches remote policies and calculates a dry-run reconcile plan. It does not mutate the organization.

By default, the command does not change a policy when the local file does not contain it. If the local file contains all specified state, add --prune:

verdictan policy diff --file iam-policies.yaml --prune

Before you continue, review each proposed deletion.

3. Evaluate a decision​

Evaluate local statements without applying them:

verdictan policy evaluate \
  --file iam-policies.yaml \
  --action events:read \
  --resource-vrn 'vdt:verdictan:events:eu:org_example:events'

Or select one or more configured remote policies:

verdictan policy evaluate \
  --name "Evidence Reader" \
  --action events:read \
  --resource-vrn 'vdt:verdictan:events:eu:org_example:events' \
  --json

Select one input mode. Use --file, or use one or more repeatable --policy-id/--name selectors. Optional --caller-attrs, --resource-attrs, and --request-attrs values must be correct JSON. Use objects that match the simulator's attribute schema.

Evaluation calls the control-plane simulator. It helps you review policy logic. It does not prove caller authentication, role assignments, or production resource context.

4. Apply reviewed changes​

verdictan policy apply --file iam-policies.yaml

The command prints the plan and prompts before changes. In automation, use --yes only after storing and reviewing the JSON diff:

verdictan policy diff --file iam-policies.yaml --json > reviewed-plan.json
verdictan policy apply --file iam-policies.yaml --yes --json

In --json mode, apply output is noninteractive without --yes. Include --yes to show the approved mutation intent in reviewed automation. Do not use JSON mode as a dry run.

JSON apply mode can return process exit code zero after individual operations fail. Automation must verify that applied == true and that the failed array is empty. It must also verify the exit status.

--prune authorizes removal of remote policies missing from the document. Pair it with a reviewed diff --prune. Do not add it only to make remote state match unexpectedly.

Safety checklist​

  • Keep runtime config and IAM policy documents in different descriptive paths.
  • Use stable policy names and statement identifiers so reviews are easy to read.
  • Apply minimum privilege.
  • Test specified allows and specified denies.
  • deny precedence and wildcard resources are high-impact changes.
  • If a recovery record is necessary, export before destructive reconciliation.
  • Use --json.
  • Examine command-specific result fields.
  • Examine the exit status. It does not show each operation failure.
  • Preserve the Trail event and change detail for production rollouts.

Next steps​