feat(chart): expose httpRoute.tlsSecretName for pre-provisioned TLS secrets - #105
Merged
Merged
Conversation
…ecrets The NebariApp template only emitted routing.tls.enabled, so there was no values path to set routing.tls.secretName. On clusters with a pre-provisioned wildcard TLS secret (e.g. an enterprise-CA-signed cert in the gateway namespace), the operator had no choice but to fall back to its cert-manager flow — which on a selfsigned-issuer cluster produces a browser-untrusted cert or wedges the Certificate in SecretMismatch. Add an optional httpRoute.tlsSecretName value, emitted under routing.tls only when set. Unset renders identically to before (verified with helm template), so existing deployments are unaffected. Requires the operator's routing.tls.secretName support (>= v0.1.0-alpha.20).
Contributor
Docker images built for this PRBranch tag:
To deploy this PR locally: helm upgrade --install nebari-landing charts/nebari-landing \
--namespace nebari-system \
--set webapi.image.tag=fix-nebariapp-tls-secretname-101 \
--set frontend.image.tag=fix-nebariapp-tls-secretname-101 |
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
Closes #101.
The
NebariApptemplate (charts/nebari-landing/templates/nebariapp.yaml) only emittedrouting.tls.enabled, andvalues.yamlexposed nosecretNameunderhttpRoute. So on a cluster that already has a pre-provisioned wildcard TLS secret (e.g. an enterprise-CA-signed cert in the gateway namespace), there was no values path to point the landing page at it — the operator fell back to its cert-manager flow, which on aselfsigned-issuercluster yields a browser-untrusted cert or wedges theCertificateinSecretMismatch.The operator has supported
spec.routing.tls.secretNamesincev0.1.0-alpha.20(nebari-dev/nebari-operator#114), already in use by NIC — the chart just didn't surface it.What changes
This is option 2 from the issue — the surgical, non-breaking fix. An optional
httpRoute.tlsSecretNamevalue, emitted underrouting.tlsonly when set:tls: enabled: {{ .Values.httpRoute.tls }} + {{- with .Values.httpRoute.tlsSecretName }} + secretName: {{ . | quote }} + {{- end }}plus the documented value in
values.yaml(defaults to"").I deliberately did not take option 1 (full
toYamlpassthrough on the routing block). Unlike the sibling data-science-pack chart — whose template is a thin passthrough — this chart hand-renders an opinionatedNebariAppspec (keycloak protocol mappers,spaClientPKCE config) and sources routing from a separatehttpRoute.*values shape. A true passthrough would mean restructuringhttpRoute.*→nebariApp.routing.*, a breaking values change, for no benefit to this specific fix.Verification
helm templatewithnebariApp.enabled=true:tlsSecretNameunset (default): routing block renders byte-for-byte identical to before —routing.tlscarries onlyenabled. Existing deployments unaffected.tlsSecretName: my-wildcard-tls: renderssecretName: "my-wildcard-tls"underrouting.tls, landing inNebariApp.spec.routing.tls.secretName.helm lintpasses.Acceptance criteria (from #101)
secretNamevalue renders intoNebariApp.spec.routing.tls.secretName.values.yaml, pointing at the enterprise-CA / pre-provisioned-secret use case.Related
routing.tls.secretName, releasedv0.1.0-alpha.20)toYamlpassthrough toauth/landingPage. The broader "every pack re-implementsnebariapp.yamland drifts from the CRD" problem is being tracked there as a library-chart proposal; this PR is the local fix for the landing chart's routing gap.