Transitioning to ABAC: Protect Your Data as You Move to the Cloud

As enterprises move their applications to the cloud, they’re adopting finer-grained authorization for their users in order to better secure architectures and applications. Today, many, if not most, organizations use a role-based access control (RBAC) model for secure access. But as the push for fine-grained control grows, many organizations are asking: should we transition to attribute-based access control (ABAC)? Not only can ABAC improve the security posture of an organization, for instance as part of a Zero Trust approach; but also, as developers are finding, the more automation and granularity they have supporting their access control, the less work and frustration they will encounter in the long term. For organizations that are considering ABAC, here’s what you need to know.

The power of ABAC is that it extends RBAC to provide finer-grained control over access. ABAC is a form of access control that allows users (aka subjects) to be associated with certain attributes, any combination of which can provide access to specified resources with similar attributes. These attributes often include roles, groups, location, security clearance and whether they are a system manager, among others. So, while an RBAC policy might specify that only users in engineering can access a particular service, an ABAC policy would specify additionally that only users who are in engineering, have a senior title and are currently on-call while located in New York can access the service.

One advantage of implementing ABAC is that it allows users to update any single object without breaking the entire system. Whereas developers of the past would have to update an entire stack to enforce new rules, ABAC allows policy to be authored and changed on the fly. Thanks to its flexibility, as well as the range of attributes one can use, ABAC is one of the most widely adopted forms of access control in the modern world, and is often the next step for organizations after RBAC.

With ABAC, organizations have the ability to:

With thousands of requests (or more) coming into a cloud environment every hour, running hands-on ABAC can be a large investment; but for scaling modern businesses, it is an investment worth making. One factor that has made it significantly easier to implement is policy as code (PaC). While RBAC can be implemented through PaC, it is ABAC that has benefited most from this new practice. ABAC is significantly more dynamic than its RBAC counterpart, and allows enterprises to externalize and automate enterprise access control policies.

As previously stated, ABAC can rely on any number of attributes, depending on the policy language used. Aside from these attributes, ABAC itself is fairly simple. All you need is to define a user, the action they can perform and the resources on which they can perform that action. The attributes are applied to the user and resources, and can be defined haowever you wish. For example, “only allow users access to resources that are located in the same geographic region.”

Additionally, ABAC is dynamic enough to allow new and existing users certain privileges without having to consistently reconfigure access control lists and user permissions. Instead, those pre-existing attributes, which can be applied when a new user is created, can carry all that weight themselves. For example, in an Application Entitlements architecture, if you want any user to be able to make read-only requests to non-resource paths, you could use the following ABAC policy:

{"apiVersion": "abac.authorization.kubernetes.io/v1beta1", "kind": "Policy", "spec": {"group": "system:authenticated", "readonly": true, "nonResourcePath": "*"}}
{"apiVersion": "abac.authorization.kubernetes.io/v1beta1", "kind": "Policy", "spec": {"group": "system:unauthenticated", "readonly": true, "nonResourcePath": "*"}}

These capabilities are allowing enterprises to expand to the cloud at high speeds without sacrificing any of their security capabilities. Since transitioning to the cloud is still a big lift for any organization to make, removing authorization from a DevOps team’s plate can be helpful.  Thus, in order to effectively operate at scale in a cloud environment, modern enterprises are turning to ABAC policy backed by code.

Now that we’ve gone over what ABAC is, let’s touch base on what you need to know before you’re ready to transition from RBAC (or some other form of access control) to an ABAC model. First, we’ll need three key components:

Once these three components are defined, all one has to do is write policies defining access capabilities between users and objects. Once that’s done, your authorization agent will automatically allow or deny requests to the aforementioned objects, allowing for automated authorization at scale.

Fulfilling these requirements is easier said than done, especially for an enterprise that is already dealing with thousands of clients and accounts moving around their environments on a daily basis. However, when ABAC is implemented, it is exponentially more scalable and efficient than its RBAC counterpart.

This is why enterprises are expanding to adopt ABAC at scale quickly, as those who adopt early will have a growing head start every day their competitors fail to do the same. Many enterprises are adopting and implementing open-source methods of ABAC authorization, such as Open Policy Agent (OPA).

OPA is an open-source project, but there are several enterprise options for its deployment. Styra Declarative Authorization Service (DAS) is a single pane of glass through which OPA can be managed at scale, whether you have 10 instances or hundreds. OPA itself uses its unique declarative policy language, Rego. This language is flexible enough to express RBAC, ABAC or any flavor of policy that your organization requires, while still remaining one of the most secure PaC methods available.

In part due to its declarative nature, Rego policies excel at expressing policy as code. OPA, when acting as the Policy Decision Point (PDP), can be deployed in several different architectural patterns, although it will commonly be deployed as a sidecar through which all requests must pass. This ease of deployment only further benefits an ABAC approach, as flexibility is one of the keys to cloud-based growth.

ABAC can be used in effectively every use case of Styra DAS, from enabling Kubernetes guardrails to enforcing cloud-native Entitlements, which can use ​​JWT tokens or metadata to allow for even more granular authorization policies. All of this is achievable while maintaining easily navigable decision logs, GitHub repository integration and the ability to translate tier0 data sources into code readable by OPA.

Altogether, Styra DAS is a dynamic option for managing OPA at scale. As such, it is being implemented by various enterprises across the globe as they expand to a cloud-native approach. 

Want to give Styra DAS a try? Try it for yourself for free! Alternatively, if you want to learn more about Styra DAS, OPA, and its custom policy language Rego, vist the Styra Academy or the Rego Playground.