The rule builder

Whole sets come from git. A single rule can be composed instead, from the CLI or the console:

cardinal policy rule list
cardinal policy rule add web-access -group engineers -to internal-apps
cardinal policy rule add application-access -group staff -app grafana
cardinal policy rule add ssh-login -group sre -to prod -account deploy,app
cardinal policy rule add run-as-root -group sre -to prod
cardinal policy rule remove <id>

Kind	What it grants
web-access	reaching a site through the proxy
application-access	signing in to an application
ssh-login	logging into machines, as named local accounts
run-as-root	becoming root on machines

-group says who it applies to, and omitting it means anyone. -anything targets every resource, which is deliberate and loud. -stage publishes without activating.

For ssh-login, the default local account is the person's own login, and root is never one of them: becoming root is run-as-root, which is a different rule with a different forbid in front of it.

What it produces

Text in the same document, published as an ordinary version, rolled back with policy activate like any other. Comments and anything the builder does not recognise pass through untouched, so a hand-written set does not degrade by being edited this way.

What it will not touch

The forbids and the administration tiers stay hand-written. They are the guardrails the other rules sit inside, so removing one goes through a policy file where the change is reviewed as text rather than as a button press.

In the console

The builder is on the Policy page. It names the group and resource, which must exist, and states in a sentence what the rule will mean before you press anything: "everyone in sre may become root on prod" is easier to check than the Cedar it becomes.