Reading Time: 3 minutes

In the previous blogs (Policy Enforcement using OPA and Go Through with Rego components), we have understood that what is OPA, how it works and the different components of rego so In this blog, we are going to understand what is bundle-API, how we can integrate with OPA and how to inject OPA policy and data at a dynamic time on the cluster with bundle-API. The bundle-API helps to inject the rego policy and data onto the cluster for the OPA authorization.

There are two types by which we can inject the policy and data onto the cluster –

• Set policy as config-map while deploying the application (Static type)
• Inject policy from the external source onto the cluster (Dynamic type)

Static Type –

We configure the OPA policy at the time of configuring the OPA-istio-plugin onto the cluster. Here is the configuration –

apiVersion: v1
kind: ConfigMap
metadata:
  name: opa-policy
data:
  policy.rego: |
    package istio.authz
    default allow = false

Advantage –

• Low latency of a request being processed.

Disadvantage –

• We can’t change the policy and data at a dynamic time on the cluster.

Dynamic type(bundle-API) –

Many times the policy decision depends upon the external data. If the external data changes infrequently and can store all data at once on the cluster then the bundle-API will be highly useful. The bundle-API based on a push-based model means the cluster continuously polls the data from an external source in the specified time.

A. The OPA-enabled service has an envoy proxy deployed into the same pod that will ask OPA for authorization. The OPA policy evaluates its policy and responds to the envoy whether this user can access the resource or not.

B. The OPA will send the request to the bundle-server because the bundle-server continuously polled the data and policy from external sources So to get the latest policy and data OPA sends the request to the bundle-server.

C. The bundle-server replicates data from the source of truth.

D. This is the full policy and data flow in bundle-API after steps A, B and C the opa-enabled service gets the response from OPA whether this user can access the resource or not.

Let’s take an example –
Here we will use AWS-S3 as an external data source for storing data and policy. Here is the bundle-API configuration –

apiVersion: v1
kind: ConfigMap
metadata:
  name: opa-istio-config
data:
  config.yaml: |
    services:
      - name: controller
        url: https://policy-bundle.s3.ohio-west-2.amazonaws.com
    bundles:
      authz:
        service: controller
        resource: auth.gz 
        polling:
          min_delay_seconds: 10
          max_delay_seconds: 20
    plugins:
      envoy_ext_authz_grpc:
        addr: :9191
        query: data.istio.authz.allow
        dry-run: false
        enable-reflection: false

The configuration is as follows –

• The AWS-S3 URL is AWS-S3 URL is https://policy-bundle.s3.ohio-west-2.amazonaws.com/auth.gz
• The polling time will be min 10 sec and max 20 Sec.
• The rego policy rule on which the whole authorization works is query parameter query: data.istio.authz.allow

If the AWS-S3 URL is not public then we need to make service-entry to get this thing work. where we will specify the host and port for hitting AWS-S3 Here is the service entry configuration –

apiVersion: networking.istio.io/v1alpha3
kind: ServiceEntry
metadata:
  name: opa-bundle
spec:
  hosts:
   - "amazonaws.com"
   - "*.amazonaws.com"
  ports:
  - number: 443
    name: https
    protocol: HTTPS
  - number: 80
    name: http
    protocol: HTTP
  resolution: NONE
  location: MESH_EXTERNAL

Advantage

• we can include an entirely new data source at the bundle server without changing the authentication service or the OPA-enabled service.
• It’s best for small size infrequent data.

Disadvantage

• The bundle-API storing the whole data as a bundle on the cluster which is a security concern, Ideally only one user data should be present on the cluster not of all user data.
• We can’t handle a large amount of data through bundle-API because the OPA takes 20X memory to uncompressed and compile the bundle onto the cluster. if you do so, then we need to increase the resource allocation memory of opa-enabled service, otherwise, the service pod will crash with “not sufficient memory” error message.

Wrap Up

I hope you get some insights about bundle-API and how it works. Here are some key points:

• bundle-API is the new way to inject the policy and data at a dynamic time on to the cluster.
• Only use for small-sized infrequent data
• If data is static and will not be changed in the future then opt for config-map option.

You can get a working template at Knoldus Techhub

NOTE:
I’ll post more blogs on OPA soon. Stay Tuned.

Thanks for Reading!!!
For more reference, you can refer to openpolicyagent.org.