Introduction to policy as code with automation

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.

[ Download A system administrator's guide to IT automation. ]

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.

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 (or codified). It also helps decouple policy from an application's business logic. This approach has several advantages, including:

• Enables adopting software development best practices
• Automates testing the policy-enabling scale
• Enforces style guides and security rules
• Provides traceability for compliance
• Centralizes rules, control, and management
• Codifies policies
• Allows version control
• Is consistent, recursive, and cost-effective

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. ]

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 achieve compliance, standards, or consistency.

There are two types of policies:

• Static policies are evaluated before execution. For example, it might test whether a device or resource name adheres to a naming convention before provisioning the device or resource.
• Dynamic policies are evaluated and enforced during runtime. For example, it can check whether user data is created, moved, or saved from a defined geographic zone at runtime.

Challenges with traditional policy enforcement

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 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 dependends on human interpretation to enforce the policies.
• Any required changes could require a significant change after the fact, making it painful and wasteful.
• Manual changes in policies could have unintended consequences.
• The lack of a framework makes it difficult to audit changes.

[ Get the ultimate CI/CD resource guide. ]

Why use policy as code?

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:

• Simplifying creation of test cases (the policy)
• Automating checking and enforcement of the policy
• Validating the policy before deployment
• Making environments created through automation more secure, scalable, consistent, and preventative
• Being easy to update, maintain, and version policies

Common use cases include:

• IaC policies (on-premises and public cloud) to provision and manage cloud resources consistently and efficiently
• Authorization and access-control policies
• Security policies, including network and endpoint protection policies
• Operational best practices (configuration-management policies)
• Cost optimization
• Kubernetes policies
• Website and browser policies
• Government regulations and legislation

What do you need to implement policy as code?

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.

What's the 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, 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:

• They only work with the vendor's product. This approach can result in a large amount of refactoring of existing IaC or partial coverage of the policies.
• Configuration files must be uploaded to the cloud. This plan increases the security risks.
• There's no easy way to audit or mitigate current environments. This approach becomes important if the policies change.

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.

Policy as code with Ansible Automation Platform and Open Policy Agent

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:

• Works with other IaC choices
• Configuration information is stored onsite
• Validates the existing environment for non-alignment
• Automatically generates Ansible playbooks to fix issues with the 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

[ Want to test your sysadmin skills? Take a skills assessment today. ]

What is Open Policy Agent?

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:

• Provides a general purpose open source decision engine
• Unifies policy enforcement across the stack
• Provides a high-level declarative language to specify policy as code
• Offers APIs to offload policy decision-making from your software
• Enforces policies in microservices, Kubernetes, CI/CD pipelines, API gateways, and more
• Offers a 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-neutral APIs to manage and enforce policies
• Extends with custom built-in functions and plug-ins
• Allows command-line interface commands

Limitations of Open Policy Agent include:

• Requires learning 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 (currently the most significant limitation)
• Requires the code being evaluated to be in JSON, which can be limiting in some cases

[ Cheat sheet: Get a list of Linux utilities and commands for managing servers and networks. ]

Wrap up

Our decoupled policy-as-code solution has several advantages over other solutions currently available, including:

• Ansible and Ansible Automation Platform can 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.
• It's not difficult to learn since it leverages Ansible Automation Platform.
• Most, if not all, of your current automation can be used without modifying it.
• The solution is flexible, reliable, and builds on top of Ansible Automation Platform, making it an attractive choice.

This article is based on "Ansible does policy as code the best" presented at AnsibleFest 2022.