Styra Academy, our online training portal for free courses on OPA, Rego and Styra Declarative Authorization Service (DA), has a new course available: OPA Performance. The primary purpose for OPA within applications is, of course, fine-grained authorization — that is, who can do what and what can do what. Each user request typically requires one or more authorization decisions to be made.
I’m excited to announce the Styra DAS integration with HashiCorp Terraform Cloud via run tasks is now generally available to Styra DAS users! Users can now enforce cloud resource policy guardrails at every step of the DevOps process, including right before Terraform Cloud applies changes to your cloud resources.
Rego is the purpose-built declarative policy language that supports Open Policy Agent (OPA). It’s used to write policy that is easy to read and easy to write. Fundamentally, Rego inspects and transforms data in structured documents, allowing OPA to make policy decisions. Rego was originally inspired by Datalog, a common query language with a decades-long history, but extends its capabilities to support structured document models like JSON.
An OPA design pattern, as detailed in a previous post, gives you an architectural solution to solve one or more common policy problems. In this blog post, we describe what we call the Offline Configuration Authorization design pattern for OPA. Remember that each OPA design patterns covers the following information.
Enterprises are shifting rapidly to the cloud in order to increase scalability, improve efficiency and lower their costs. In the process, every company has become a software company — constantly building and updating new software — while the cloud has radically transformed how software is built. Oftentimes, the modern cloud-native application will be made up of several (or hundreds of) microservices, while being hosted on dynamic scaling platforms like Kubernetes.
Most enterprises are well on their way towards a cloud operating model. Many have moved significant parts of their applications to one (or more) public clouds. Yet, many resources will never be destined for a central public cloud — and for good reason. We now see two factors that affect where and how many resources will ultimately be deployed (hint: it’s at the edge).
In the past, responsibility for data privacy and security fell on non-development teams, like IT, security or compliance. But this is changing. Thanks to the adoption of cloud native technologies and trends like policy-as-code, developers are more focused on security than ever. According to the Styra 2022 Cloud-Native Alignment Report, over half of developers think their organization should enhance its data privacy efforts in the next 12 months.
We’re excited to be included in the first Policy Based Access Management (PBAM) market report! The KuppingerCole Analysts AG’s 2022 Market Compass provides an excellent overview of how the access market is transforming and emerging vendors in the space.
Organizations today are embracing cloud-native technologies to increase time-to-market, scalability and cost savings. A big part of the cloud-native transition is moving legacy systems and architectures to the cloud. With this comes both complexity and new risks because modern applications are often composed of dozens of microservices, housed in containers and hosted on immutable, dynamically scaling platforms like Kubernetes.
Styra Academy, our online training portal for free courses on OPA, Rego, and Styra Declarative Authorization Service, has a new course available - Microservice Authorization! Before diving in, let’s get a better understanding of microservices and some of the authorization challenges developers need to consider. Microservices are everywhere — and securing them presents a unique set of challenges.
