By the time you’ve worked in the IT industry for a couple of years, you are usually familiar with many practices as code, for example, infrastructure as code, configuration as code, and security as code. You may have even met with the expression policy as code. What does it mean? Why should we follow an ‘as code’ approach? You’ll find all the answers in this article.
What is policy as code?
The main idea behind policy as code is using specific language to manage and automate policies. What language can be used for that target? In the next section, you’ll find examples of tools and frameworks.
Policy definition
In a broad IT context, a policy is a set of rules, conditions, guidelines, or instructions for IT processes, resources, and operations. In a more narrow context, e.g. related to firewalls, a policy defines how to handle traffic for specific IP addresses, protocols, applications, etc. Of course, we can think of other contexts where policy has a different meaning, but this article is focused on these two: - general and related to firewalls.
Check out the article when we focus on OPA (Open Policy Agent) and the Rego language.
Benefits of using an "as code" approach
Consistency
Treating much of our work ‘as code’ lets us make it consistent, e.g. when we use standards (like Terraform) for managing our infrastructure.
Version Control
Every code can be version controlled, so it's easy to determine changes or revert to an earlier configuration version.
Code audit
Code files can be audited easily. In case of any change or need to scale resources, it can be quickly achieved by changing some part of the code.
Portability
A similar case is portability, e.g. exporting settings from one environment and applying them to another can be painless.
At this moment the benefits of using an as code approach are clear, but what exactly is policy?
Curious about how to effectively automate network? Discover more information here.
Moreover, we also encourage you to watch the panel discussion, where industry experts share their thoughts and insights on the network automation journey:
Tools for policy as code
Policy as code tools are applications that ensure security and compliance with standards in the organization. Below you will find the tools for policy as code divided by specific purpose — IT organizational policy and managing firewall policy.
IT organizational policy
OPA
Open Policy Agent (OPA) is a general-purpose policy engine and it decouples policy decision-making from policy enforcement. OPA policies are expressed in Rego 
, which is a declarative language. Policy evaluation can be integrated into pipelines or Terraform Cloud on the team and governance tiers. In the below diagram is presented a typical flow deploying infrastructure as code with the use of policy as code.
Sentinel
Sentinel is the second solution for defining policies. Both OPA and Sentinel in most cases can be used interchangeably. The main difference between OPA and Sentinel is the language used - appropriately, Rego and Sentinel.
Sentinel is a policy as code framework from HashiCorp Enterprise Products, so testing it locally without Terraform Cloud is not as easy a task, mainly because of the need to generate mock data from the Terraform plan.
Checkov
Checkov is the next tool for policy as code. It scans cloud infrastructure to find misconfigurations. It contains out of the box a lot of infrastructure code frameworks like Terraform, Kubernetes, GitLab or GitHub actions.
Managing firewall policies
The introduction presented two contexts for describing policy as code. Alongside IT organizational policy, managing firewall configuration is the second context in which the term policy as a code is used, mainly connected with security policies. Using an infrastructure as code tool (like Terraform) or configuration as code tool (like Ansible), we can automate the process of managing firewalls and use all the benefits of the as code approach.
If you want to apply network solutions in your organization, check out how CodiLime can help you accelerate your business growth.
Terraform providers
If network infrastructure is being deployed from the code, then we can use the same HCL language, but with additional Terraform providers, for deploying network devices and configuring them. From the pipeline perspective, that solution is straightforward - as in the diagram below.
More details can be found in the documentation for sample Terraform provider e.g:
- Aviatrix firewall policy
- Cisco ASA access rules
- FortiGate firewall policy
- F5 - BIG-IP WAF policies
- Palo Alto Networks security policy
Ansible modules
Terraform is a great tool for managing infrastructure, though not always for configuring devices (mainly because of the need for managing state). In some approaches, Ansible (or another configuration as code tool like Puppet or Chef) seems to be more adequate. In the case of Ansible, code for policies is defined in the YAML language and Ansible modules are used to configure them on network devices.
More details can be found in the documentation for each Ansible module, e.g.
Summary
The two contexts regarding "policy as code" presented in this article show the possibilities and scope of use. In the case of IT organizations, we can gain great benefit from the implementation of OPA or Sentinel when we add it to automatic processes such as CI/CD pipelines. In the context of network devices, especially firewalls, instead of manually configuring the policies, a huge profit in terms of time and avoiding mistakes is gained when we treat firewall policies as code, and when we use the solutions already existing on the market, like Terraform providers or Ansible modules.
