opa

Summary

Description

The opa plugin is used to integrate with Open Policy Agent. By using this plugin, users can decouple functions such as authentication and access to services and reduce the complexity of the application system.

Attributes

NameTypeRequirementDefaultValidDescription
hoststringrequiredOpen Policy Agent service host (eg. https://localhost:8181)
ssl_verifybooleanoptionaltrueWhether to verify the certificate
policystringrequiredOPA policy path (It is a combination of package and decision. When you need to use advanced features such as custom response, decision can be omitted)
timeoutintegeroptional3000ms[1, 60000]msHTTP call timeout.
keepalivebooleanoptionaltrueHTTP keepalive
keepalive_timeoutintegeroptional60000ms[1000, …]mskeepalive idle timeout
keepalive_poolintegeroptional5[1, …]msConnection pool limit
with_routebooleanoptionalfalseWhether to send information about the current route.
with_servicebooleanoptionalfalseWhether to send information about the current service.
with_consumerbooleanoptionalfalseWhether to send information about the current consumer. (It may contain sensitive information such as apikey, so please turn it on only if you are sure it is safe)

Data Definition

APISIX to OPA service

The type indicates that the request type. (e.g. http or stream) The reqesut is used when the request type is http, it contains the basic information of the request. (e.g. url, header) The var contains basic information about this requested connection. (e.g. IP, port, request timestamp) The route, service, and consumer will be sent only after the opa plugin has enabled the relevant features, and their contents are same as those stored by APISIX in etcd.

  1. {
  2. "type": "http",
  3. "request": {
  4. "scheme": "http",
  5. "path": "\/get",
  6. "headers": {
  7. "user-agent": "curl\/7.68.0",
  8. "accept": "*\/*",
  9. "host": "127.0.0.1:9080"
  10. },
  11. "query": {},
  12. "port": 9080,
  13. "method": "GET",
  14. "host": "127.0.0.1"
  15. },
  16. "var": {
  17. "timestamp": 1701234567,
  18. "server_addr": "127.0.0.1",
  19. "server_port": "9080",
  20. "remote_port": "port",
  21. "remote_addr": "ip address"
  22. },
  23. "route": {},
  24. "service": {},
  25. "consumer": {}
  26. }

OPA service response to APISIX

In the response, result is automatically added by OPA. The allow is indispensable and will indicate whether the request is allowed to be forwarded through the APISIX. The reason, headers, and status_code are optional and are only returned when you need to use a custom response, as you’ll see in the next section with the actual use case for it.

  1. {
  2. "result": {
  3. "allow": true,
  4. "reason": "test",
  5. "headers": {
  6. "an": "header"
  7. },
  8. "status_code": 401
  9. }
  10. }

Example

First, you need to launch the Open Policy Agent environment.

  1. $ docker run -d --name opa -p 8181:8181 openpolicyagent/opa:0.35.0 run -s

Basic Use Case

You can create a basic policy for testing.

  1. $ curl -X PUT '127.0.0.1:8181/v1/policies/example1' \
  2. -H 'Content-Type: text/plain' \
  3. -d 'package example1
  4. import input.request
  5. default allow = false
  6. allow {
  7. # HTTP method must GET
  8. request.method == "GET"
  9. }'

After that, you can create a route and turn on the opa plugin.

  1. $ curl -X PUT 'http://127.0.0.1:9080/apisix/admin/routes/r1' \
  2. -H 'X-API-KEY: <api-key>' \
  3. -H 'Content-Type: application/json' \
  4. -d '{
  5. "uri": "/*",
  6. "plugins": {
  7. "opa": {
  8. "host": "http://127.0.0.1:8181",
  9. "policy": "example1"
  10. }
  11. },
  12. "upstream": {
  13. "nodes": {
  14. "httpbin.org:80": 1
  15. },
  16. "type": "roundrobin"
  17. }
  18. }'

Try it out.

  1. # Successful request
  2. $ curl -i -X GET 127.0.0.1:9080/get
  3. HTTP/1.1 200 OK
  4. # Failed request
  5. $ curl -i -X POST 127.0.0.1:9080/post
  6. HTTP/1.1 403 FORBIDDEN

Complex Use Case (custom response)

Next, let’s think about some more complex scenarios.

When you need to return a custom error message for an incorrect request, you can implement it this way.

  1. $ curl -X PUT '127.0.0.1:8181/v1/policies/example2' \
  2. -H 'Content-Type: text/plain' \
  3. -d 'package example2
  4. import input.request
  5. default allow = false
  6. allow {
  7. request.method == "GET"
  8. }
  9. # custom response body (Accepts a string or an object, the object will respond as JSON format)
  10. reason = "test" {
  11. not allow
  12. }
  13. # custom response header (The data of the object can be written in this way)
  14. headers = {
  15. "Location": "http://example.com/auth"
  16. } {
  17. not allow
  18. }
  19. # custom response status code
  20. status_code = 302 {
  21. not allow
  22. }'

Update the route and set opa plugin’s policy parameter to example2. Then, let’s try it.

  1. # Successful request
  2. $ curl -i -X GET 127.0.0.1:9080/get
  3. HTTP/1.1 200 OK
  4. # Failed request
  5. $ curl -i -X POST 127.0.0.1:9080/post
  6. HTTP/1.1 302 FOUND
  7. Location: http://example.com/auth
  8. test

Complex Use Case (send APISIX data)

Let’s think about another scenario, when your decision needs to use some APISIX data, such as route, consumer, etc., how should we do it?

Create a simple policy echo, which will return the data sent by APISIX to the OPA service as is, so we can simply see them.

  1. $ curl -X PUT '127.0.0.1:8181/v1/policies/echo' \
  2. -H 'Content-Type: text/plain' \
  3. -d 'package echo
  4. allow = false
  5. reason = input'

Next, update the config of the route to enable sending route data.

  1. $ curl -X PUT 'http://127.0.0.1:9080/apisix/admin/routes/r1' \
  2. -H 'X-API-KEY: <api-key>' \
  3. -H 'Content-Type: application/json' \
  4. -d '{
  5. "uri": "/*",
  6. "plugins": {
  7. "opa": {
  8. "host": "http://127.0.0.1:8181",
  9. "policy": "echo",
  10. "with_route": true
  11. }
  12. },
  13. "upstream": {
  14. "nodes": {
  15. "httpbin.org:80": 1
  16. },
  17. "type": "roundrobin"
  18. }
  19. }'

Try it. As you can see, we output this data with the help of the custom response body function described above, along with the data from the route.

  1. $ curl -X GET 127.0.0.1:9080/get
  2. {
  3. "type": "http",
  4. "request": {
  5. xxx
  6. },
  7. "var": {
  8. xxx
  9. },
  10. "route": {
  11. xxx
  12. }
  13. }