Kubernetes (K8s) has achieved undeniable mainstream status, with 96% of organizations currently evaluating or already using this technology, according to the Cloud Native Computing Foundation (CNCF). This popularity also brings growing scrutiny over Kubernetes compliance standards and audits, in light of how Kubernetes and cloud native technologies demand a very different approach to security.
There are unquestionable advantages to cloud native technologies, but significant challenges as well. Case in point: microservices authorization. Microservices have, for many companies, become the architecture of choice for cloud native apps — whether for migrating legacy apps or building new cloud native applications.
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.
