operator/charts: add extraDNSNames to TLS certificates for failover SANs#1561
Draft
david-yu wants to merge 2 commits into
Draft
operator/charts: add extraDNSNames to TLS certificates for failover SANs#1561david-yu wants to merge 2 commits into
david-yu wants to merge 2 commits into
Conversation
Add an `extraDNSNames` field to the broker TLS `Certificate` configuration so
users can specify additional Subject Alternative Names on the generated server
certificate. The names are always appended regardless of whether an `issuerRef`
is supplied, and are ignored when a `secretRef` is provided (the operator does
not generate the certificate in that case).
The motivating use case is TLS failover between clusters: baking a stable,
shared hostname into the server certificates of two clusters lets clients fail
over (e.g. via DNS repointing) without hitting a TLS hostname mismatch.
The field is wired into both certificate generators:
- charts/redpanda (the Redpanda CRD / Helm chart path), via
`tls.certs.<name>.extraDNSNames`
- operator/multicluster (StretchCluster / RedpandaBrokerPool), per pool,
since each pool is its own cluster
Generated CRDs, schemas, partials, applyconfigurations, deepcopy, and chart
templates are regenerated accordingly.
Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
The extraDNSNames TLS SAN feature is scoped to the Redpanda CRD only, dropping the multicluster broker-pool wiring (GetExtraDNSNames helper, certs.go usage, and the tls-extra-dns-names render case). The lifecycle values golden file is regenerated so TestV2ResourceClient picks up the new extraDNSNames cert field. Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
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
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.
What
Adds an
extraDNSNamesfield to the broker TLSCertificateconfiguration, letting users specify additional Subject Alternative Names (SANs) on the generated server certificate.RedpandaCRD / Helm chart):tls.certs.<name>.extraDNSNamesStretchCluster/RedpandaBrokerPool): per-pooltls.certs.<name>.extraDNSNames(each pool is its own cluster)The names are always appended regardless of whether an
issuerRefis supplied, and are ignored when asecretRefis set (the operator doesn't generate the cert in that case).Why
The motivating use case is TLS failover between clusters. Today there is no way to add custom SANs to broker certs — only the automatic internal service names plus the
applyInternalDNSNamestoggle. By baking a single, stable, shared hostname (e.g.redpanda.failover.example.com) into the server certificates of two clusters, clients can fail over between them (e.g. by repointing DNS) without hitting a TLS hostname mismatch.This pairs naturally with the shadow-link DR story, where clients may need to switch from a source cluster to a shadow cluster transparently.
Example
Implementation
charts/redpanda/values.go(TLSCert.ExtraDNSNames)charts/redpanda/certs.gooperator/api/redpanda/v1alpha2/redpanda_clusterspec_types.go(Certificate.ExtraDNSNames)operator/api/redpanda/v1alpha2/stretch_cluster_helpers.go(GetExtraDNSNames)operator/multicluster/certs.goGenerated artifacts (CRDs,
values.schema.json, partials, applyconfigurations, deepcopy, chart templates) were regenerated viatask generate.Tests
charts/redpanda: newTestClientCertsExtraDNSNamesasserts both automatic and extra SANs appear on the generated server cert.operator/multicluster: newtls-extra-dns-namesrender golden case proves the SANs flow through per-pool cert generation.TestTemplateand multiclusterTestRendergolden tests pass with no unrelated drift.Notes / open questions for review
issuerRef), soextraDNSNamesis honored at the pool level. That granularity is arguably correct for failover (per-cluster SANs), but flagging it in case reviewers want cluster→pool TLS propagation addressed separately.dnsNames. If IP-based SANs are wanted, a follow-upextraIPAddressesfield wiring intoSpec.IPAddresseswould be straightforward.🤖 Generated with Claude Code