What is Policy as Code?

TL;DR

⁠Policy as code is a concept that refers to the practice of defining and managing policies using code. This allows policies to be managed and enforced using the same tools and processes that are used for managing and deploying software.

The Benefits of Policy as Code

There are many benefits to having policy as code, including improved consistency, accuracy, and traceability.

Defining policies using code provides organizations with the ability to ensure policies are consistently enforced across different systems and environments, which can help prevent policy violations and reduce the risk of unauthorized access to sensitive data or systems.

Policy as code allows them to be more easily managed and updated. When managed as code, policies can be managed using the same tools and processes used to manage and deploy software. This makes it easier to track changes to policies over time, roll back changes if necessary, and in general, enjoy the well-thought-through best practices of the code world (e.g., GitOps).

Now that we have gone over the benefits of having policy as code let’s talk about what this would look like in practice!

Examples of Policy as Code

One example of a policy as code implementation is Rego - the language used by Open Policy Agent (OPA). Rego is a high-level declarative language that is designed specifically for defining and managing policies. It is a Prolog / Datalog derivative language, and it allows policies to be defined using simple sets of rules, which can be handled recursively by the OPA engine.

Here is a super simple example of a policy written in Rego:

package example

import input

default allow = false

allow {
  input.user.role == "admin"
  input.resource.category == "sensitive"
}

In this example, the policy specifies that a user is only allowed to access a resource if they have the "admin" role and the resource is in the "sensitive" category. The policy is defined using simple, declarative statements, and it can be easily understood and modified by anyone familiar with the language.

That being said, Rego isn’t your run-of-the-mill programming language like Python or Java and can have somewhat of a steep learning curve. To learn more, check out these articles about implementing RBAC with OPA and Implementing ABAC with OPA. 

OPA’s Rego is just one example of a policy-as-code language. Many other such languages exist (Such as Google Zanzibar Schemas, Cedar, OSO, and many more), with each of them having its own supporting tools. At the end of the day, picking the correct language and tools will depend on the specific needs and requirements of what you’re building. 
-- ⁠Want to learn more about the differences between Rego and Cedar - check out this article.

Policy as low/no code 

While policy-as-code should be managed in a code repository, that doesn’t mean it should be authored as pure code. By simplifying policy creation, we can make our work as developers easier, free ourselves  from becoming bottlenecks, and empower other critical stakeholders (e.g., product managers, security, compliance, support, professional services, and sales) to participate in the policy creation process.

The way to achieve this is through using solutions that provide low-code interfaces that generate policy code right into a Git repository (Like Permit.io 😉). This allows developers to test, benchmark, and even code review the generated code - all while maintaining the ability to add more code on their own for the more advanced cases.

Using low-code policy interfaces also reduces dependence on a single policy engine and allows for embracing a more polyglot dynamic approach to software (as you would anyway - it's all about using the right tool for the right job).

Permit.io’s no-code UI, which generates RABC and ABAC policies as code. 

Want to learn more about authorization best practices? Join our Slack community, where there are hundreds of devs building and discussing authorization.