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.
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).
Users can manage policy rules by creating, updating and deleting
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 `ConfigMap`s to 1MB. Users have to take this limit into consideration when manging policy rules.|
Only ConfigMaps labeled with
opa.stackable.tech/bundle: "true" are considered by the builder when updating bundles. The name of
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).|