Keep policies in git
Write decisions as policy files, decide in process and explain every decision.
Status Status is where the work is: Planned (in a milestone, not started), Building (tickets in progress), Preview (usable, may change), then the stability it ships at.
Stability The promise an interface ships with.
- Stable Follows semantic versioning; breaking changes need a new major, 12 months of overlap and a codemod.
- Beta Usable in production; may change before it becomes stable.
- Experimental May change or go away; needs an explicit opt-in in main.yaml.
You will put policy files in your repository, decide a request in process and explain the result. It takes about 15 minutes.
You need
- The
accessinterface set up (see Protect a route with permissions).
1. Choose the engine
policy:
engine: cedar
dir: policies/
mode: observeStart in observe: decisions are logged but not enforced. Move to enforce when the log looks right.
2. Decide and explain
import { policy } from "mainsdk";
export function canUpdate(user: string, order: { id: string }) {
const d = policy.decide({
subject: { type: "user", id: user, roles: ["member"] },
action: { name: "orders.update" },
resource: { type: "order", id: order.id },
});
return { allowed: d.allow, why: policy.explain(d.id) };
}3. Review changes in a pull request
Policy files are plain text in git, so a change to who may do what is a reviewed diff with history.
Check it worked
policy.explain() names the policy and rule behind a decision, and the audit log holds the policy version.
Next
Was this page helpful?