ztunnel

ztunnel copied to clipboard

Added support for K8 CSR and custom signer

@howardjohn I will move the client creation to the common level (probably when we create the configs) ?

Why do we have a different k8s csr support from sidecar? We send request to istiod and istiod will do this for sidecar

IMO Ztunnel has all the capabilities to make a CSR request directly. Why to add an extra complexity of sending req to istiod. cc : @howardjohn

@aryan16 How can we support VM installation using this mode?

@aryan16 How can we support VM installation using this mode?

If VM is able to talk to K8s api server then no issues, if not we won't be using this feature instead use the existing GRPC call to istiod.

The committers listed above are authorized under a signed CLA.

• :white_check_mark: login: aryan16 / name: Aryan Gupta (16bd692dcf814a12c1878c90de4391abad8946e3)

PR needs rebase.

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/test-infra repository.

What's next ? The DNS proxy ( which is REQUIRED if the underlying network is not secure ) ? Integration with the external SDS provider using UDS ?

Can we please add the agent and just use it ? No need for ztunnel to duplicate all the integrations and do everything ( in a slightly different way ).

A design doc on such changes with focus on security will also be greatly appreciated:

• who approves the CSRs and on what criteria ? If Istiod, why not use the existing code that also generates the CSR
• VMs - how does it change the install and security requirements ? We didn't use k8s signing from VMs because it required VMs to have K8S SA and access - which means higher escalation risks and permissions.
• what are the benefits compared to using the current method and letting Istiod generate the k8s sign request ?

But even if we conclude direct integration with k8s from the proxy is best ( and I can be convinced it's a more standard protocol than our gRPC call to Istiod ) - we should still do it in the agent, so both sidecars and ambient are consistent and use whatever is best.

On a related note - ztunnel should eventually match the integrations we have, including SDS and CSI-based providers ( in both dedicated mode and in future if we implement delegation ).

I saw the FAKE provider - IMO it should be replaced (or we should add) with a mode that reads from /var/run/secrets... ( same default as istio-agent ), and fallback to SDS using the well-known path that the Envoy is using ( for Spire and all other integrations ). And once SDS is added - we can maybe remove the call to Istiod and keep ztunnel focused on proxying, not implementing multiple CA protocols, just XDS and files.