When introducing Open Policy Agent (OPA) to application developers and platform engineers, I normally end my presentation with a bulleted list detailing what I think are the best steps to take to start learning OPA and its declarative policy language, Rego.
Few things in recent years have changed the game plan of the tech organization as much as the infrastructure as code movement. With infrastructure itself largely having moved into the cloud, automating provisioning, upgrades and management of that infrastructure was a natural next step.
As anyone who has built or introduced a new project or product knows, success doesn’t happen overnight. It takes time and patience. When we first started the Open Policy Agent (OPA) project in 2016, we didn’t just spend all of our time on code — a lot of it was spent building awareness around the project and the community. As OPA started gaining traction, we were encouraged every time we’d hear a developer talk about OPA at a conference or mention it in a blog post.
Capital One Financial Corporation is the nation’s largest direct bank. They have a well-earned reputation as a data and tech pioneer in the financial services industry and have long been progressive in setting a bold agenda around digital and tech transformation. This has meant operating years ahead of most enterprises in moving to the cloud, scaling in-house engineering workforce and adopting agile, microservices, open source and a modern data ecosystem.
Today, more organizations than ever use Open Policy Agent (OPA) as the de facto standard for policy enforcement across the cloud native stack. A graduated project from the Cloud Native Computing Foundation (CNCF), OPA has dozens of use cases — from Kubernetes guardrails, to microservices authorization, to infrastructure-as-a-service controls — that are leveraged by millions of users.
Today, if you’re running Kubernetes, you know that security is not “built-in.” To secure your clusters, you have to configure, add or build in additional controls. Some are part of Kubernetes, like role-based access control (RBAC), but other best practices include specifying trusted repositories for known-good containers and then layering in runtime scanning tools as well.
Uptime. Reliability. Efficiency. These used to be perks, elements of forward-thinking and premium-level enterprises. Now they’re a baseline expectation. Today, consumers expect information, resources, and services to be available on-demand, updated in real time, and accessible without fuss. Imagine trying to Google something or place an order from Amazon only to be told, “Please try again in 48 hours. Sorry for the inconvenience.”
In November 2019, just after Styra raised $14 million in our Series A funding round, I wrote that the market’s move away from monolithic apps and adoption of containerized cloud-native application architectures was going to provide “a substantial market opportunity for policy and authorization to evolve.” A lot has happened since I wrote that, and I’m happy to report that while our Series A round showed the market opportunity, our latest round of funding proves the validity of t
Open Policy Agent, or OPA, is an open source, general purpose policy engine. OPA decouples policy decisions from other responsibilities of an application, like those commonly referred to as business logic. OPA works equally well making decisions for Kubernetes, Microservices, functional application authorization and more, thanks to its single unified policy language. So what’s a policy engine? And what’s policy? A policy can be thought of as a set of rules.
Kubernetes developers and platform engineers are typically under a metric ton of pressure to keep app deployments humming at a brisk pace. With the scale and power of Kubernetes, this can feel daunting. Maybe you’re a retailer launching a new e-commerce feature for a huge sale. Maybe you’re a bank that’s scaling a finance app worldwide. In either case, compromises always get made in the interest of speed and schedules.
