Policy-as-Code

Policies are defined in high-level, declarative languages (e.g., Rego for Open Policy Agent, Cedar for AWS Verified Permissions) that specify what the desired security state is, not how to enforce it. This machine-readable format enables:

• Automated evaluation by policy engines.
• Static analysis for logic errors and conflicts.
• Integration into CI/CD pipelines and runtime systems.

Policy definitions are treated as source code, stored in version control systems (e.g., Git). This enables:

• Change tracking and audit trails for every policy modification.
• Peer review processes for security policy changes.
• Policy testing using unit and integration tests to validate behavior against known cases before deployment.
• GitOps workflows where policy changes are promoted through environments via pull requests.

PaC implements a clear separation of concerns between policy definition and enforcement, following a standard pattern:

• Policy Decision Point (PDP): The engine (e.g., Open Policy Agent) that evaluates policies against an incoming request's context (user, action, resource).
• Policy Enforcement Point (PEP): The component embedded in an application, API gateway, or infrastructure tool that intercepts requests, queries the PDP, and enforces the allow/deny decision. This decoupling allows a single, consistent policy to be enforced across diverse systems.

Authorization decisions are not based solely on user identity. Policies evaluate a rich set of attributes from multiple dimensions:

• Subject Attributes: User role, department, clearance level.
• Resource Attributes: File sensitivity tag, database classification, cost center.
• Action Attributes: The specific operation being requested (e.g., read, write, delete).
• Environmental Context: Time of day, request location, device security posture, IP address. This enables sophisticated models like Attribute-Based Access Control (ABAC).

PaC shifts compliance from manual, periodic audits to continuous, automated validation. Policies encode regulatory requirements (e.g., HIPAA, GDPR) and security benchmarks (e.g., CIS). These policies can be run continuously to:

• Scan infrastructure-as-code (Terraform, CloudFormation) for misconfigurations before deployment.
• Validate runtime state of cloud resources against golden standards.
• Generate evidence for auditors automatically, proving that guardrails are always active and effective.

A core promise of PaC is applying a consistent policy language and enforcement mechanism from infrastructure to application layers. The same policy engine can govern:

• Infrastructure Provisioning: "No storage buckets can be publicly readable."
• Kubernetes Admission Control: "Pods must not run as root."
• Application API Authorization: "Users can only edit documents they own."
• Data Pipeline Access: "This service account can only query PII data if the destination is encrypted." This eliminates security silos and contradictory rules.

The Policy Decision Point (PDP) is the core reasoning component in a policy-based architecture. It is responsible for evaluating access requests against a set of compiled policies to render an authorization decision.

• Evaluation Engine: In a PaC system like OPA, the PDP loads and evaluates Rego policies against the provided input (user, action, resource, context).
• Input/Output: It accepts a structured query (e.g., a JSON object describing the request) and returns a policy decision, often with detailed reasoning or partial results.
• Centralized Logic: The PDP centralizes policy logic, ensuring consistent enforcement regardless of which Policy Enforcement Point (PEP) makes the request.

The Policy Enforcement Point (PEP) is the component that intercepts a specific request for access to a resource, consults the PDP, and enforces the returned decision.

• Gatekeeper Role: A PEP acts as the guard at the point of access. Examples include a Kubernetes admission controller, an API gateway, or a middleware function in a microservice.
• Protocol: The PEP is responsible for formulating the correct query for the PDP, sending it (often via a REST API), and then allowing or denying the request based on the PDP's output.
• Distributed Deployment: While policy logic is centralized in the PDP, PEPs are deployed at every resource or service that requires protection, creating a distributed enforcement layer.

Rego is the purpose-built, declarative query language used by the Open Policy Agent (OPA) to define policies. It is designed for expressing complex rules over hierarchical data structures.

• Declarative Logic: Developers specify what the policy should enforce, not how to enforce it. The OPA engine handles the evaluation logic.
• Data-Centric: Rego policies query and reason over JSON/YAML-structured data, making them ideal for modern APIs and configurations.
• Key Constructs:
  • Rules: Define sets of values or decisions.
  • References: Navigate nested input data.
  • Comprehensions: Transform and aggregate data.
  • Built-in Functions: Provide operations for string manipulation, aggregation, and type checking.
• Example: A rule to allow access only if the user's department matches the resource's owner: allow { input.user.department == input.resource.owner }.

Compliance as Code is the application of Policy-as-Code principles to automate the validation and demonstration of adherence to regulatory standards and internal security benchmarks.

• Automated Audits: Instead of manual checklists, compliance requirements (e.g., CIS Benchmarks, PCI-DSS, HIPAA) are encoded into executable policies that continuously scan infrastructure and configurations for violations.
• Shift-Left for Compliance: Compliance checks are integrated into the development lifecycle, identifying issues during the IaC authoring or CI/CD phase, long before deployment to production.
• Evidence Generation: The policy evaluation results serve as auditable proof of the system's state at any given time, streamlining the audit process.
• Real-time Monitoring: PaC engines can be used in a continuous monitoring mode, alerting on configuration drift that introduces compliance violations in live environments.