Builtin OPA to support integration with OPA's Management interface

[tayyabjamadar]

Is your feature request related to some problem you are facing? Please describe that problem here.

:- Want to configure builtin OPA with Authorino in such a way that fetching the policy bundles from a remote HTTP server and streaming logs to the same is possible. Basically, want to integrate the builtin OPA with the Management Interface as mentioned here in OPA's docs.

Currently builtin OPA only supports inline rego and policies from the external OPA policy registry.

OPA integration is accomplished in other similar tools via an External Auth plugin that connects with the Opa-envoy service, and opa-envoy supports the APIs mentioned on the above doc. But since we have builtin OPA here I think supporting the management interface APIs would be great.

Describe alternatives you've considered :- This can also be achieved if Authorino supports Ext Auth to the grpc(similar like envoy) or http.(But I guess Ext Auth is under analysis)

Did you already reject some other solutions, for some particular reasons? If you can share those here, you'll be saving everyone's time when someone has thought of the same solution you've already rejected.

:- None rejected.

[guicassolato]

Hi @tayyabjamadar

You should be able to fetch Rego policies from a remote HTTP registry with Authorino. The feature was introduced in #144 and is available since Authorino v0.5.0.

It's right here in the spec. Sorry if you couldn't find it in the docs. We're right now working on enhancing them.

Here's an example of an AuthConfig using OPA external policy registry:

apiVersion: authorino.3scale.net/v1beta1
kind: AuthConfig
metadata:
  name: my-api-protection
spec:
  hosts:
  - my-api.io
  identity:
  - name: friends
    apiKey:
      labelSelectors:
        group: friends
    credentials:
      in: authorization_header
      keySelector: APIKEY
  authorization:
  - name: my-policy
    opa:
      externalRegistry:
        endpoint: https://my-opa-server/v1/policies/policy-id
        sharedSecretRef: # optional - name of k8s secret that stores the credentials to authenticate with the policy registry API
          name: my-secret
          key: secret-key-name
        credentials: # optional - where the authentication secret flies in the request
          in: authorization_header
          keySelector: Bearer

You can get some extra info by running on a cluster where the Authorino CRDs are installed:

kubectl explain services.spec.authorization.opa.externalRegistry --api-version='config.authorino.3scale.net/v1beta1'

And here's a user guide with an example for trying Authorino with OPA: https://github.com/Kuadrant/authorino/blob/docs-restructuring/docs/user-guides/opa-authorization.md (adapt the AuthConfig as above; link may expire once the PR is merged and the branch is deleted.)

[tayyabjamadar]

Hey @guicassolato. Thanks for the response and sorry I think I did not state the problem statement correctly.

I am aware of the example AuthConfig to fetch rego policies from the HTTP server.

But what my suggestion was to builtin OPA to support the OPA management interface APIs as mentioned here in the OPA doc.Which consist of streaming the decision logs, sending status updates to remote http and etc along with fetching the policy bundle.

[guicassolato]

Hi @tayyabjamadar

No apologies needed. On the contrary, you've stated it very well the first time. It was me who overlooked it and ended up replying something else. Sorry.

What's your use-case exactly?

OPA's "Management API" is basically an umbrella for all other APIs of the OPA server that are not policy evaluation. Very briefly commenting on some of those and how I understand they relate to Authorino:

• Bundle API: the way to configure policies in Authorino is via AuthConfig custom resources. One thing Authorino misses though is auto-refreshing the cache of policies fetched from external endpoints. We could open an issue to implement a "TTL" option for that cache, similarly to WIP #181.
• Status API: the status of the AuthConfig and Authorino instance should be enough IMO.
• Decision Log API: OPA logs definitely provide more details about evaluated policies/performed queries than Authorino's, even compared to Authorino in debug mode. A way I see to perhaps improve that in the future could be 1) by making the authorization evaluators (OPA included) to respond with more than boolean responses (related to #109), and 2) implement some kind of webhook functionality that could be triggered at any arbitrary point of the auth pipeline, of course with capability to read from the Authorization JSON. Other than that, regarding logs, I guess extracting those from the Kubernetes pods should suffice. No need for a built-in interface that pushes to some endpoint periodically IMO.
• Health check and metrics APIs: Authorino also provide those. They are very basic so far, but we're working on improving them (e.g. #162).