Zendesk Engineering consists of many teams that own a large number of different domains, ranging from engineering teams that built internal services to teams that work on our various product offerings. One concern that these teams have in common is controlling access to their APIs via fine-grained policies. Some APIs are only available to admins, others to users with a specific set of permissions and some APIs restrict access based on attributes of the data being accessed.

Open Policy Agent (OPA) can be a mighty tool for users looking to embrace a policy-as-code approach to authorization. However, learning to decouple policy decisions from your applications with OPA can be a challenge on its own — not to mention deploying and managing those OPA instances at scale.

With the growing importance of cloud-native security and zero-trust approaches to software, questions around the level of access granted to cloud resources have become more critical. Equally important is to understand the value of different authorization strategies. In this article, we present an overview of fine-grained and coarse-grained authorization methods.

XACML is an OASIS standard for implementing declarative authorization policy. It was intended to be a widely adopted technology that would move authorization policy decisions out of application code and into a specialized Policy Decision Point (PDP). The terms often used in the OPA world, such as PDP, PIP (Policy Information Point) and PEP (Policy Enforcement Point) all come from the XACML standard. You can read more about XACML in Anders Ecknert’s blog post on architecting authorization.

In Tim Hinrich’s prior blog titled the Three-Body Problem for Policy, he dives into the interconnected relationship between policy, data and software. He identifies a key consideration when using OPA — that “policies can only be evaluated when provided with the correct data.” The full blog is well worth the read to better understand the role of data and its correctness in your policy implementation.

Open Policy Agent (OPA) is widely used to provide security and compliance policy guardrails for Kubernetes. The built-in role-based access controls in Kubernetes are not sufficient for fine-grained policy. OPA is a proven solution for implementing strong, granular policy checks for cluster resources during Admission Control. OPA users implement fine-grained policy in the form of rules written in Rego, the declarative policy language of OPA.

The shift from monolithic architectures to microservices poses complex authorization challenges to development teams. In this article, we look at how to enforce fine-grained access control in cloud-native environments as we make a case for a dynamic approach to authorization in microservices. Key takeaways.

Kubernetes (K8s) and its expansive ecosystem of cloud-native technologies have revolutionized the way applications are built and run. While the adoption of Kubernetes has opened the door to big gains in business agility, scalability and efficiency, it also introduces complex new security challenges that affect platform engineers and developers alike.

Modern SaaS applications power the world’s most iconic businesses, and with hundreds of billions of dollars of annual revenue at stake, speed to market without compromising secure operation and access control is essential. Authorization for multi-tenant SaaS applications enables end-users to control ‘who’ and ‘what’ can interact with the application.