It’s been a great year so far for the Open Policy Agent (OPA) project and community. OPA achieved graduated status in the Cloud Native Computing Foundation (CNCF) in February and is quickly nearing 100 million downloads! With all this growth, we were excited to see the results of the second annual Open Policy Agent user survey. As I mentioned in my post on the Open Policy Agent blog, we survey the community to help better steer the project's long-term roadmap in the right direction.

Not only has cloud native transformed the velocity in which organizations execute and maintain business operations, but it has also redefined storage, network and compute. From the infrastructure that IT operations maintains, to the applications that supply customers with the ability to interact with their data—DevOps teams have to deliver more services than ever, and they have to do it fast, with little to no error. Easy, right?

Cloud native tooling for authorization is an emerging trend poised to revolutionize how we approach this oft-neglected part of our applications. Open Policy Agent (OPA) is the leading contender to become a de-facto standard for applying policies to many different systems — from workloads running on Kubernetes to requests passing through Istio.

Open Policy Agent (OPA) is rapidly becoming a cornerstone in the management and maintenance of secure and compliant systems that align with industry and organizational best practices. As more organizations begin — or continue — their cloud-native digital transformation, the importance of policy-as-code only increases. Sometimes, though, becoming an expert in yet another tool or language isn’t in the cards.

The Kubernetes community created a feature in v1.10 called Pod Security Policy (PSP) to control the security-related fields for pods defined in your Kubernetes cluster. Now that PSP is being deprecated in Kubernetes v1.21, what should you do to secure your Kubernetes cluster? In this blog, we’ll learn a bit about PSP, explore why it’s being deprecated and how Open Policy Agent (OPA) can ease the migration from PSP.

The shift to cloud-native has transformed the way organizations do business, keep up with the competition and meet the demands of customer expectations. From the infrastructure that maintains IT operations to the applications that supply customers with the ability to interact with their data, the velocity in which DevOps teams have to deliver these services has significantly increased, leaving little to no room for error.

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.