If you’re responsible for a microservices app, you may be familiar with the idea of a “latency budget.” This is the maximum latency, measured as total request time, that you need for the app to work, in order to meet your SLAs and keep stakeholders happy. For a stock trading or financial services app, this budget might be the barest of microseconds.
Bridging the gap between Security, Compliance and DevOps teams can be a challenging cultural shift to address. DevOps teams are eager to get software out faster and more efficiently, yet security best practices, like policy-as-code, need to be integrated from the outset to streamline the development process in this new cloud-native world.
A question that comes up every now and then is whether it’s possible to compose policies based on dynamic attributes provided with the request when querying Open Policy Agent (OPA) for decisions. Could we for example provide a group, team or role name as part of the input and have OPA evaluate all policies provided for that group, team or role, but no additional policies other than those? Imagine you have several teams in an organization, each of them with their own responsibilities.
Whether you’re just starting to understand basic Rego language concepts or want to brush up on structuring policy-as-code rules, Styra Academy’s “OPA Policy Authoring” course lays out the fundamentals you need to know to get started. Before we dive in, let’s get a better understanding of Open Policy Agent (OPA) and some common use cases. OPA is an open source, general purpose policy engine for cloud native environments.
As part of Styra’s vision for unified authorization, we founded the Open Policy Agent project (OPA) to make policy-based control of the cloud-native stack accessible to everyone. OPA has now grown to become the de facto standard for authorization across the stack, leading to a large part of the community looking for ways to manage the OPA policy-as-code lifecycle.
This post is going to outline some basics, interesting tidbits and caveats on unit testing Rego policies.
Open Policy Agent (OPA), now a graduated project from the Cloud Native Computing Foundation, has become the open-source tool of choice for millions of users, who leverage it as a standard building block for policy and authorization across the cloud-native stack. Given the flexibility of OPA — with practically limitless deployment options — it has been adopted for dozens of use cases across hundreds of companies.
One of my absolute favorite aspects of Open Policy Agent (OPA) is the general purpose nature of the tool. While commonly seen in deployments for Kubernetes admission control or application authorization, the large OPA ecosystem includes integrations with anything from databases, and operating systems to test frameworks and REST clients for most common languages.
In this pandemic-defined era of rapid retail transformation, the digital shopping experience has become tantamount to the success of the business. As a result, retailers have redoubled their efforts to improve digital applications and services.
Devops teams are flocking to GitOps strategies to accelerate development time frames and eliminate cloud misconfigurations. They should adopt a similar ‘as-code’ approach to policy. One risk in deploying fleets of powerful and flexible clusters on constantly changing infrastructure like Kubernetes is that mistakes happen. Even minute manual errors that slip past review can have substantial impacts on the health and security of your clusters.
