Security | Threat Detection | Cyberattacks | DevSecOps | Compliance

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.

Picture this: unfortunately you had to let one of your engineers go. No matter how many times you tried to tell them, after countless interventions and meetings with the engineering lead, they simply wouldn’t stop using tabs instead of spaces. An absolutely unforgivable offense. A few weeks later, suddenly your production Snowflake database is wiped out. You log on to assess the damages and you check the SNOWFLAKE.ACCOUNT_USAGE.QUERY_HISTORY for every user in the system.

The proliferation of third-party software components such as open source software(OSS) has triggered a growing need to keep track of it all. Why? Because when security vulnerabilities inevitably crop up in open source components, it’s pretty important to know whether your company uses that piece of code – or whether it appears in the myriad software dependencies inherent in open source.