How OPA helps enterprises manage authorization and maintain compliance in the cloud

Dec. 10, 2021
Cloud environments are too vast and dynamic to address with traditional authorization approaches

Hosting and developing services on the cloud helps companies achieve high uptime, fast updates, global availability and other benefits. Yet, storing data over the internet expands an organization's attack surface, creating a higher risk of non-compliance and security breaches.

Authorization — ensuring users and applications only have access to the systems they need — is key to addressing stricter compliance regulations and more frequent security breaches. However, traditional, legacy authorization techniques don’t provide the granularity or nuance required in a cloud environment.

Organizations should consider modern authorization solutions that are purpose-built for a cloud-native tech stack. Open Policy Agent (OPA) augments the creation, management and governance of authorization policy. OPA can help enterprises become cloud-first while still maintaining a strong and compliant security posture.

Authorization is Complex in Cloud Environments

The number of integrations and connections between systems is expanding as organizations increasingly adopt cloud technologies and shift to cloud-native software development. As more entities interact with the enterprise’s systems, controlling access is crucial to ensure compliance, prevent security breaches, and privilege escalation.

But authorization can be difficult to execute in the cloud. In legacy, on-premise environments, controlling access was simple because companies only managed a few disparate systems. But in a cloud-based environment, there are more discrete components that require their own unique authorization policy configurations.

Today, the average business uses more than 600 applications and hundreds (sometimes even thousands) of application programming interfaces (APIs), rendering the scaling, managing and tracking of authorization especially complex and time-consuming.

Additionally, traditional access control measures like single-sign-on, SAML, OIDC and OAuth2 don’t provide the level of granularity that’s essential to implement and secure authorization among core components of a cloud-native stack. Whenever access policies need to be changed or audited, engineers must use a variety of APIs, graphical user interfaces (GUIs) and authorization models. Manual authorization efforts are not only time-consuming, but they open the door to human error — like miswritten code that creates opportunities for system vulnerabilities.

Many providers offer their own proprietary solutions that enable authorization in specific cloud environments. But these solutions are often incompatible with other policy frameworks the enterprise may be using, creating an inconsistent policy environment that is difficult to control. This requires users to learn multiple authorization systems, each with its own API, GUI and authorization model, which can be time-consuming and confusing for developers.

OPA — the open-source, domain-agnostic policy engine — provides a unified approach to create, enforce and manage authorization policies across a cloud-native tech stack. OPA is highly flexible and technology-agnostic, which makes it fast, lightweight and easily integrated across systems. OPA helps reduce the possibility of human error and streamlines compliance efforts.

3 Benefits of Open Policy Agent (OPA)

OPA simplifies policy creation and governance authorization in the cloud, circumventing many of the pitfalls caused by manual authorization efforts and commercial authorization solutions. The following are some of the primary benefits of OPA:

    1. Unified approach promotes authorization across systems. OPA creates a single standard for policy that allows architects, engineers and developers to define and control access across multiple diverse apps and infrastructures. Policies are written in Rego, which is a purpose-built language for expressing policies over complex hierarchical data structures. The language is flexible enough to encode a wide variety of authorization models, helping meet every organization’s unique needs. OPA can enforce policies in microservices, Kubernetes, CI/CD pipelines, API gateways and more.
    2. Open-source community offers a range of policies. When I co-founded Styra, my colleagues and I immediately started creating OPA in 2016 and subsequently donated it to the Cloud Native Computing Foundation (CNCF) in 2018. The project reached graduation status earlier this year and is currently being used by industry leaders like Netflix, Pinterest and Goldman Sachs. Since OPA is open source, the infrastructure is informed by experts around the world and covers a wide range of policies and software integrations that wouldn’t be possible if produced by only one team. Furthermore, this flexible structure fosters collaboration by allowing community members to learn from one another and uplevel their skills. 
    3. Policies are flexible and separate from architecture. OPA also decouples policy logic from service proxies, so developers don’t need to hardcode rules into the app services or any individual proxies. Instead, developers are able to read, write, analyze, distribute and manage policy without changing the application architecture itself. Decoupling policy reduces the likelihood of bugs or errors and simplifies the process of making authorization policy changes. Additionally, OPA is flexible enough to run as a command-line interface (CLI), library, sidecar, daemon or centralized service which helps implement policy decoupling regardless of the architectural requirements.

Thanks to the open-source community contributions and OPA’s unified approach, this solution has become the de-facto standard for authorization and compliance. But like any technology, deployment still requires due diligence and concentrated effort to get off the ground.

The 3 Building Blocks of OPA Deployment

Since OPA is technology-agnostic, it’s not necessary to have built-in connectors, rules or database frameworks. Instead, OPA can work with any system by considering the authorization scenario’s context, evaluating it against relevant rules and returning policy decisions. However, this flexibility also means that OPA must be carefully configured for each organizations’ unique technology setup.

 OPA requires three key components to make authorization decisions which are broken down for you below:

  1.  Integration with enforcement APIs: OPA evaluates contextual data and provides decisions based on policy, but it does not enforce those policies. To achieve enforcement, you must integrate OPA as an external authorization webhook. OPA easily integrates with other software systems (especially those that are cloud-native) including gateways, service meshes, container orchestrators and CICD pipelines. This cohesion allows OPA to offload authorization decision-making and achieve the necessary availability to retrieve those decisions.
  2. Business logic: Business logic determines what authorization requests should be allowed or denied. To make a policy decision, OPA needs to be told how to evaluate the context of an authorization request by the business logic itself. Rego, a declarative language, facilitates turning the logic into codified policy, meaning policy authors can focus on what policy should do, rather than how that policy needs to be written. Think of your first policy as an exercise in pattern-matching. Here’s an example of how a policy in Rego could be written: The only people that can access production clusters must be full-time, currently on-call employees and have checked code into that cluster.
  3.  Contextual data: OPA also requires contextual data to make policy decisions. OPA can use any structured data, from any system to evaluate policies — like a list of on-call engineers or whether a database column contains PII. All that’s required is the ability to present relevant data to OPA, which can be done by either pushing data from relevant systems or having OPA query those systems as needed. In our example above (see point two “Business logic”), OPA would need access to who is on call (from software like Pager Duty) who is a full-time employee (from Workday) and who has checked code into production (from Github). You can use any system as OPA is purpose-built to sort through unrelated data from various sources to evaluate policy decisions.

Scaling Authorization to Focus on Innovation

Cloud environments are too vast and dynamic to address with traditional authorization approaches. As companies embrace cloud and cloud-native development strategies, OPA can help teams scale authorization, maintain compliance and enhance security. By using technology to streamline policy-based controls, organizations can spend less time on proof of compliance and manual policy development and more time on innovation.

About the author: Tim Hinrichs is the Co-Founder and CTO at Styra, a leader in cloud-native authorization-based in Redwood City, Calif.