Allow defining mechanisms in CRs

[notniknot]

Preflight checklist

• I agree to follow this project's Code of Conduct.
• I have read and am following this repository's Contribution Guidelines."
• I have discussed this feature request with the community.

Describe the background of your feature request

In a multi tenant setup, users reference central predefined mechanisms in their RuleSet.

The issue is that central mechanisms can only be managed by the platform team (or the team which manages Heimdall). This results in:

• A huge Heimdall config which grows bigger and bigger every time we need to add mechanisms
• Thus, the config is harder to manage
• The platform team is the bottleneck even though most of the mechanisms are owned by the tenants

Describe your idea

Allow defining mechanisms in either namespace or cluster scoped custom resources:

• namespace scoped mechanisms are only allowed to be consumed by RuleSets located in the same namespace
• cluster scoped mechanisms can be consumed by all RuleSets in all namespaces (could be limited by a namespace selector)

This allows tenants to manage their own mechanisms but still leaving the option to centrally manage common mechanisms.

Are there any workarounds or alternatives?

Install Heimdall in every namespace where it is needed. Could cause chaos with its CRDs.

Version

v0.17.16

Additional Context

No response

[dadrus]

Interesting idea. Would it not also lead to the same CRD "chaos", you mentioned in the "alternatives" section? I fear so. If you deploy a new version and there is a breaking change, all the CRs must be migrated.

As of today, you could indeed deploy a tenant specific heimdall instance, even in the same cluster, give it a specific auth_class, and refer to that auth class from the corresponding rules. That way only those instances, responsible for that auth class will load the rules (See also https://dadrus.github.io/heimdall/v0.17.16/docs/rules/providers/#_configuration_4 for details).

Btw. This FR is imo pretty much related to the https://discord.com/channels/1100447190796742698/1122922827834732674 idea described in discord. There was no FR ticket for that as there was no much discussion. Let us shape your topic from here in discord. Though, there are many things to be discussed and considered before it can be implemented.

[notniknot]

Thanks, that makes sense. I agree that API/versioning and migration need to be considered carefully.

The “CRD chaos” I meant in the workaround is slightly different though: deploying one Heimdall instance per tenant means multiple Helm releases, multiple runtime configs, multiple services/autoscaling/monitoring concerns and possible version drift.

In our setup Heimdall is intentionally a central platform component, but tenants own parts of the auth configuration that their RuleSets depend on. Today that forces all tenant-owned mechanisms into the central Heimdall config, so the platform team becomes the bottleneck.

CR-based mechanisms would keep the runtime centralized while delegating ownership:

• namespace-scoped mechanisms could only be referenced by RuleSets in the same namespace
• cluster-scoped mechanisms could be platform-owned shared building blocks
• Kubernetes RBAC/admission/GitOps can govern who may define or update them
• validation/status can make bad tenant config visible without hiding it in one large Helm values file

I agree breaking changes would require migration, but RuleSets already have that concern. Mechanism CRs could follow the same versioning/conversion/migration approach.

The main thing I’m looking for is not necessarily “more CRDs” specifically but a way to separate central Heimdall operation from tenant-owned mechanism definitions without requiring one Heimdall deployment per tenant.

[dadrus]

Thanks for the detailed explanation. My previous comment wasn’t meant as a disagreement. I definitely see the need, and supporting this would be a huge step forward for the project.

There are a lot of trade-offs to consider here - not just around CRDs vs. central config, but also around consistency, operability, versioning, and how far we want to lean into Kubernetes-native abstractions.

Therefore, let’s plan this feature together with the community. Even though discussions on discord can be pretty quiet at times, this topic is so fundamental that we really need a space to explore different approaches and their implications, and I’d really appreciate it if we could continue shaping these aspects in the idea topic I linked in my previous comment.