Co-authored by Anders Eknert, Styra; Idan Shahar, Allero; and Jim Bugwadia, Nirmata.
Continuous Delivery Landscape is intended as a map to explore various tools and services that support a continuous delivery-oriented software environment from individual process steps to full pipeline orchestration. The landscape contains various categories and tools and services are placed under them accordingly.
The Continuous Delivery Foundation (CDF) has recently introduced “Policy” as a new category to the CD Landscape. The first three projects listed within the category are Allero, Kyverno, and Open Policy Agent (OPA).
This post talks about what policy is, how policies could help organizations, and how they are employed within Continuous Delivery (CD) pipelines with the help of a few sample use cases. Perspectives from the three projects listed in the policy category are included as well.
What is a Policy
The Cambridge Dictionary defines policy as:
“a set of ideas or a plan of what to do in particular situations that has been agreed to officially by a group of people, a business organization, a government, or a political party”
This description isn’t entirely different from how the policy is described within different technical domains. In CD, the policies defined and employed by organizations ensure that the software that goes through the pipelines adheres to various criteria such as security and compliance. If the software doesn’t meet any of the criteria, it gets blocked from flowing further within the pipelines and corresponding feedback is made available to the individuals and teams to take further action.
Policies in CD
CD is a critical software development practice that enables organizations to deliver software with security and speed. The emergence of cloud native and the move to microservice architectures increased the importance of CD even further, increasing the pipeline’s complexity. The result was multiple CD processes that aren’t always uniform, since microservices can be written in different languages, with different requirements, and are subject to different types of checks.
This diversity makes the use of policies necessary to ensure the code goes through various verification processes and is ready for production. These processes can vary from company to company and generally deal with the technical aspects of the code in question. A few examples of the checks that are part of the processes include:
- code convention checks, successful completion of specific tests,
- source code analysis (SCA) to check if an outdated dependency is included in a certain component and if containers are running with elevated privileges,
- and so on.
Policies aren’t limited to technical aspects. For example, organizations can have policies to make sure no new software can be deployed to production during certain periods of the year (like the week before Black Friday) to prevent unexpected downtimes or certain features aren’t activated in certain geographical regions due to legal concerns or regulations (like GDPR).
Non-technical requirements require organizations to take a more holistic approach while developing and implementing policies since there are different stakeholders with different concerns, considerations, and ways of working. For example, developers who work with software development directly will naturally develop policies as part of their daily work, especially if the organization is using a Policy as Code approach. However, things are quite different for other individuals and teams within the organization, such as legal departments and sales teams. It’s critical for the leaders to empower them to contribute to developing and maintaining policies to make sure the various aspects of the software deployed to the production conform to business policies.
An additional use case with the policies in CD context is that policies are applicable to CD processes and pipelines themselves as well to help organizations to set organization-wide CD standards and create guidelines to ensure everyone in the organization follows them. Additionally, organizations use policies to control the behavior of CD pipelines to make sure the pipelines do only what they are supposed to do and nothing more. Any irregularities caught during pipeline executions could be flagged and blocked with the help of policies.
Perspectives From the Projects
Allero
Allero is an open source CLI policy tool that prevents misconfigurations in CI/CD pipeline manifests. There is no single way to write CI/CD pipelines, and companies end up having many, unstandardized pipeline manifests. This makes it difficult to ensure security, code quality, and compliance standards are in place in every pipeline.
Allero’s open source tool helps companies by continually scanning their CI/CD pipeline manifests and validating them against a set of policies. Once failed, users can configure Allero to fail a pipeline completely, or be notified about the breach of policy. By using Allero’s policies in CI/CD pipelines, companies can prevent failures & security risks from reaching production.
Allero acts as guardrails for developers, allowing them to build and maintain their own CI/CD pipelines with focus on application logic, while having peace of mind that DevOps engineers have got their back with non-core functionalities like security, compliance and operations.
We’ve built Allero with an engineering-first mindset, allowing engineers to take advantage of various built-in rules, and also easily create custom rules which can (and are encouraged to) be contributed back to the community.
Kyverno
Kyverno is a policy engine designed for Kubernetes. Kyverno policies, and policy reports, are Kubernetes resources making it possible to build policy management workflows using the Kubernetes API.
Kyverno policies can validate, mutate, and generate any Kubernetes resource. Kyverno can also verify image signatures and attestations for software supply chain security. Kyverno runs as an in-cluster admission controller and as a command line tool in cloud-native delivery pipelines so securing configuration manifests and images can be integrated into CI/CD workflows.
Open Policy Agent
Open Policy Agent (OPA) was created to unify the way organizations work with policy across the whole stack. The larger the organization, the more programming languages, tech stacks and frameworks are likely to be encountered. While these commonly come with their own unique ways of defining policy, it is challenging to manage rules, configurations and follow up on decisions made (i.e. auditing) across widely disparate systems at scale.
As a general-purpose policy engine, OPA integrates with nearly any CI/CD system, and allows policy-based enforcement to control not just the configuration of the resources about to be deployed, but also the build and deployment pipelines themselves! In just the last few years, a number of OPA-based projects have emerged that focus on applying policy to the declarative configuration of an organization’s build and deployment pipelines. This can give DevOps teams greater freedom in configuring the CI/CD system to their needs, while at the same time meeting the requirements of the organization with a baseline of rules, best practices and security configurations to be maintained.
However, the main use case for policy in CI/CD is to help construct the guardrails for what will be deployed. Due to its general purpose nature, OPA offers a compelling alternative in this space, where a single policy engine may be used to build and enforce rules across widely disparate systems — like provisioning of infrastructure and cloud resources, bare metal deployments, Kubernetes resource manifests or serverless workloads.
