Skip to content

Add runtime TLS configuration via xDS MeshSettings#1861

Open
zmiklank wants to merge 7 commits intoistio:masterfrom
zmiklank:mesh_settings
Open

Add runtime TLS configuration via xDS MeshSettings#1861
zmiklank wants to merge 7 commits intoistio:masterfrom
zmiklank:mesh_settings

Conversation

@zmiklank
Copy link
Copy Markdown
Contributor

Implement runtime mesh-wide TLS configuration that can be pushed from
istiod to ztunnel via xDS, enabling dynamic updates without pod restart.

MeshSettings provides:

  • trustDomain: SPIFFE identity trust domain for mTLS validation
  • trustDomainAliases: additional trust domains for multi-cluster scenarios
    • this is a new feature in ztunnel, let me know if it is better to be removed.
  • meshMTLS: TLS protocol configuration (min version, cipher suites, ECDH curves)

Configuration priority: xDS > environment variables (if exist) > defaults.

This aligns ztunnel with Envoy sidecar configuration model, allowing
operators to use existing MeshConfig fields to configure ztunnel's
TLS behavior mesh-wide.

Feature was tested locally, and needs istio complementary part to work. I will create a PR to Istio in following days.
Feature is backwards compatible, so if user decides to not use the XDS meshConfig in the mesh, everything will work as before.
In hope of easier review this was implemented in 2 steps (in 2 commits), the first one delivering minimal changes, the second one centralising the mesh_config and its operations into one file.
Fixes: #1817

zmiklank and others added 2 commits April 21, 2026 09:54
Implement runtime mesh-wide TLS configuration that can be pushed from
istiod to ztunnel via xDS, enabling dynamic updates without pod restart.

MeshSettings provides:
- trustDomain: SPIFFE identity trust domain for mTLS validation
- trustDomainAliases: additional trust domains for multi-cluster scenarios
- meshMTLS: TLS protocol configuration (min version, cipher suites, ECDH curves)

Configuration priority: xDS > environment variables (if exists) > defaults.

This aligns ztunnel with Envoy sidecar configuration model, allowing
operators to use existing MeshConfig fields to configure ztunnel's
TLS behavior mesh-wide.

Expose MeshSettings in /config_dump endpoint.

Signed-off-by: Zuzana Miklankova <zmiklank@redhat.com>
Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com>
Move crypto provider selection, cipher suite parsing, and env var
fallback logic out of lib.rs into a dedicated mesh_config module.
TLS configuration is now resolved once (at startup from env vars,
or when xDS pushes MeshSettings) and stored as ResolvedMeshConfig.
Call sites read pre-resolved values instead of repeating fallback
chains. Control plane and signature verification use a lazy default
that is independent of xDS updates.

Signed-off-by: Zuzana Miklankova <zmiklank@redhat.com>
Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com>
@zmiklank zmiklank requested a review from a team as a code owner April 22, 2026 07:30
@istio-testing istio-testing added size/XXL Denotes a PR that changes 1000+ lines, ignoring generated files. needs-ok-to-test labels Apr 22, 2026
@istio-testing
Copy link
Copy Markdown
Contributor

Hi @zmiklank. Thanks for your PR.

I'm waiting for a istio member to verify that this patch is reasonable to test. If it is, they should reply with /ok-to-test on its own line. Until that is done, I will not automatically test new commits in this PR, but the usual testing commands by org members will still work.

Regular contributors should join the org to skip this step.

Once the patch is verified, the new status will be reflected by the ok-to-test label.

I understand the commands that are listed here.

Details

Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the kubernetes-sigs/prow repository.

@sridhargaddam
Copy link
Copy Markdown

/ok-to-test

@istio-testing istio-testing added ok-to-test Set this label allow normal testing to take place for a PR not submitted by an Istio org member. and removed needs-ok-to-test labels Apr 22, 2026
…l crypto provider

Signed-off-by: Zuzana Miklankova <zmiklank@redhat.com>
…S verification

Signed-off-by: Zuzana Miklankova <zmiklank@redhat.com>
…ippy

Signed-off-by: Zuzana Miklankova <zmiklank@redhat.com>
Signed-off-by: Zuzana Miklankova <zmiklank@redhat.com>
Comment thread src/proxy/inbound.rs Outdated
// This is small since it only handles the TLS layer -- the HTTP2 layer is boxed
// and measured above.
assertions::size_between_ref(1000, 1600, &serve_client);
assertions::size_between_ref(1000, 2200, &serve_client);
Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

this seems like quite the jump?

Copy link
Copy Markdown
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

hmm, yes. It is because the whole DemandProxyState was added to the serve_client.
I pushed the commit which instead of the whole DemandProxyState only uses newly introduced MeshConfigHandle. I also used it in other places where it made sense.

…ossible

Avoid capturing the full DemandProxyState (which includes TokioResolver
at ~400 bytes). MeshConfigHandle holds only the Arc<RwLock<ProxyState>>
pointer needed to read the current resolved mesh config.

Signed-off-by: Zuzana Miklankova <zmiklank@redhat.com>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

ok-to-test Set this label allow normal testing to take place for a PR not submitted by an Istio org member. size/XXL Denotes a PR that changes 1000+ lines, ignoring generated files.

Projects

None yet

Development

Successfully merging this pull request may close these issues.

Runtime TLS configuration with xDS

4 participants