Multiple pipeline configurations and K8s CRDs

[shishkin]

I understand that in K8s context heimdall container needs to be deployed once per backend service. The reason for that is the pipeline configuration being process-singleton.

If pipeline configuration would instead allow multiple named pipelines defined, forward auth middleware could then select a pipeline per ingress/service. This could be done via a header or path segment. That would allow having a single instance of heimdall in the cluster.

Furthermore, pipeline configurations could then be stored in CRDs and managed along with backend service deployments and ingresses.

What do you think?

[dadrus]

Hi. And thank you for asking.

I understand that in K8s context heimdall container needs to be deployed once per backend service. The reason for that is the pipeline configuration being process-singleton.

Unfortunately your understanding is not correct. The "global" mechanism definitions are indeed singletons. But these can be considered as prototypes. They just define the behavior which is possible. The actual "instantiation" happens in the rules, respectively pipelines defined in rules. That means each and every rule has its own set of mechanism "instances". These are rule pipeline specific and used only by that rule and none of the rules influence each other. While defining a pipeline in a rule, you reuse, what has been defined globally, but are also able to override specific parts (which is then also rule specific and does not influence the "global" mechanisms). These "globally" defined mechanisms can also be considered as a catalogue of options, from which each particular rule takes and combines the ones, which are required for it. Like at a car manufacturer - you configure your car by selecting components, which are available and tune them as you want. And than, you have your own specific car, which you use :) This misconception has been addressed by PRs linked to #28. Please check the "dev" documentation version, whether it is more clear now and let me know.

If pipeline configuration would instead allow multiple named pipelines defined,

I hope my answer from above has answered that as well. In principle each and every rule is a named pipeline (or actually two - the regular and the error pipeline) - the rule id the the name. In addition a rule defines a couple of other things, like the url patterns/glob, etc for which the pipeline defined in the rule applies.

... forward auth middleware could then select a pipeline per ingress/service. This could be done via a header or path segment. That would allow having a single instance of heimdall in the cluster.

Given the description from above, this is not required. Each and every request can be forwarded to heimdall and is matched based on the url regexes/globs of the known rules. If a rule matches, its pipeline is executed. If none of the rules matches the default rule's pipeline (if defined) is executed, otherwise 404 is returned.

This way you can have heimdall deployments as you need it. E.g. with 1:1 heimdall-to-ingress relation, but you can also have 1:n heimdall-to-ingress relation. as well as n:1 heimdall-to-ingress relation.

Furthermore, pipeline configurations could then be stored in CRDs and managed along with backend service deployments and ingresses.

This is exactly what has been implemented by #336.

Please Note: the helm chart (created in #325 and updated in #336), as well as the CRD support (#336) is not yet released. Planned for 0.5.0-alpha (see also #332 and Milestone 5)

Could you please check the current "dev" version of the documentation and let me know, if those things, which I've written above are not properly described in it. Btw. the documentation of the Helm Chart is available under https://github.com/dadrus/heimdall/tree/main/charts/heimdall

[dadrus]

FYI: The v0.5.0-alpha release is now available and includes the changes/functionality described above.