Two web-scale companies have recently shared how they solved mission-critical authorization challenges using Open Policy Agent (OPA). These accounts validate the value of what we’ve built with OPA and give important blueprints for engineers looking to address similar challenges. We consider these required reading for anyone considering or using OPA at scale. In this post we review these two case studies to highlight common patterns and important differences.

Two years ago, I explored the idea of linting Rego with Rego on this blog, and how we could use the abstract syntax tree (AST) representation of a Rego policy as JSON input data, allowing us to write a “linter” for Rego using Rego itself. Open Policy Agent (OPA) is well-established for use cases like application authorization, cloud infrastructure and Kubernetes admission control, where we normally talk about policy as guardrails. But who’s guarding the guardrails?

Whether you use the 600+ Styra provided compliance rules or build your own, with Styra DAS, the same rules can now enforce compliance of your Kubernetes and Terraform infrastructure across all of the Code, Deploy, and Run phases.

I’m excited to announce the launch of Styra Declarative Authorization Service (DAS) and Open Policy Agent (OPA) as a Red Hat Ansible Certified Content Collection. Teams can now automate infrastructure deployments with the right guardrails in place to enable security-enhanced operations and align with regulatory compliance.

Kubernetes has become the de facto way to run modern computing platforms, both in the cloud and on-premise. This is a huge change from just a few years ago, and it didn’t happen overnight. On the road to production readiness with Kubernetes, many have run afoul. Thanks to Kubernetes Failure Stories though, engineering teams from around the world have shared in detail what they did wrong and how they can avoid making the same mistake in the future.

Kubernetes admission control is a mechanism that validates and modifies requests to the Kubernetes API server before they are processed. Admission control can enforce policies, security rules, resource limits, default values and other elements of the cluster’s use. This mechanism can also reject requests that violate certain rules or conditions.

The practice of infrastructure as code (IaC) has enabled platform teams to control infrastructure using code stored in Git. This enables teams to apply standard development practices like code review and testing to infrastructure management. The practice of GitOps takes this a step further by: Open Policy Agent (OPA), thanks to its Rego policy language, enables organizations to manage their authorization policies as code (PaC).

We recently released Enterprise OPA, the drop-in enterprise edition of Open Policy Agent (OPA). With Enterprise OPA, we aim to solve several challenges large organizations encounter when using OPA. These include performance and memory usage when using large datasets, keeping authorization data up to date and performing policy updates in a safe way.

A common use case our customers have for Open Policy Agent (OPA) is access control. The problem of access control is generally broken down into two parts, authentication and authorization. Authentication is about making sure we can trust someone’s stated identity, authorization is making decisions about who can do what.

A microservice application comprises small autonomous services that communicate with each other through application programming interfaces (APIs) — as standalone services or via a service mesh. These API calls or requests raise security and compliance concerns if not appropriately secured through authentication and authorization checks. Service-to-service authorization is the process of determining what actions an authenticated service is allowed to perform based on pre-defined policies.