Policy as code

Policy as code expresses requirements as rules that software can evaluate. Teams can version, review, test, and deploy those rules. Examples include authorization rules, infrastructure constraints, and configuration checks.

The practice is broader than storing a policy file in Git. The change process also needs to track which policy implements the requirement and which system applies it. Open Policy Agent's testing documentation illustrates how policy behavior can be checked against explicit expected outcomes.

Explore Dome: Authorization · Docs: Author rules.

Connect the requirement to the policy change

Suppose a platform team restricts production deployment tools to an approved release agent. Name the agent and the deployment operation in the requirement. Then write the policy using inputs the system supports and can trust.

A useful change record contains the requirement, owner, candidate version, test cases, deployment scope, and rollback version. Reviewers can check whether the policy expresses the intended restriction and will be applied by the services handling those requests.

If the new policy expects an agent attribute the application doesn't yet send, deployment order matters. Track the required application and policy versions together, and verify that the services evaluating requests have both changes.

Explore Dome: Authorization · Docs: Author rules.

Decide what happens when rules conflict

Policy inheritance lets rules set for a larger group, such as an organization, also apply to its teams or workloads. Policy conflict resolution determines the result when applicable rules disagree. Policies may be assembled from organization, team, application, and workload scopes. “More specific wins” is one possible design, not a universal property of policy as code.

For the release agent, a local permission might coexist with an organization restriction on production changes. Whether the request is allowed depends on how the system combines those rules. Review the complete policy set rather than a single file in isolation.

In Dome, active rules are combined across scopes and a matching forbid takes precedence over a permit. A local permit for the release agent therefore cannot override a matching organization-level forbid. Other policy engines may resolve conflicts differently.

When reviewing inheritance, record which version of each contributing policy was evaluated. A local file diff alone may not explain why an operation changed from allowed to denied.

Explore Dome: Authorization · Docs: Authorization model.

Make policy changes easy to review and roll back

For a change to the release agent's permissions:

1. State the access change and the reason for it.
2. Review the proposed policy and where its inputs come from.
3. Run expected-result tests and relevant historical comparisons.
4. Deploy to the intended services or workloads, with a known version ready to restore.
5. Check the resulting decisions after the new policy has reached the services that use it.

A valid policy file may still grant the wrong access. Test expected allow and deny cases, compare historical decisions, and verify the deployed path. Policy testing versus simulation explains what each check covers.

Dome provides workflows for authoring, validating, simulating, and applying rules. Its audit and version information can support review of governed decisions. The larger practice still requires a team to own the requirement and approve the change.

A reviewer should be able to connect the business restriction to the policy version that was applied. An operator should know how to reverse an unintended change.

Explore Dome: Authorization · Docs: Simulate rules.