Implementation Notes

We run an OPA on each node, because we want to avoid requiring network round trips for services making policy queries (which are often chained in serial, and block other tasks in the products).

We ensure local access via an InternalTrafficPolicy. This means that Pods accessing OPA via the service discovery will be routed to the OPA Pod on the same Node to reduce request latency and network traffic. This feature is only activated per default in Kubernetes versions 1.22 or higher.

Users can manage policy rules by creating, updating and deleting ConfigMap resources.

The responsibility of the OPA Bundle Builder is to convert these resources to bundles (tar.gz files) and make them available via an HTTP endpoint. The OPA Bundle Builder runs in a side container of the OPA Pod as a simple HTTP server that OPA is querying regularly (every 20 to 30 seconds) for updates.

Only ConfigMaps labeled with opa.stackable.tech/bundle: "true" are considered by the builder when updating bundles. The name of the data entries in the ConfigMap are used as file names when storing the rules in the bundle.