Explore a new way to define, update, share, and enforce policies with Ansible Automation Engine and Open Policy Agent.
Posted: December 16, 2022 |
Automation with Infrastructure as Code (IaC) and other methods can improve costs, productivity, time to market, and security, particularly for organizations adopting hybrid cloud models. Automation leads to faster operations because tasks that were done manually are now handled by code. However, automation doesn't address significant areas like compliance, governance, and standards by default. Repeatability and speed don't ensure things are done correctly—repeatability is not helpful if you make the same mistakes over and over.
Policy as code defines, updates, shares, and enforces policies using code. The key here is code because this method codifies your policies utilizing a programming language. These codified policies can help enforce or test automation scripts to verify that they follow the defined policies.
Policy as code is not a new concept, and some companies use systems that help implement it. Most of those offerings apply to particular use cases and are designed to work only with specific environments or technologies.
This article presents a new policy-as-code project built on Ansible Automation Platform and an open source policy engine called Open Policy Agent. This collaboration between IBM and Red Hat applies to multiple use cases and works with most environments and technologies.
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 (or codified). It also helps decouple policy from an application's business logic. This approach has several advantages, including:
The following diagram shows a standard process for a policy-as-code solution.
[ Learn more about server and configuration management by downloading Ansible for DevOps. ]
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 achieve compliance, standards, or consistency.
There are two types of policies:
Conventional policy enforcement is manual or semi-automated and does not scale well. Each development or application team embeds some policy-enforcement code within its applications. This code is not easily trackable or auditable because every team implements it as it sees fit due to a lack of framework definition.
Each organization follows certain practices and processes while developing and delivering software. Some must comply with industry-recognized frameworks such as SOC 2, CIS, PCI DSS, or ISO 27001. These policies are either part of the business logic code or enforced manually. This results in the same policies being written in different languages, stored in several code repositories, and managed by different teams. This can also result in different groups interpreting the same policy differently. In addition, 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 approach is very cumbersome to enforce.
Another issue is that organizations define and enforce policies 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 as code addresses the weaknesses of the traditional enforcement method. It automates defining and enforcing the policies through a specific technology platform. There are multiple advantages of using policy as code, including:
Common use cases include:
Policy as code requires defining (or 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. The following diagram shows a decoupled policy engine.
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, amplifing the need for policy as code.
Another reason why policy as code is gaining traction is regulations and standards. Requirements 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.
Currently, at least eight vendors provide policy-as-code offerings. In general, they have some significant limitations, including:
There are two ways to implement policy as code. The most common is that the policy engine is embedded inside a larger platform, such as Sentinel.
The other way is to decouple the policy engine (such as Open Policy Agent) from the application rather than build it into the solution. This is the structure of the Red Hat and IBM solution I'll describe below.
Ansible Automation Platform does not 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.
The advantage of this model is that it applies to various use cases since the policy engine is decoupled from Ansible Automation Platform. The key differentiator is that Ansible Automation Platform can ingest IaC from multiple vendors and is a widely used and stable platform. It also can deploy to most known environments, including virtualization platforms, public clouds (including AWS, IBM, Azure, and Google), and container orchestration platforms (such as Kubernetes, Docker, and Red Hat OpenShift).
This flexibility is an advantage as new environments are introduced and current ones evolve, making the offering easy to adopt and implement. Also, because the policy engine is decoupled from Ansible Automation Platform, you can replace it with another policy agent if required.
Other key advantages include the following:
[ Want to test your sysadmin skills? Take a skills assessment today. ]
Open Policy Agent is a general-purpose open source policy engine developed by Styra. It 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.
Styra contributed Open Policy Agent to the Cloud Native Computing Foundation (CNCF), and it's been a graduated project since 2021. It has become an industry standard because it is a CNCF project, is flexible, satisfies performance standards, and is reliable to meet enterprise needs.
Policies are codified in Open Policy Agent using a language called Rego. Our team chose it because it offers a mechanism to codify policies and test them against automation code. It was a natural choice because it works in a decoupled model, enabling us to use it without making any major changes to Ansible Automation Platform.
Open Policy Agent handles authorization through Rego. Rego allows users to write policy as code, define their entire setup, then apply these rules to every running Open Policy Agent. It handles incoming requests using internalized decision-making expressed through Rego.
There are many advantages of Open Policy Agent, including:
Limitations of Open Policy Agent include:
Our decoupled policy-as-code solution has several advantages over other solutions currently available, including:
This article is based on "Ansible does policy as code the best" presented at AnsibleFest 2022.
