We’ve had an exciting past six months at Styra, from a Series A funding announcement to tremendous growth in the Open Policy Agent (OPA) community to new enhancements to our commercial product, Styra’s Declarative Authorization Service (DAS). All of this great momentum maps to our overarching vision of unifying authorization and policy for the cloud-native environment.
Talks focused on Open Policy Agent (OPA) are featured prominently in the agenda for KubeCon + CloudNativeCon Europe—15 OPA-focused sessions were accepted from users at Google, City of Ottawa, Ada Health and more—signaling the importance of authorization in the cloud. While the event and those talks are now on hold until August, that doesn’t mean we should postpone learning more about authorization within applications, across Kubernetes clusters and on top of service mesh.
It’s clear from the latest Cloud Native Computing Foundation survey that containerized environments have become mainstream, increasing automation at scale for companies. But, in the cloud-native environment, changes are constant and runtime is extremely dynamic. And while automation can help eliminate manual work, it can also replicate mistakes and risk at cloud scale.
Why the cloud-native architecture required a new policy language I recently started a new series on the Open Policy Agent (OPA) blog on why Rego, OPA’s policy language, looks and behaves the way it does. The blog post dives into the core design principles for Rego, why they’re important, and how they’ve influenced the language. I hope it will help OPA users better understand the language, so they can more easily jump into creating policy of their own.
The results are in! The Cloud Native Computing Foundation (CNCF) seventh annual survey was recently released, showing that cloud-native technologies have become mainstream, and that deployments are maturing and increasing in size. This cloud-native shift means developers can more easily build complex applications, and organizations can deploy and manage these applications more quickly and with more automation than ever before. Don’t have time to read the whole thing? We’re here for you.
The RSA Conference—”Where the World Talks Security”—begins today. It’s a perfect time to take a hard look at security, and to investigate new solutions that help us all stay ahead of attacks and minimize risks. The team from Styra and Open Policy Agent will be there—eager to discuss advances in security for the cloud-native world.
As enterprises adopt cloud-first or cloud-native strategies, Kubernetes is by far the most important strategic consideration. At the same time, for the large subset of these enterprises which take payment from consumers, PCI DSS has never been more critical. More than ever, enterprises have to pay attention to data security (and their commitment to improving security posture) in order to meet compliance requirements. So what has to change to meet compliance in a Kubernetes-based environment?
This week, I'm pleased to announce that we closed our $14M Series A financing round. We look forward to partnering with our new investor, Accel, who led the round alongside existing investors, Unusual Ventures and A.Capital. Accel's Eric Wolford will join our board, bringing a wealth of open source experience from Heptio, SysDig and Corelight.
As Kubernetes matures and moves from exploration into production, we on the Styra and Open Policy Agent teams are starting to hear of a new trend. It’s part of any kind of operational lifecycle for many companies and it goes something like this: DevOps: Our Kube environment is performant, secure, and compliant by design! Auditor: K. Walk me through every line of code you typed since time began.
When NIST (https://nvd.nist.go) announces a new CVE (Common Vulnerability and Exposure) that impacts Kubernetes, kube administrators and IT Security teams need to quickly understand the impact of the vulnerability and protect their Kubernetes clusters. Often, no patches are yet available, so in addition to understanding the impact, DevOps teams have to decide whether or not to create a custom fix to mitigate the risk of that CVE without bringing down the entire app or system.
