5 Myths about Policy-as-Code
There are a number of misconceptions about Policy-as-Code. Here are the ones that we’ve run into most frequently:
Its only purpose is to lock down Infrastructure-as-Code deployments
It’s a slow and fragile, so it can’t be used for anything important
It’s a security risk
The policy language(s) are difficult to use
No one is using Policy-as-Code for anything important
Locking down IaC
Definitely not true. IaC compliance management is certainly one of the first uses of policy-as-code (and probably how it got the name), but it has progressed well beyond that. AWS Cedar, for example, is exclusively focused on Policy-Based Access Control (PBAC, as compared to Role-Based Access Control, or RBAC). And the Open Policy Agent is a general-purpose rules system, capable of compliance management, PBAC, business rules, or properly implementing a complex tangle of regulatory restrictions.
Slow and Fragile
One of the challenges with licensed products is the cost-per-use. This is often structured in such a way that deploying to the edge is non-viable financially. Luckily, some of the prominent Policy-as-Code products (Open Policy Agent, and the Permit.io suite of agents) are open source, and can be easily deployed everywhere with minimal incremental cost (i.e. configuration and labor).
Because these can be deployed at the edge, or as sidecars in Kubernetes solutions, the agents can easily integrate into existing health monitoring, which significantly reduces their fragility.
Security Risk
OPA and the Permit products can be locked down with server-side certificates and other restrictions. It then becomes virtually impossible to subvert or eavesdrop on these agents without access to the private keys. This implementation is straightforward, follows standard practices, and easily replicated in a structured way.
Difficult Language
AWS Cedar is fairly straightforward because of its particular focus. Generally, the accusations of difficulty is a criticism of Rego. As a declarative logical programming language, Rego is definitely a different kind of language. And because developers aren’t used to thinking in a “declarative logic” way, they often write programs in Rego that are awkward and hard to follow. And then, as people gain familiarity with Rego, they often write their policies using every possible feature of Rego.
Neither of those two strategies result in policies that are easy to follow. And for certain, if a language drives developers into bad programming models, that is at least partially the fault of the language.
On the other hand, as programmers gain familiarity and comfort with “Thinking in Rego”, it is straightforward to write policies that are readable and functions that are reusable. The language is not difficult to use. Admittedly, it is fairly difficult to learn without context, which is something that can be mitigated with training and practice. In addition, Styra has a free online academy for learning how to write Rego. There is also a support system in place on the Open Policy Agent slack channel(s).
No Critical Uses
IMO, this is probably the biggest myth, because over the last year, it is quite clear that Rego is being used to solve some very interesting problems. For example:
Compliance and Compliance Audits
Companies are using Policy-as-Code to enforce compliance (SOC2, HIPAA, etc) within various elements of their infrastructure (not just IaC, but also services & APIs that provide data (such as patient medical data or financial data)
In addition, the policy decisions can be logged in a consistent, centralized way, which can save a lot of time during audits
Zero Trust
For Zero Trust architectures, PaC is used to lock down services, APIs and legacy applications. The benefit here is the ability to surgically add the policy analysis without changing the rest of the logic, which reduces complexity, risk and time to market
Policy-Based Access Control
One of the challenges with RBAC is ‘role explosion’, which can occur as the number of roles and capabilities continuously grows as different groups within an organization require subtly different capabilities and access from each other. PBAC can be used to mitigate this by grounding the capabilities in logic based around the entity making the request, rather than role assignments.
Policy Disintermediation
Even in situations where compliance isn’t a primary concern, there are opportunities to use Policy-as-Code to change the way you build code. In many enterprise environments, the “business rules” that the developers are implementing are often “corporate policy”. Because up until recently there was no option for extracting the policy from the functional logic, the same developers would build both the functionality (such as collecting and manipulating data) and the policy (encrypting or obfuscating certain columns, validating access to specific rows, etc). If you look at your business rules and discover a lot of implicit corporate policy, you might have some opportunities to pull that policy out of the functional logic, which makes it easier to change those policies without having to rewrite, rebuild and redeploy the software.
So there you have it - some myths about Policy-as-Code, and some examples that challenge those myths. If you have thoughts about this, different opinions, concerns we haven’t addressed, or other examples of myths that we should address, we would love to hear from you at: info@paclabs.net