How to implement RBAC with API Gateway and OPA

Currently, in order to ensure that the right people can access the right resources, we need to enable appropriate access control methods for the system. However, facing various well-known implementation models, building an API authorization system for its backend services is often a big challenge. In this article, we will discuss how to use the open source API gateway - Apache APISIX ( https://apisix.apache.org/ ) and Open Policy Agent (OPA, https://www.openpolicyagent.org/docs/latest/ ) to enable role-based access control (RBAC) authorization model for your API.

What is RBAC?

Role-based access control (RBAC, https://en.wikipedia.org/wiki/Role-based_access_control) and attribute-based access control (ABAC, https://en.wikipedia.org/wiki/Attribute-based_access_control) are two of the most commonly used access control models for managing permissions and access to resources in computer systems. Typically, RBAC assigns permissions to users based on their roles and responsibilities in an organization.

That is, in RBAC, roles are defined based on the functions or responsibilities of users, and corresponding permissions are assigned to these roles. Of course, in actual operations, we often assign one or more roles to users so that they inherit the permissions associated with these roles. For example, in the context of APIs, the developer role may have the permission to create and update API resources, while the end-user role only has the permission to read or execute API resources. Moreover, in RBAC, policies are defined by a combination of factors such as the roles assigned to users, the operations they are authorized to perform, and the resources they need to perform the operations. If RBAC assigns permissions based on user roles, then ABAC assigns permissions based on the attributes associated with users and resources.

What is OPA?

As a policy engine and a set of tools, OPA provides a unified approach to enforcing policies across distributed systems. It allows developers to centrally define, manage, and enforce policies from a single endpoint. By defining policies as code, OPA can easily review, edit, and rollback policies, facilitating efficient policy management.

As shown in the figure above, OPA provides a declarative language called Rego (https://www.openpolicyagent.org/docs/latest/policy-language/). It allows you to create and implement various policies throughout the technology stack. When you request a policy decision from OPA, it uses the rules and data you provide in the file to evaluate the query and generate a response, and then sends the result of the query back to you as a policy decision. Because OPA stores all the policies and data it needs in its internal cache, it can return results quickly. The following is an example of a simple OPA Rego file:

 package example default allow = false allow { input.method == "GET" input.path =="/api/resource" input.user.role == "admin" }

As shown in the code snippet above, we have a package called "example" that defines a rule called "allow". This rule specifies: if the input method is "GET", the requested path is /api/resource, and the user role is "admin", then the request is allowed. That is, if these conditions are met at the same time, the "allow" rule evaluates it to "true", allowing the request to proceed.

Why use OPA and API Gateway for RBAC?

The API Gateway provides a centralized location to configure and manage APIs and their consumers. As a centralized authentication gateway, it effectively avoids having each individual service implement authentication logic within it. On the other hand, OPA separates policy from code by creating a separate authorization layer for authorization. With this combination, you can add permissions for API resources to roles, and then define a set of permissions (GET, PUT, DELETE) for RBAC resources (defined by URI path) for each user role. In the next section, we will learn how to implement RBAC using both.

How to implement RBAC with OPA and Apache APISIX

In Apache APISIX, you can define the behavior of your API by configuring routes (https://apisix.apache.org/docs/apisix/terminology/route/) and plug-ins (https://apisix.apache.org/docs/apisix/terminology/plugin/). Specifically, you can use the APISIX OPA plug-in (https://apisix.apache.org/docs/apisix/plugins/opa/) to enforce RBAC policies by forwarding requests to OPA for decision making. In other words, OPA makes authorization decisions in real time based on the user's role and permissions.

Assume we have a Conference API (https://conferenceapi.azurewebsites.net/) where you can retrieve/edit active sessions, topics, and speaker information. In terms of authorization, speakers can only read their own sessions and topics, while administrators can add/edit more sessions and topics. Moreover, attendees can leave their feedback on the speaker's session via POST request to the /speaker/speakerId/session/feedback path, while the speaker can only see it by requesting the GET method of the same URI. The following figure shows the whole scenario:

1. The API consumer uses its credentials (e.g., JWT token in the Authorization header, https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Authorization) to request a route on the API Gateway.

2. API Gateway sends the consumer data with the JWT header to the OPA engine.

3. OPA uses the policies (i.e. roles and permissions) that we specified in the .rego file to evaluate whether the user has permission to access the resource.

4. If OPA decides to allow, the request will be forwarded to the upstream Conference service.

Next, we will install and configure APISIX and define various policies in OPA.

Prerequisites

• Docker (https://docs.docker.com/get-docker/) for installing containerized etcd and APISIX.
• Curl (https://curl.se/) is used to send requests to the APISIX Admin API. Of course, you can also use tools such as Postman (https://www.postman.com/) to interact with the API.

Step 1: Install Apache APISIX

APISIX can be easily installed and quickly started using the following script:

 curl -sL https://run.api7.ai/apisix/quickstart | sh

Step 2: Configure the backend service (upstream)

In order to route requests to the backend service of the Conference API, you need to add an upstream server to configure it in Apache APISIX through the Admin API (https://apisix.apache.org/docs/apisix/admin-api/). See the following code:

 curl http://127.0.0.1:9180/apisix/admin/upstreams/1 -X PUT -d ' { "name":"Conferences API upstream", "desc":"Register Conferences API as the upstream", "type":"roundrobin", "scheme":"https", "nodes":{ "conferenceapi.azurewebsites.net:443":1 } }'

Step 3: Create an API consumer

Next, we create a consumer (i.e., a new speaker) in Apache APISIX with the username Jack and set up the jwt-auth ( https://apisix.apache.org/docs/apisix/plugins/jwt-auth/ ) plugin for the consumer with the specified key so that the consumer uses JSON Web Token ( JWT , https://jwt.io/ ) for authentication. See the following code:

 curl http://127.0.0.1:9180/apisix/admin/consumers -X PUT -d ' { "username": "jack", "plugins": { "jwt-auth": { "key": "user-key", "secret": "my-secret-key" } } }'

Step 4: Create a public endpoint to generate a JWT token

You also need to set up a new route that uses the public-api ( https://apisix.apache.org/docs/apisix/plugins/public-api/ ) plugin to generate and issue tokens. At this point, the API Gateway will act as an identity provider server to verify the token created and verified by the user Jack 's key. Of course, the identity provider can also be any third-party service such as Google ( https://developers.google.com/identity ), Okta (https://www.okta.com/), Keycloak ( https://www.keycloak.org/ ) and Ory Hydra ( https://www.ory.sh/hydra/ ). See the following code:

 curl http://127.0.0.1:9180/apisix/admin/routes/jas -X PUT -d ' { "uri": "/apisix/plugin/jwt/sign", "plugins": { "public-api": {} } }'

Step 5: Request a new JWT token for the API consumer

Now, we can use the public endpoint we created to get a new token for Jack from the API Gateway. The following curl command generates a new token using Jack's credentials and assigns the roles and permissions in the payload.

curl -G --data-urlencode 'payload={"role":"speaker","permission":"read"}' http://127.0.0.1:9080/apisix/plugin/jwt/sign?key=user-key -i

After running the above command, you will receive a new token in response. Let's save this token somewhere so that we can use it later to access the new API Gateway endpoint.

Step 6: Create a new plugin configuration

This step involves configuring three APISIX plug-ins: proxy-rewrite ( https://apisix.apache.org/docs/apisix/plugins/proxy-rewrite/ ), jwt-auth ( https://apisix.apache.org/docs/apisix/plugins/jwt-auth/ ) and OPA ( https://apisix.apache.org/docs/apisix/plugins/opa/ ). Please see the following code:

 curl "http://127.0.0.1:9180/apisix/admin/plugin_configs/1" -X PUT -d ' { "plugins":{ "jwt-auth":{ }, "proxy-rewrite":{ "host":"conferenceapi.azurewebsites.net" } } }'

• The proxy-rewrite plugin is configured to proxy all requests to the conferenceapi.azurewebsites.net host.
• The OPA authentication plugin is configured to use the OPA policy engine running on http://localhost:8181/v1/data/rbacExample . In addition, APISIX sends all the information related to the user to OPA. We need to add the .rego file in the configuration section of OPA.

Step 7: Create a route for the Conference session

The last step is to create a new route for the speaker session of the Conferences API:

 curl "http://127.0.0.1:9180/apisix/admin/routes/1" -X PUT -d ' { "name":"Conferences API speaker sessions route", "desc":"Create a new route in APISIX for the Conferences API speaker sessions", "methods": ["GET", "POST"], "uris": ["/speaker/*/topics","/speaker/*/sessions"], "upstream_id":"1", "plugin_config_id":1 }'

The above payload contains route information such as name, description, method, URI, upstream ID, and plugin configuration ID. In this example, the route is configured to handle GET and POST requests to two different URIs (/speaker/topics and /speaker/sessions). The "upstream_id" field specifies the ID of the upstream service that will handle incoming requests for this route, while the "plugin_config_id" field specifies the ID of the plugin configuration that will be used for this route.

Step 8: Test the setup without OPA

So far, we have set up all the necessary configuration for APISIX to direct incoming requests to the various endpoints of the Conference API and only allow those API consumers who have been authorized to use it. According to this, every time an API consumer needs to access an endpoint, they must provide a JWT token to retrieve data from the Conference backend service. You can verify this by hitting the endpoint. Here, the domain address we are requesting is the custom API gateway, not the actual Conference service:

 curl -i http://127.0.0.1:9080/speaker/1/topics -H 'Authorization: {API_CONSUMER_TOKEN}'

Step 9: Run the OPA service

Next, we use Docker to run the OPA service and upload our policy definition using its API, which can be used to evaluate the authorization policy for each incoming request.

 docker run -d --network=apisix-quickstart-net --name opa -p 8181:8181 openpolicyagent/opa:latest run -s

The above Docker command starts a container with the latest version of the OPA image. It creates a new container named OPA on the existing APISIX network apisix-quickstart-net and exposes port 8181. Therefore, APISIX can directly use the address -- [http://opa:8181]( http://opa:8181 ) to send policy check requests to OPA. Note that OPA and APISIX should run in the same Docker network.

Step 10: Define and register policies

The next step on the OPA side is to define the policies that will be used to control access to the API resources. These policies should define the attributes required for access (e.g. which users have which roles), and the permissions allowed or denied based on these attributes (e.g. which roles have which permissions). For example, in the configuration below, we ask OPA to check the table user_roles to find the role Jack. This information is sent by input.consumer.username inside APISIX. We use this to verify the user's permissions by reading the payload of the JWT and extracting token.payload.permission from it. The following comments clearly describe these steps.

 curl -X PUT '127.0.0.1:8181/v1/policies/rbacExample' \ -H 'Content-Type: text/plain' \ -d 'package rbacExample # Assigning user rolesuser_roles := { "jack": ["speaker"], "bobur":["admin"] } # Role permission assignments role_permissions := { "speaker": [{"permission": "read"}], "admin": [{"permission": "read"}, {"permission": "write"}] } # Helper JWT Functions bearer_token := t { t := input.request.headers.authorization } # Decode the authorization token to get a role and permission token = {"payload": payload} { [_, payload, _] := io.jwt.decode(bearer_token) } # Logic that implements RBAC default allow = falseallow { # Lookup the list of roles for the user roles := user_roles[input.consumer.username] # For each role in that list r := roles[_] # Lookup the permissions list for role r permissions := role_permissions[r] # For each permission p := permissions[_] # Check if the permission granted to r matches the users request p == {"permission": token.payload.permission} }'

Step 11: Update the existing plugin configuration with the OPA plugin

Once the policies are defined on the OPA service, we need to update the existing plugin configuration so that the routes use the OPA plugin. As shown in the following code snippet, we need to specify it in the policy property of the OPA plugin.

 curl "http://127.0.0.1:9180/apisix/admin/plugin_configs/1" -X PATCH -d ' { "plugins":{ "opa":{ "host":"http://opa:8181", "policy":"rbacExample", "with_consumer":true } } }'

Step 12: Test the setup using OPA

At this point, we can test all the settings using OPA policies. Once you run the following curl command to access the API Gateway endpoint, it will first check the JWT token during the authentication process, and then send the user and JWT token data to OPA during the authorization process to verify the role and permissions. Obviously, any request without a JWT token or without an allowed role will be rejected.

 curl -i http://127.0.0.1:9080/speaker/1/topics -H 'Authorization: {API_CONSUMER_TOKEN}'

summary

In this article, we have customized a simple policy logic to show how to allow or deny access to API resources based on the roles and permissions of API users. At the same time, we have also demonstrated how to extract information related to API users in the policy file from the JWT token payload sent by APISIX or the user's object, so as to ultimately achieve the RBAC effect of OPA and Apache APISIX.

About the Translator

Julian Chen, editor of 51CTO community, has more than ten years of experience in IT project implementation. He is good at managing internal and external resources and risks, and focuses on disseminating network and information security knowledge and experience.

Original title: RBAC With API Gateway and Open Policy Agent (OPA) , author: Bobur Umurzokov

Link: https://dzone.com/articles/rbac-with-api-gateway-and-open-policy-agentopa