Product
|
Cloud costs
|
released
December 1, 2020
|
3
min read
|

Policy As Code

Updated

Automated governance is an important topic that we discuss as part of software delivery. And for many organizations, it can be the driving factor for investing in CI/CD platforms. However, not every deployment has to be risky. One practice is to introduce policy as code which allows users to codify policy decisions in software. This is beneficial because policy as code decouples decision logic from business logic in services. And we can even go as far as to make policy decisions based on an application or environment’s context. This blog post will share why we care about policy as code and how it can apply to software delivery.

Why Use Policy as Code?

Every business tests its products before releasing them to its consumers. Software services are no different, and every organization has its practices, tools, and processes that verify the health, readiness, performance, and accuracy of an application. These allow us to make guarantees to consumers and users of our product. This helps ensure that all changes are in compliance and adhere to a set of standards.

There are 2 ways to go about making a decision while testing a service. An individual or team can manually decide if a decision is correct or automate the decision-making process. One scales better than the other. Treating policy as code allows for automated decision-making, giving developers and engineers the independence to manage feature defining work without sacrificing compliance.

What Is Policy as Code?

Policy as code involves writing code in a high-level language to manage and automate policies. The high-level language is dependent on the policy engine, which takes a query input, some data, and policy to produce a query result. For a policy engine such as the open-source Open Policy Agent (OPA), the policies are expressed in a declarative language called Rego. Alternative policy engine solutions aside from OPA include Hashicorp’s Sentinel.

A Policy Engine returns a response given a query, policy, and some data.

Let’s describe the three inputs needed to make a decision.

  1. Policy: The policy represents the coded logic that models the decision-making process. 
  2. Data: The data is information from an application, environment, or service. This data is provided in a JSON format for OPA.
  3. Query Input: The query triggers the decision-making process based on the supplied data and policy provided uploaded to the policy engine. The policy engine service listens on a port for the JSON query made via an API call.

Here are links to resources to learn more about OPA and writing policies. 

  • Open Policy Agent Introduction @ CloudNativeCon EU 2018: video, slides
  • Rego Deep Dive @ CloudNativeCon EU 2018: video, slides
  • How Netflix Is Solving Authorization Across Their Cloud @ CloudNativeCon US 2017: video, slides.

Like any other piece of code it’s important to have the right processes in place to support development. OPA has a VSCode extension to support development within an IDE, alongside with a complete testing suite which allows you to unit test your policies. 

What Are Some Policy as Code Use Cases?

Some common use cases which policies include:

  1. Authorization Control for application services: Implementing fine grained access control for an application is one of the most common use cases for policy as code. To check authorization a service makes an API call to the policy engine to output whether the request is authorized or not. Here is some policy as code, which you can use to implement API Authorization in OPA.
  2. Infrastructure Provisioning within the cloud: Enforcing specific requirements on Public Cloud resources such as mandatory tags on instances, firewall and networking settings, and provisioned machine or instance types.
  3. For Kubernetes control: you can manage Kubernetes by writing policies against different Kubernetes resources like pods, namespaces, and nodes. You can ensure container images come from trusted registries. I recommend looking at OPA Gatekeeper (and we describe in another Harness blog post how to deploy Gatekeeper as part of your continuous delivery process).

Conclusion

Creating checks is a major part of the software delivery process. The earlier and faster we can catch errors or noncompliance, the better the software delivery process. This blog post shares some interesting use cases that policy as code can help automate. If you’re interested in trying policy as code, I recommend looking at Open Policy Agent.

Sign up now

Sign up for our free plan, start building and deploying with Harness, take your software delivery to the next level.

Get a demo

Sign up for a free 14 day trial and take your software development to the next level

Documentation

Learn intelligent software delivery at your own pace. Step-by-step tutorials, videos, and reference docs to help you deliver customer happiness.

Case studies

Learn intelligent software delivery at your own pace. Step-by-step tutorials, videos, and reference docs to help you deliver customer happiness.

We want to hear from you

Enjoyed reading this blog post or have questions or feedback?
Share your thoughts by creating a new topic in the Harness community forum.

Sign up for our monthly newsletter

Subscribe to our newsletter to receive the latest Harness content in your inbox every month.

Thank you! Your submission has been received!
Oops! Something went wrong while submitting the form.
Continuous Delivery & GitOps