When rules define the behavior in sense of the desired authentication and authorization aspects, then the providers are those entities, which manage the lifecycle of these. That are the providers, which load, reload or remove rules when new rules appears, changes are detected, or rules are deleted.
Regular, respectively upstream specific rules must somehow be organized, versioned and also loaded. So, there must be some structure allowing all of that. That structure is defined by the so-called rule sets.
A rule set can be considered to be just a file containing a list of rules and some additional meta information, like format version, name of the rule set and alike. Rule sets do also allow ordering of rules, e.g. with most specific matching expressions first allowing simpler matching expressions.
The actual format of the rule set is provider specific.
While all providers are different in the sense that they support different sources to load rule sets from, respectively monitor them, most of the providers use the same rule set format.
The following table gives an overview about existing providers
Provider | Rule Set Format | Short Description |
---|---|---|
YAML or JSON | Loads rule set files from the local file system | |
YAML or JSON | Loads rule sets from an HTTP(s) endpoint | |
YAML or JSON | Loads rule sets from cloud blobs, like AWS S3, Google Cloud Storage, Azure Cloud Storage and alike. | |
Custom Resource | Loads rule sets made available to a kubernetes cluster as customer resources. |
Last updated on Mar 9, 2024