Implementation notes
These notes may be of use when trying to understand why things are implemented the way that they are, but should not be required reading for regular use.
OPA replica per node
OPA runs on each Node to avoid requiring network round trips for services making policy queries (which are often chained in serial, and block other tasks in the products).
Local access is ensured via an InternalTrafficPolicy.
This means that Pods accessing OPA via the service discovery are routed to the OPA Pod on the same Node to reduce request latency and network traffic.
OPA Bundle Builder
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.
| Kubernetes limits the size of ConfigMaps to 1MB. Users have to take this limit into consideration when managing policy rules. |
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.
| Currently, it is the user’s responsibility to make sure these names do not collide (as they will override each other). |