What is Policy as Code?
Policy as code is also a part of the larger “as code” movement which aims at automating the compliance process where business logic is translated from a spoken language into a high-level machine language. This helps simplify, manage and enforce policies. It involves decoupling the policy from the business logic of an application. By representing policies as code in text files, software development best practices can be adopted, such as version control, automated testing, and automated deployment.
The problem with traditional policy enforcement process
Each organization will have its own practices and processes while developing and delivering software. Based on their business, they may have to comply with industry-recognized frameworks such as SOC2, CIS, PCI DSS, etc.
Most of these policies are either part of the business logic code or enforced manually. This results in the same set of policies being written in different languages, in different code repositories, and managed by different teams.
Even if you want to change one rule or create a new version of the policy, it may take weeks or months to implement it.
Organizations define and enforce policies traditionally. A Compliance team will compose the business requirements into a document with specific rules that they will expect everyone to follow. The enforcement process happens through a ticketing mechanism. In case of a software release, the DevOps Engineer will raise a ticket and submit it to the compliance team to review. The compliance team then reviews the release and can either reject or approve it.
This workflow is manual and slow. The ticketing mechanism is itself error-prone because the incident has to be manually raised by a person. It is difficult to scale as the entire process is manual and checking a release at the last stage of the software release cycle is a wasteful practice.
Also, policies are managed by different application development teams, your central compliance or security team may have less visibility and it is difficult to audit the changes.
Why do organizations need policies as Code?
Policy as Code can automate the policy check process and bring policy checks as a part of the software speed time to market.
With Policy as Code, compliance teams can construct multiple test cases that always validate every deployment happening in a pipeline. These enforcement checks can be placed at every stage of the pipeline from git push to production deployment. These checks will ensure that a compliance issue is fixed before it snowballs into something unfixable. Whereas without the automated policy verification organization have to rely on the compliance team to perform these checks at the end the deployment cycle.
Let us take an example. A policy set by the compliance team mandates that all the servers in the cloud must be in the US region. When a developer is preparing a cloud server by using an existing script from a previous project, it might spin the server at a different location as per the instructions of the previous project. If Policy as Code had not been implemented, this issue would have been highlighted just days before release. Last-minute surprises like this incur delays in deployment and increase MTTR and team frustrations.
The goal of Policy as Code is not to detect policy violations, but to prevent them.
Policy as Code will help enforce a policy standard for your organization. For complex organizations with multiple business policies can be enforced as per the clusters defined by the Compliance and Security Engineers. The shift from speaking language to code improves the automation and efficiency in tasks by enforcing the rules that prevent wrong setup and configuration in your cluster/environment.
Challenges faced by Engineers while implementing Policy as Code
- Installation and maintenance of policy engine (where we ship it with our product)
A policy as code agent has to be installed beside the systems or applications that are being monitored. It will simulate the policy-checking decisions that previously would have required manual checks. The policies need to be updated as per requirements and dedicated teams might be necessary to manage the system.
OpsMx ISD is pre-configured with OPA that saves your teams from the hassle of breaking things while installing and configuring it.
- Tracking changes to policy and version control (where we suggest the git repo based approach)
Policy once implemented, needs to have a version control. Version control is necessary for audit purposes and keeping a track of all policy changes. Using OpsMx ISD allows you to quickly link your Git account to maintain policy through the git repository.
- Converting a policy document into code
The most difficult part of implementing a Policy as code is to understand the granular policies in each framework and converting it to a high level language. These codes need to go through multiple checks and testing before integration into the pipeline.
OpsMx ISD has simplified integration by shipping commonly used policies with the product.
The Solution
Policy as Code involves writing policies followed by an organization in a high-level language. The language may vary based on the chosen policy engine. For example, Open Policy Agent is one of the best open-source solutions available in the market and it uses a language called Rego to define policies.
The organization may create a central git repository to maintain these policies, which will help the compliance team to version control and audit policy changes.
How OpsMx supports Policy as Code
OpsMx ISD (Intelligent Continuous Delivery platform) comes with out-of-the-box support for OPA, which allows you to enforce two types of policies in the software delivery process, Static Policies, and Dynamic Policies.
A static policy allows users to evaluate conditions before the start of pipeline execution and a dynamic policy allows users to evaluate runtime conditions.
OpsMx maintains a public repository of policies that are written in Rego and compatible with OPA. You may use these as specific pipeline stages or as system-wide configurations to automate policy enforcement.
Here are a couple of examples from the repository.
Static Policy to restrict image source while a pipeline is being saved
######
#IF
# application named "sampleapp"
# deploying to an account "production"
# THEN
# The image, if present MUST start with "docker.opsmx.com"
#
# Other applications/pipelines can be saved without these restrictions
package opa.spinnaker.pipelines.new
deny[msg] {
count(input.new.stages)>0
input.new.application == "sampleapp"
input.new.stages[_].account == "production"
images := input.new.stages[_].manifests[_].spec.template.spec.containers[_].image
not startswith(images, "docker.opsmx.com/")
msg := sprintf("[%v] being deployed to be from docker.opsmx.com", [images])
}
Dynamic policy that verifies the deployment is not happening during a blackout window
# This policy verifies the deployment is not happening during a blackout window.
# The blackout window can be configured by changing hour
package opa.pipelines.datetimeslot
deny["Pipeline has no start time"] {
startTime := input.startTime
startTime == 0
}
weekday {
day := time.weekday(time.now_ns())
day != "Saturday"
day != "Sunday"
}
deny["No deployments allowed between 09am - 04pm on weekdays"] {
[hour, minute, second] := time.clock([time.now_ns(), tz])
tz = "Africa/Lagos"
hour >= 9
hour < 16
weekday
}
To know more about the usage of policies visit Continuous Compliance using OpsMx ISD
For detailed documentation visit Policy Management Overview
0 Comments