Using OPA for multicloud policy and process portability

How Open Policy Agent allows developer teams to write and enforce consistent policy and authorization across multicloud and hybrid cloud environments

 

As multicloud strategies become fully mainstream, companies and dev teams are having to figure out how to create consistent approaches among cloud environments. Multicloud, itself, is ubiquitous: Among companies in the cloud, a full 93% have multicloud strategies—meaning they use more than one public cloud vendor like Amazon Web Services, Google Cloud Platform, or Microsoft Azure. Furthermore, 87% or those companies have a hybrid cloud strategy, mixing public cloud and on-premises cloud environments.

The primary reason that companies move to the cloud at all is to improve the performance, availability, scalability, and cost-effectiveness of compute, storage, network, and database functions. Then, organizations adopt a multicloud strategy largely to avoid vendor lock-in.

But multicloud also presents a second alluring possibility, an extension of that original cloud-native logic: the ability to abstract cloud computing architectures so they can port automatically and seamlessly (if not just quickly) between cloud providers to maximize performance, availability, and cost savings—or at least maintain uptime if one cloud vendor happens to goes down. Cloud-agnostic platforms like Kubernetes, which run the same in any environment—whether that’s AWS, GCP, Azure, private cloud, or wherever—offer a tantalizing glimpse of how companies could achieve this kind of multicloud portability.

But while elegant in theory, multicloud portability is complicated in practice. Dependencies like vendor-specific features, APIs, and difficult-to-port data lakes make true application and workload portability a complicated journey. In practice, multicloud portability only really works—and works well—when organizations achieve consistency across cloud environments. For that, businesses need a level of policy abstraction that works across said vendors, clouds, APIs, and so on—enabling them to easily port skills, people, and processes across the cloud-native business. While individual applications may not always port seamlessly between clouds, the organization’s overall approach should.

 

Using OPA to create consistent policy and processes across clouds

One of the tools that has become popular, precisely because it’s domain agnostic, is Open Policy Agent (OPA). Developed by Styra and donated to the Cloud Native Computing Foundation, OPA is an open-source policy engine that lets developer teams build, scale, and enforce consistent, context-aware policy and authorization across the cloud-native realm. Because OPA lets teams write and enforce policies across any number of environments, at any number of enforcement points—for cloud infrastructure, Kubernetes, microservices APIs, databases, service meshes, application authorization, and much more—it allows organizations to take a portable approach to policy enforcement across multicloud and hybrid cloud environments.

Moreover, as a policy-as-code tool, OPA enables organizations to take the policies that are otherwise in company wikis and people’s heads and codify them into machine-processable policy libraries. Policy as code not only lets organizations automatically enforce policy in any number of clouds, but also shift left and inject policies upstream, closer to the development teams who are working across clouds, in order to catch and prevent security, operational, and compliance risk sooner.

Pairing OPA with Terraform and Kubernetes

As one example, many developers now use OPA in tandem with infrastructure-as-code (IaC) tools like Terraform and AWS CDK. Developers use IaC tools to make declarative changes to their vendor-hosted cloud infrastructure—describing the desired state of how they want their infrastructure configured, and letting Terraform figure out which changes need to be made. Developers then use OPA, a policy-as-code tool, to write policies that validate the changes that Terraform suggests and test for misconfigurations or other problems, before they are applied to production.

Learn how to operationalize OPA at scale

This article first appeared in Infoworld on December 9, 2020. 

 Prev

Open Policy Agent Graduating in the CNCF proves need for cloud-native authZ

Next  

OPA + Styra DAS free up time and resources for a CRM solution

Subscribe

Using OPA with GitOps to speed cloud-native development

Devops teams are flocking to GitOps..

February 25
Go

The Kubernetes authorization webhook

The webhook feature of the Kubernetes API..

February 17
Go

OPA + Styra DAS free up time and resources for a CRM solution

Let’s say you were going to plan a..

February 24
Go