DevOps and DevSecOps have offered an innovative approach to delivering software that focuses on continuous integration, continuous delivery, and building a bridge between engineering and operations teams in order to ship software faster and with less risk.
It's been adopted by banks, insurance companies, governments, and several organizations in highly regulated industries. But here is the thing, it's moved on a lot since its beginnings and doesn't offer a competitive advantage on its own anymore.
For this reason, it’s necessary to take the next step and implement policy as code as an extension to DevOps. This is simply because, the quicker you can catch errors and non-compliance, the better and the faster the software delivery process will be. And in a competitive market, your success, to a considerable extent, depends on how quickly you can deliver quality software.
In this post we'll look at what policy as code is and why you should use it.
What Is Policy As Code?
A policy is a set of rules that governs the behavior of a specific software service. These policies could, for example, describe rate-limits, names of trusted servers, the clusters where an application should be deployed too, permitted network routes, or even accounts a user can withdraw money from.
So, writing policy as code simply involves writing code in a high level language to manage and automate these policies. This makes it easier for developers and engineers to manage feature-defining work without sacrificing any compliance.
When writing policy as code, the high-level language depends on the policy engine used. This policy engine takes a query input, data, and policy to produce a query result. For example, for a policy engine like the open-source Open Policy Agent (OPA), the code will be written in a declarative language called Rego. Using it, developers can write policy as code that promotes safe, performant, and fine-grained controls.
Other policy engine solutions include HashiCorp’s Sentinel, and Pulumi’s CrossGuard amongst others. In these, the high-level language used is Sentinel Language and JavaScript or Python respectively.
What Are the Benefits of Using Policy As Code?
One of the main benefits of using policy as code is that it decouples decision logic from business logic in services. This, ultimately, means that policies can be updated at any time without recompiling or redeploying, and they can be automatically enforced.
This helps organizations to build software at scale, making them adaptable to changing business requirements, improving the ability to discover violations and conflicts, and increases the consistency of policy compliance. In simple terms, it mitigates the risk of human error.
Now, with that in mind, let's look at some of the benefits of using policy as code in more detail.
Less Costs
One way to control costs is by setting policies based on pricing. When you have pricing data online, you can calculate the cost of using a resource ahead of the time and create a policy that limits the cost to deploy it.
You're also able to implement a policy that stops unused resources when they're not used. This means that, if the resource isn't running, it can't cost you money. This prevents that surprising monthly cloud bill that sneaks up on you at the worst of times.
Better Compliance
You can use policy as code as a way to enforce infrastructure policies and prevent inadvertent or unauthorized access to resources like databases and storage. In fact, controlling access to these resources is a best practice.
By using policy as code, you can mitigate the likelihood of unauthorized access to these resources, data breaches or even cyber security threats, irrespective of whether it's a development environment, a testing environment, or a production environment. In other words, with policy as code, you can enforce this best practice across an entire organization.
Validating Before or During Deployment
One of the shortcomings of using a cloud provider’s interface to create policies, is that these policies can only be tested on deployed resources. With policy as code, this isn't a problem. For example, Pulumi’s deployment engine constructs a preview of the resource and also tests if resources are compliant with the included policies.
The policies are run before the resources are registered and its inputs are validated. Likewise, out of compliance resources are blocked from being created or modified. Also, for example, a service like Fugue also allows you to validate your infrastructure-as-code against enterprise policies and out-of-the-box compliance standards before deployment. In this way you get instant feedback on policy violations.
You could also use policy as code to validate a resource during deployment when necessary, for example, where one resource is required to provision another resource. Here, you can run policies against a stack as a whole or selected resources and when all resources are registered it will not prevent resources that are out of compliance from being created.
Either way, you save both time and money.
Best Practices as Policies
All cloud providers provide a set of best practices for deploying resources. You can implement these best practices as policies, as we've described above when we mentioned unauthorized access. You can thus use policy as code that determine how resources like storage and databases are used.
Not only does this enable you to deploy best practices as policies, but it also gives you repeatable and fine-grained control over the resources you deploy.
Sandboxing
Policies provide the proverbial guardrails for other automated systems. These automated systems should be protected from performing dangerous actions. Now, this may seem simple if there's not too many automated systems.
However, as the number of automated systems grow, to protect them against performing dangerous actions becomes complicated. Manual verification is too slow, so when policies are represented as code, it's easier to keep up with all automated systems.
Final Thoughts
Hopefully, this post was helpful to illustrate what policy as code is and, more importantly, why you should consider using it.
Simply put, it saves you costs, improves your compliance, and keeps you using best practices in your development efforts.