Globals

What Globals do in policy evaluation

Globals are runtime values exposed to policy logic so decisions can adapt to deployment context without hardcoding environment-specific data into the policy itself. In Cerbos-style policy evaluation, that makes globals a clean way to keep policy rules portable while still letting them respond to tenant, region, or environment differences.

That separation matters because policy authors can express the decision once, while operators supply the context that changes across environments. Used well, globals reduce brittle policy duplication and make the policy layer easier to deploy consistently across development, staging, and production.

How globals shape access decisions

Globals are part of the evaluation context, so they influence the outcome of a policy only when the policy explicitly reads them. They are not a separate authorization system; they are inputs that help the policy decide whether a request should be allowed or denied under the current deployment conditions.

This makes globals useful for rules that depend on operational context, such as environment flags, regional constraints, or deployment-specific configuration. The policy remains the source of decision logic, while the runtime supplies the values that make that logic context-aware.

For teams using contextual policy inputs alongside broader access-control controls, the important design principle is to keep environment data observable and deliberate. A policy that depends on globals should be easy to reason about, because hidden or poorly documented runtime values can make access decisions difficult to explain or audit.

Why globals are useful for policy portability

Globals help separate policy intent from deployment detail. Instead of baking environment constants into multiple policy files, teams can centralise those values and let the same policy evaluate differently across installations. That supports reuse, consistency, and easier maintenance as infrastructure changes.

This is especially valuable when the same policy logic must run in multiple environments with different operational settings. The policy stays stable, while the runtime supplies the values that distinguish one deployment from another.

That portability only works when the meaning of each global is clearly defined. If a value is ambiguous, reused for unrelated purposes, or changed without coordination, the policy can still be syntactically correct but semantically misleading.

Common implementation mistakes

A frequent mistake is treating globals as a convenient dumping ground for configuration that really belongs elsewhere. When too many decision inputs are packed into runtime values, policies become harder to test, harder to review, and easier to misconfigure.

Another common problem is assuming that a value available at runtime is automatically trustworthy. Globals can be operationally useful, but the decision logic still depends on the integrity of the data supplied to the policy engine. If those values are wrong, stale, or inconsistent across environments, the resulting access decision may also be wrong.

For a good practical reference on policy-adjacent access-control concepts and implementation patterns, NIST SP 800-53 Rev 5 Security and Privacy Controls remains useful for framing access-control and configuration-management expectations, while OWASP Cheat Sheet Series provides practical guidance around secure policy-adjacent implementation concerns.

Risk and Threat Considerations

Globals can create security exposure when they influence policy outcomes but are not governed as carefully as the policies themselves. If environment-specific values are misconfigured, tampered with, or inconsistently applied, the policy may grant access in contexts where it should not, or deny access where it should be allowed.

Failure mechanism: the policy engine evaluates correct logic against incorrect, stale, or unauthorised runtime values, causing access-control drift. Because the decision appears to come from policy, the underlying configuration error can be difficult to spot until users or attackers encounter unexpected access behaviour.

Impact: compromised or unreliable globals can lead to over-permissive access, failed segregation between environments, or brittle decisions that break during deployment changes. In the worst case, an attacker who can influence runtime inputs may be able to steer policy outcomes without changing the policy file itself.

Practitioner Guidance

Governance implication: treat globals as policy inputs with ownership, versioning, and review discipline. The policy author should understand which values are expected, who supplies them, and how changes are promoted across environments so that runtime context does not become an invisible control dependency.

What to watch for: unexpected decision changes after configuration updates, environment drift between clusters or tenants, and globals whose meaning is unclear to reviewers. If a global materially affects access, document it as part of the policy design so that testing and audits can verify the intended behaviour.

Practitioner takeaway: the safest globals are the ones that are few, explicit, and stable enough to explain in the same sentence as the policy rule they influence.

Related resources from NHI Mgmt Group

• What is the difference between using globals and using separate policy versions for environment-specific authorization rules?