HTTPRoute support as an alternative to Ingress

[stone-z]

Summary

With the sunset of ingress-nginx, many Kubernetes users are switching to using Gateway API types with a gateway of their choice.

This Helm chart could include an optional HTTPRoute in order to more easily route traffic to the SCIM bridge in Gateway API environments.

We are open to contributing this.

Use cases

Much of the community uses ingress-nginx, but it will no longer be maintained, so users must eventually find an alternative ingress or switch to gateway.

There are other documented reasons to switch, but some that may be of particular interest for this project are the security improvements of separating the infrastructure configuration (Ingress/Gateway) from the application routing (HTTPRoute) and the ability to more easily use mTLS between the application and the gateway, if the implementation supports it.

Proposed solution

Giant Swarm is already using an HTTPRoute for the SCIM bridge that we could contribute.

We could also contribute other related Envoy resources, if there is interest in implementation-specific support.

Is there a workaround to accomplish this today?

Ingresses still work fine. Users can switch to an alternative ingress controller or configure an HTTPRoute separately from this chart.

References and prior work

[somaz94]

Opened a draft PR for this: #171.

It adds an optional HTTPRoute (gated on scim.httproute.enabled, default false) that mirrors the existing Ingress conventions — parentRefs/hostnames, a default PathPrefix / rule to the <name>-svc backend, plus filters and a full rules override for advanced routing. Disabled by default, so ct install needs no Gateway API CRDs.

Happy to adjust the values shape if the maintainers (or the Giant Swarm folks who offered to contribute) have a preferred structure.

[stone-z]

Thanks for taking that @somaz94! Your implementation looks fine to me, we did basically the same thing 😄 wishing you a speedy review