Security | Threat Detection | Cyberattacks | DevSecOps | Compliance

June 2021

The Open Policy Agent Journey from Sandbox to Graduation

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.

Styra blends flexible integration and policy-as-code framework for Capital One

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.

Getting Open Policy Agent Up and Running

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.

K8s Admission Control vs RBAC

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.