Policy as Code (PaC) Defined

Policy as Code is the practice of defining decision logic programmatically. With this approach, policies for security, compliance, audits and monitoring are defined using a general purpose, domain-specific or markup programming language. These policies are applied as a function of a CI/CD and continuous testing pipeline.

Ultimately, policy as code allows DevOps teams to automate workflows while managing security, risk and compliance.

Let’s look at how policy as code works. We’ll start with what it looks like without codifying your policies.

Traditional development incorporates policies — manually

Traditionally, developers follow documented procedures that specify a variety of organizational policies, such as those for security, auditing and compliance.

This manual approach of adhering to a vast number and variety of applicable policies has a number of challenges:

• Human errors and lack of expertise contribute to policy infringements that can expose the IT network to security risks and compliance malpractices.
• Dynamically changing and hidden dependencies in ephemeral cloud-based environments also adds to the complexity of enforcing a variety of security policies in real-time.
• Documented policies may be interpreted differently between team members from different functional departments pursuing their own business objectives.

In some cases, a user may unintentionally disregard a policy due to lack of awareness, collaboration and information sharing between other users.

Enter policy as code, which aims to remedy these manual issues.

How policy as code works

Policy as Code systems typically rely on open source agents or a policy engine. These work like this:

1. Take predefined policies as an input.
2. Evaluate the policy control parameters that may be applicable to a specific user query.
3. Authorize and approve requests according to the defined policies.

A policy validation engine may be introduced into the CI/CD pipeline that takes the policy inputs from a policy version control system, evaluates the code builds from a version control system before approving the build for a deployment engine. The policies may be either:

• Static and evaluated prior to execution
• Dynamic and executed during runtime

A policy management system can extend this framework to introduce automated and continuous documentation and collaboration between cross-functional teams.

The concept of Policy as Code is similar to the Infrastructure as Code (IaC) approach of provisioning and managing infrastructure operations programmatically.

Policy as code: when & why to use it

Where IaC is suitable for Infrastructure and Operations (I&O) tasks, Policy as Code follows similar DevOps goals relating to security operations, risk management, data handling and access to sensitive digital workloads, apps and services in various IT environments.

Let’s look at some of the key advantages and use cases of Policy as Code:

Dynamic and real-time IAM

Authorization solutions rely on multiple control parameters, environment and resource information to determine the context of a request and handle authorizations. Advanced authorization systems use Policy as Code to integrate policy enforcement within the CI/CD and testing environments instead of the application code or external manual tests.

This is particularly useful for Identity and Access Management (IAM) systems that rely on modern policy-based rules frameworks such as RBAC where the policy can change dynamically and the control parameters can be variably defined.

Modular, decoupled policy environments

Policy as Code allows DevOps teams to decouple the policy environment and codify modular components of the policy, which can apply to isolated systems and processes without an overlap. This approach simplifies policy enforcement and governance adoption. Users can:

• Define custom policies.
• Automatically execute when specific conditions are met, such as microservices and container environments that interact with sensitive data workloads.
• Evaluate in real-time for monitoring and traceability.

Shift left security

The practice of security testing early during the software development lifecycle — shifting left — allows DevOps teams to identify and resolve security issues, as well as anticipate changes that may arise at later stages. Policy enforcement depends on these changes, which are often only identified in retrospect.

By codifying policy enforcement, the process becomes automated, passive and applied in real-time with respect to every change — including unforeseeable changes. This helps security testing teams to evaluate policy enforcement for a variety of use cases and environment settings throughout the SDLC pipeline.

Centralize and automate policy management

Policies tend to change frequently depending on:

• Security risks
• Operational scale
• Regulations
• Market trends
• Business objectives

To enforce policies consistently and uniformly across all IT and digital assets, codifying policies allows full control over the policy environment. Manual policy enforcement is replaced by real-time systems that can conduct a large number of parallel tests to evaluate the impact of policy changes on system performance.

Limitations of Policy as Code

The Policy of Code approach currently faces some limitations. In order to ensure full coverage with existing IaC policies, any policy-as-code offering must be fully compatible with open source and standardized cloud environments. The available policy engines currently in the market may not support all vendor products deployed in your cloud-based environment.

Furthermore, applying a policy-as-code system may require moving configuration information to third-party cloud servers, potentially exposing to security risks as IAM related configurations may be exposed if the target servers are compromised.

A shift to a general-purpose policy engine such as Open Policy Agent alleviates these concerns and provides a standardized approach to decouple decision-logic from policy enforcement.