Policy Deployment Engine

Cloud Security, Policy-as-Code, Compliance

This group project was part of my university's capstone program. Our goal with the Policy Deployment Engine (PDE) is to audit cloud configurations prior to deployment to check for compliance. A series of policies are authored and act as the "gateway" to facilitate this. Our project is the first of its kind at Deakin University, initially aimed at GCP services.

View the project on GitHub↗!

Project Summary

Background

The Cloud is the backbone of modern organizations. Repeating cloud configurations for different resources manually quickly becomes difficult, leading to the idea of Infrastructure-as-Code (IAC). Frameworks such as Terraform↗ enable cloud configurations to be expressed as code, facilitating scalability.

However, managing and auditing different cloud plans take time, so the initial problem is still present. Manual audits can also introduce human error. Hence, the PDE operates between what is planned and what is deployed, scanning resources with associated security policies. The declarative language Rego↗, developed as the main query language in the Open Policy Agent (OPA)↗, is chosen to achieve this. After assessing their assigned service and resources, members design their policies using our development framework, and evaluate their correctness by scanning compliant and non-compliant Terraform configurations.

For example, a storage bucket resource should have the "force_delete" option disabled by default to prevent accidentally data deletion. Though a simple example, when applied to different resources, the PDE quickly becomes a powerful compliance-enforcing tool for cloud environments via its library of security policies.

Policy Development Framework (helpers.rego)

A big problem stems from standardization. With 30 (and later, 60) members, how do we ensure that policies are structured the same way project-wide? Without standardization, the following issues arise:
- inconsistent naming convention
- lack of compatibility
- difficulty in understanding or maintaining another person’s policy
- duplicated logic across files
- increased review time and confusion.

Worse still, each member would need to be well-versed in Rego to implement needed functions. To address these concerns, I developed the helpers.rego, a suite of functions to aid in developing policies; i.e., it is our project's custom library for policy development. Working and maintaining the codebase alongside another lead, the helpers.rego supports policy development that requires: white/blacklisting, range checks, pattern checks, IF-logic, and AND-logic. Most importantly, members only need to focus on the security-aspect of the project, i.e., accessing their assigned GCP service and its resources, with the nitty-gritty of Rego left to the development team. I also standardized the project's current templates and conventions to do with file and folder structuring.

See the below for more information about the helpers.rego, namely the documentation (reflected↗) and raw source code.