The Open Policy Agent is used for policy decision-making across the stack. In the case of Kubernetes, it is often used as an admission controller to protect the API Server with dynamic rules that don’t require recompilation to introduce. Today on the InfoQ Podcast, Wes Reisz speaks with Tim Hinrichs and Torin Sandall (two of the Open Policy Agent Project creators). The three talk about the project, including things like architecture, origin, community, the policy language (Rego), and, of course, performance. The podcast is an introduction to how OPA can is used across the stack for policy decisioning
- OPA’s responsibility is to make a policy decision on its own and return that decision as a JSON object back to the caller. It’s up to the caller to decide what to do with the OPA decision. Semantically, OPA only operates on the data passed to it (typically as JSON). So OPA doesn’t require deep knowledge about the environment itself. This makes OPA flexible and portable to many different use cases.
- Rego is a high-level declarative language that’s based on decades of research into policy systems. It embodies specific ideas that make it useful for these kinds of more modern cloud-native systems and is designed like a onion. There are core parts of the language that are extremely fast. As you need more expressiveness, you move up the performance curve.
- OPA is most often used as an admission controller in Kubernetes. An admission controller is where all the semantic validation of Kubernetes resources occur before resources are persisted to etcd and controllers go off and start doing work.
#the infoq podcast #kubernetes #software development #performance #architecture & design #podcast