We just enhanced Styra Declarative Authorization Service (DAS) with a feature customers have been asking for: near-instant scanning of policy-as-code config files right in GitHub. …Oh, and as a bonus, it’s free, it’s available now and it only takes a couple minutes to see live in-action in your repos!

Modern microservices applications built using containers are complex — often requiring complex authorization solutions, due to the sheer number of access possibilities involved. Indeed, as IT infrastructure has migrated to the cloud, along with the applications running on it, security and privacy concerns have only increased. As microservice applications became ubiquitous, open-source authorization tools have come to the fore for many organizations.

The Rego policy language is the backbone of Open Policy Agent (OPA), the policy enforcement tool that helps simplify cloud-native development at scale. With OPA Rego policy, the result is a reduced manual authorization burden, improved accuracy, and quicker time to market. But yes, there’s a learning curve, which makes Rego a main barrier to using OPA. You might be hesitant about the time investment needed to learn a new, highly specified language.

Securing your Kubernetes environments may seem daunting at first, given how many different parts must be individually protected. Still, with the proper organization, you can make Kubernetes security much simpler and more effective. We’ve put together a complete Kubernetes security checklist of best practices and security recommendations to help you keep track of your progress. To make this a little easier, we’ve divided this checklist into the following sections.

Open Policy Agent, or OPA, has emerged as an industry standard for cloud-native authorization and policy as code. From 2018 to now, it has grown from being a Cloud Native Computing Foundation (CNCF) sandbox project into a fully mature, graduated CNCF project, deployed by many of the largest organizations in the world. (For just the tip of the iceberg, here is a list of users who have made their adoption of OPA public).

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.