Digital transformation is no longer the exclusive domain of forward-thinking companies on the leading edge of technological advancement. It has become a cost of entry into competitive business. Digital transformation was already accelerating into the mainstream prior to the pandemic, but the jarring shift to remote and hybrid work put fuel in the proverbial jetpacks.

Before the rise of cloud computing and small autonomous services built with containers, a typical application would consist of a monolith of code with a frontend, a backend and a database. Developers would take extra caution when updating their code because any change or bug could affect the entire application. As an alternative, microservices broke down applications into small interconnected services — each responsible for their discrete function, collaborating using APIs.

If you’ve been paying attention to trends in access control, then you’ll likely have come across the terms Role-Based Access Control (RBAC) and Attribute-Based Access Control (ABAC). Both have years of precedent in the field of access control, and both are used to great effect across nearly every market in the world.

Testing the relatively new function mocking feature of OPA revealed a vulnerability in the Go API, where the use of the WithUnsafeBuiltins function on the compiler object — a deprecated legacy function used to declare a set of function names as unsafe, and as such rejected in the policy compilation stage — could be bypassed by mocking a function, effectively replacing it with one of the functions deemed unsafe.

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.