feat(helm): add extensible Gateway API routing with TLS passthrough#2108
Open
krishicks wants to merge 2 commits into
Open
feat(helm): add extensible Gateway API routing with TLS passthrough#2108krishicks wants to merge 2 commits into
krishicks wants to merge 2 commits into
Conversation
Move Kubernetes Gateway creation and route settings out of the grpcRoute hierarchy and into a dedicated gatewayApi configuration tree. Nesting the Gateway resource under grpcRoute made the Gateway lifecycle look like an implementation detail of GRPCRoute. It also coupled shared Gateway identity and listener configuration to one route kind, making it awkward to create only a Gateway, attach only a route to an existing Gateway, or add other Gateway API route types. Use gatewayApi as the umbrella because it names the Kubernetes Gateway API integration directly and avoids conflating it with the OpenShell gateway server. Keep shared Gateway resource settings under gatewayApi.gateway and place independently selectable route kinds under gatewayApi.routes. The initial gatewayApi.routes.grpc entry preserves GRPCRoute support while establishing a natural extension point for TLSRoute and other route types. Restore the generated Gateway to its original fixed HTTP listener on port 80 and remove the TLS termination settings introduced in commit abcd15d while restructuring the values contract. This removal is intentional and temporary: a later commit restores encrypted ingress as TLS passthrough using TLSRoute, without coupling TLS configuration to GRPCRoute. Add shared helpers for Gateway name and namespace resolution, reject the removed grpcRoute values with migration guidance, and cover Gateway-only, GRPCRoute-only, combined, and pre-existing Gateway configurations with Helm unit tests. Update the chart values, CI overlay, generated README, ingress documentation, Skaffold guidance, and troubleshooting references to use the new hierarchy. Signed-off-by: Kris Hicks <khicks@nvidia.com>
Add gatewayApi.routes.tls so TLSRoute can be created independently for an existing Gateway or paired with a chart-managed Gateway. When the chart owns the Gateway, enabling the route adds a fixed port 443 TLS listener in Passthrough mode while retaining the existing HTTP listener. This revises the ingress approach introduced by commit abcd15d. Envoy reads the ClientHello SNI for routing and forwards the encrypted stream to the OpenShell gateway, which remains the TLS endpoint. That preserves end-to-end TLS and client certificate authentication, so existing mTLS continues to work through Envoy. Passthrough also avoids certificate management at the Envoy listener. It does not require reusing the OpenShell server certificate as a Gateway certificate or provisioning a separate edge certificate and Secret. The server certificate only needs to cover the external SNI hostname. Signed-off-by: Kris Hicks <khicks@nvidia.com>
krishicks
requested review from
a team,
derekwaynecarr,
maxamillion and
mrunalp
as code owners
|
🌿 Preview your docs: https://nvidia-preview-pr-2108.docs.buildwithfern.com/openshell |
TaylorMutch
approved these changes
Jul 1, 2026
Collaborator
Author
|
cc @zhaohuabing I think this solves the problem you created #2015 to fix while retaining mTLS support, and overall being a simpler implementation as it does TLS passthrough instead of termination. |
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
2 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Summary
Refactor the Helm chart’s Gateway API configuration under a route-neutral
gatewayApihierarchy, allowing Gateway resources and individual route types to be managed independently. Replace the Envoy TLS termination approach introduced byabcd15d1with TLS passthrough, preserving end-to-end TLS and mTLS while avoiding certificate management at the Envoy listener.Related Issue
Follow-up to #2015 (
abcd15d1).Changes
grpcRoute.gatewayvalues hierarchy with:gatewayApi.gatewayfor shared Gateway resource configuration.gatewayApi.routes.grpcfor independently managed GRPCRoute configuration.gatewayApi.routes.tlsfor independently managed TLSRoute configuration.gatewayApias the parent key to distinguish the Kubernetes Gateway API integration from the OpenShell gateway server.TLSlistener inPassthroughmode when TLSRoute and chart-managed Gateway creation are enabled.gateway.networking.k8s.io/v1TLSRoute that routes by SNI and forwards the encrypted stream to the OpenShell service.server.disableTls=true.grpcRoutevalues.gateway-helmv1.8.1.Testing
mise run pre-commitpassesChecklist