Define, update, share, and enforce policies using code

In all companies, especially those adopting the hybrid cloud model, automation adoption, such as infrastructure as code (IaC), offers decreased costs, increased productivity, and shortened time to market. Another benefit is better security. Automation leads to faster operations because tasks that were manually done are now handled by code. It has also highlighted areas that need to be addressed -- specifically, compliance, governance, and standards that aren’t addressed by default when using automation. Repeatability and speed don’t ensure that things are being done correctly, and repeatability is not helpful if the same mistakes are made over and over. If this is your challenge or you wish to learn more about this, this article will interest you.

We will discuss a new model called policy as code, from IBM and Red Hat. At a high level, it is an approach to policy management in which policies are defined, updated, shared, and enforced using code. The keyword here is code, which means that your policies are codified utilizing a programming language. These codified policies can help enforce or test automation scripts to ensure that they follow the defined and codified policies.

You would generally encounter this as a part of more extensive platform software, especially security and IaC software that enforces the actions taken to meet the defined policy. For example, checking to ensure that none of the computing resources have a direct route to the Internet (violating a security policy) or limiting the possible exposable services to just HTTPS and SSH. In general, for this to work, you need a policy engine. The policy engine stores the policies and uses them to ensure that the resource creation will comply with the codified policies. Most offerings allow for deny, warn, or report based on compliance with business requirements of the specific attribute. This is a simple use case, but there can be variations and more complex policies requiring a greater compliance need in frequency and scale. Policy as code provides a simple way to align the IT infrastructure with a company’s policies and standards.

This is not a new concept, and a few companies have systems and platforms that help implement policy as code. One of the standard tools is Sentinel from HashiCorp. One might wonder then: What are we doing that is new? If you do a Google search for policy as code, you will not find Ansible anywhere in that search. We are building a policy as code offering that is built with the Red Hat Ansible Automation Platform as the foundation and an open source policy engine called Open Policy Agent. Most offerings available today apply to particular use cases and were designed to work only in specific environments/technologies. IBM and Red Hat offerings will apply to multiple use cases and work with most environments/technologies. For example, Sentinel works with Terraform only, and the code must be uploaded to the Terraform cloud. This is a major limitation. The IBM and Red Hat solution will avoid most of these limitations since Ansible Automation Platform works with most technology platforms (Terraform, Azure Resource Manager templates, Ansible Playbooks, other IaC tools, and public clouds). We shall dive a little deeper into Ansible Automation Platform and Open Policy Agent a little later in this article, but won’t be comparing this to other offerings available in the market.

What is policy as code?

Policy as code is an approach to policy management in which policies are defined, updated, shared, and enforced using code. A policy is a rule, condition, or instruction governing operations or processes. Another way to think about policy as code is that it automates the compliance process, where the business logic is translated from a spoken language into machine language (codified). It also helps decouple policy from the business logic of an application. This approach has several advantages, including:

• Software development best practices can be adopted
• Automated testing of the policy-enabling scale
• Enforcement of style guides and security rules
• Traceability for compliance
• Centralized control and management of rules
• Codified policies
• Can be version-controlled
• Consistent, recursive, and cost-effective

The following diagram shows a standard process for a policy as code solution.

What is a policy?

A policy is a rule, condition, or instruction governing operations or processes. Another definition of policy is a set of rules or guidelines for an organization, people, or process to follow to achieve compliance, standards, or consistency.

There are two types of policies:

• Static policies -- Evaluated before execution, to test whether a device/resource name adheres to a naming convention before provisioning the device/resource, for example
• Dynamic policies -- Evaluated and enforced during runtime, if user data is not created, moved, or saved from a defined geographic zone at runtime, for example

Challenges to the traditional policy enforcement process

The challenge with conventional policy enforcement is that it is manual or semi-automated and does not scale well. Each development or application team embeds some policy enforcement code within their applications. This is not easily trackable or auditable because every team implements it as it sees fit due to a lack of framework definition.

Each organization will have its practices and processes while developing and delivering software. Based on their business, they may have to comply with industry-recognized frameworks such as SOC 2, CIS, PCI DSS, ISO 27001, etc. These policies are either part of the business logic code or enforced manually. This results in the same policies being written in different languages, in other code repositories, and managed by different teams. This can also result in different groups interpreting the same policy differently. Also, if you want to change one rule or create a new policy version, it may take weeks or months to implement and test it. This makes it very cumbersome to enforce.

The other issue is that organizations define and enforce policy manually. A compliance team will compose business requirements with specific rules that everyone is expected to follow. There are several challenges with this traditional approach:

• Policy documents are continuously updated while development teams are developing against them.
• Policy documents do not specify a framework for how those policies need to be implemented.
• Testing is after the fact and manual.
• It is not a scalable process.
• It is dependent on human interpretation to enforce the policies uniquely.
• Any changes required could require a significant change after the fact, so it is painful and wasteful.
• Changes in policies done manually could have unintended consequences.
• The lack of the framework makes it difficult to audit changes.

Why policy as code?

Policy as code addresses the weakness of the traditional enforcement method. It automates defining and enforcing the policies via a specific technology platform. There are multiple advantages of using policy as code:

• Simplifies the creation of test cases (the policy)
• Automates the checking/enforcement of the policy
• Validates the policy before deployment
• Makes environments created through automation more secure, scalable, consistent, and preventative
• Easy to update, maintain, and version policies

What is required to implement policy as code?

Policy as code requires defining policies (codifying policies) using programming languages like Python, YAML, or Rego. It also requires a policy engine to enforce the policies. This engine can be a built-in solution, or use a different platform or agent for policy enforcement that is decoupled from the application or platform. See the following diagram that shows a decoupled policy engine.

Policy as code landscape

Policy as code is not a new concept. It is gaining traction because organizations are adopting automation to increase productivity and scale deployments -- IaC, for example. As organizations spin up infrastructure faster and faster at scale, compliance, security, and controls get sacrificed, which has amplified the need for policy as code.

Another reason why policy as code is gaining traction is regulations and standards. Regulations and standards like PCI DSS are continuously updated and becoming increasingly complex, making the process more complicated, time-consuming, and expensive to implement. This makes the outcome more people-dependent, and thus, inconsistent and prone to errors.

Policy as code is normally implemented in two ways. The common one is that the policy engine is embedded inside the a larger platform, such as Sentinel.

Another way policy as code is implemented is that the policy engine, like Open Policy Agent, is not built into the solution but is decoupled from the application itself like our solution is.

Currently, there are more than eight vendors that provide policy as code offerings. In general, the current policy engines have some significant limitations, including:

• Only work with the vendor's product. This can result in a large amount of refactoring of existing IaC or partial coverage of the policies.
• Require uploading the configuration files to the cloud. This increases the security risks.
• No easy way to audit or mitigate current environments. This becomes important if the policies change.

Why choose the Ansible Automation Platform and Open Policy Agent?

You might wonder what Ansible Automation Platform brings to the table that makes the IBM and Red Hat offering unique or more competitive. First, Ansible Automation Platform cannot provide a policy as code solution by itself; it requires a policy enforcement engine. After much research, we chose Open Policy Agent, an open source engine developed by Styra. In the next section, we will discuss Open Policy Agent and its benefits.

The advantage of this offering is that it applies to myriad use cases, since the policy engine is decoupled from Ansible Automation Platform. The key differentiator is that Ansible Automation Platform can ingest most of the available IaC -- like Terraform, Azure Resource Manager templates, AWS CloudFormation, Ansible Playbooks, Helm, Chef, Puppet, etc. -- and is widely used and a stable platform. The other advantage of Ansible Automation Platform is that it can deploy to most known environments, including VMware, public clouds (AWS, IBM, Azure, Google), container orchestration platforms like Kubernetes, Docker, and Red Hat OpenShift Container Platform. As new environments are introduced and current ones evolve, this offering will automatically work, provided Ansible Automation Platform continues to support them. This makes the offering easy to adopt and implement with product support from Red Hat. Another advantage is that the policy engine is decoupled from Ansible Automation Platform, making it replaceable if required with another policy agent.

Other key advantages include:

• Works with other IaC choices
• Configuration information stored onsite
• Validates existing environment for non-alignment
• Automatically generates Ansible Playbooks to fix issues with current environment
• Can validate developers’ code locally
• Central management and workflow engine
• Works onsite and in the cloud
• Inherits the advantages of the Ansible Automation Platform

Open Policy Agent

Open Policy Agent is a general-purpose open source policy engine developed by Styra. Styra contributed it to the Cloud Native Computing Foundation (CNCF), and it's been a graduate project since 2021. Styra has several integration partners, including AWS, Curity, Envoy, Kasten, Kong, Kubernetes, and Terraform. Styra provides support for Open Policy Agent through a subscription model. Open Policy Agent provides a purpose-built policy language, policy engine, tooling, and more than 100 integrations to help you write and enforce policies across the cloud-native ecosystem.

Policies are codified in Open Policy Agent using a language called Rego. We choose Open Policy Agent because it offers us a mechanism to codify policies and then test those policies against automation code. It was a natural choice because it works in an decoupled model, enabling us to use it without making any major changes to Ansible Automation Platform.

Open Policy Agent has become industry-standard because it is a graduated CNCF project and it meets the enterprise needs because it is flexible, satisfies performance standards, and is reliable.

Open Policy Agent handles authorization through Rego. With Rego, users can write policy as code, define their entire setup, then apply these rules to every running Open Policy Agent. Open Policy Agent handles incoming requests using internalized decision-making, expressed through Rego. Open Policy Agent has been integrated by several enterprises and is usable with standard infrastructure tools such as Kubernetes, Envoy, Terraform, and Azure, Google, IBM, and AWS. This makes it an excellent tool for developers to create their policy as code offerings, regardless of how their system or applications are set up.

There are many advantages of Open Policy Agent, including:

• General purpose open source decision engine
• Unifies policy enforcement across the stack
• Provides a high-level declarative language to specify policy as code
• Simple APIs to offload policy decision-making from your software
• Can be used to enforce policies in microservices, Kubernetes, CI/CD pipelines, API gateways, and more
• Framework to write tests for your policies
• Provides low-latency/high-performance for use cases
• Provides a profiler for the policies you have written
• Provides domain-agnostic APIs to manage and enforce policies
• Can be extended with custom built-in functions and plug-ins
• Provides CLI commands

Limitations of Open Policy Agent include:

• Requires learning a new programming language: Rego
• Policy evaluation is CPU-bound and currently single-threaded
• The viability of Styra and its ongoing support for Open Policy Agent
• Lack of libraries that support rules for common compliance and policy standards -- the most significant limitation currently
• Open Policy Agent requires the code being evaluated to be in JSON, which can be limiting in some cases

Use cases for policy as code

1. IaC policies (on-premises and public cloud) -- IaC frameworks enable infrastructure teams to provision and manage cloud resources consistently and efficiently. IaC adds complexity and additional challenges to securing cloud-native and on-premises environments. Policy as code provides an opportunity to automate security feedback and guardrails in code, making it more efficient and proactive.
2. Authorization and access control policies -- API authorization and access control are excellent examples of this.
3. Security policies, including network policies, end-point protection policies, etc. -- An excellent example of these is closing all ports when new instances are set up, encrypting data at rest, allowing connection from a specific VLAN to another VLAN, and allowing Internet access based on the VLAN the instance resides in.
4. Operational best practices (configuration management policies) -- An example of this is policies from site reliability engineering teams aimed to ensure the high availability of the services in a production environment even when a cloud availability zone is down.
5. Cost optimization -- An example of this could be a policy that dictates that your DevOps teams must shut down the development environments outside of business hours or must tag the AWS resources created with a cost center.
6. Kubernetes -- An example of this could be Kubernetes Pod Security Policies that must be implemented on the clusters to improve the security posture.
7. Enforce website and browser policy based on use policy setup
8. Government regulations and legislation -- One example of this is the PCI DSS policy. PCI DSS is a set of technical and operational requirements; PCI data in a database must be secured and compliant.

Summary

In this article, we have covered a new model called policy as code, from IBM and Red Hat. At a high level, it is an approach to policy management in which policies are defined, updated, shared, and enforced using code. Our solution is a decoupled solution and has a number of advantages over other solutions currently available, including:

• Ansible and Ansible Automation Platform have the ability to work with most of the tools heavily in use both on-premises and in the different public clouds.
• Ansible Automation Platform is heavily adopted by the industry at large.
• Easier to learn since this solution leverages Ansible Automation Platform.
• Most if not all your current automation can be used without modifying it.
• Solution is overall flexible, reliable, and builds on top of Ansible Automation Platform, making it an attractive choice.

You can learn more about Ansible on IBM Developer.

Acknowledgements

We would like to thank John Martin and Jennifer Nguyen from the client engineering team that is working with us to do demonstrations to evangelize this new service; our managers, Connie Chung, Sarah Stolpe, Mark Parzygnat, Jose Luis Spagnuolo, and Rob Sauerwalt in guiding how to navigate IBM and Red Hat processes as we develop this service.