Add runtime TLS configuration via xDS MeshSettings#1861
Add runtime TLS configuration via xDS MeshSettings#1861zmiklank wants to merge 7 commits intoistio:masterfrom
Conversation
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>
|
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 Regular contributors should join the org to skip this step. Once the patch is verified, the new status will be reflected by the I understand the commands that are listed here. DetailsInstructions 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. |
|
/ok-to-test |
…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>
| // 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); |
There was a problem hiding this comment.
this seems like quite the jump?
There was a problem hiding this comment.
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>
Implement runtime mesh-wide TLS configuration that can be pushed from
istiod to ztunnel via xDS, enabling dynamic updates without pod restart.
MeshSettings provides:
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