Support SPIRE certificates for `workload -> control-plane` traffic about istio HOT 21 OPEN

Provide some context on the usage in my workplace:

• We want our SPIFFE/SPIRE infrastructure to be the single solution for certificate issuing for all workloads, both control plane date flow and data plane flow.
• It is very easy for us to distributed keys and trust bundle since we have spire-agent everywhere.
• We also want to control the attestation aspect, which Istio's self sign cert do not provide.
• Kubernetes secret is a big no-no. We do not want key materials to be persisted in any where.
• File mount offers a rudimental solution. If we have to do it, we can make spire-agent write cert into a memory dir and rotate it periodically. But it does raise the concern of inconsistency during the cut over of rotation.

from istio.

One cent from me, istiod startup should not depend on spire, fetching cert from spire api during bootstrap is risky. Can bring more dependencies on deploying

I definitely understand where you're coming from here, however if a user has decided that SPIRE is the certificate source than I think that's acceptable. In fact istiod coming up despite missing its xDS CA may mislead users. The other option I could see is failing readiness checks, but I'm not sure how much use istiod is without the xDS server, and we can't start said server without the proper certs.

from istio.

Agree on the concern of introducing a dependency during startup. And I agree with @EItanya that the reliability on that dependency is what user should be concerned about. The current approach which rely on k8s secret or a mount file arguable will have same reliability concern. It just that failures like k8s fails to provide secret or a file missing are perceived as less likely to happen.

From security perspective, no workload should start if they're not able to attest their identity. For example, it would be hazardous if a malicious actor can start their own istiod without attestation to manipulate the mesh. The workload's cert managed on a separate loop from istiod CA mitigate the risk of man in the middle attack. However, a fake istiod still can do a lot of damage by setting malicious network configurations.

We do need to ensure a correct layering of the infrastructure systems. If SPIRE lays the foundation of workload attestation, it shouldn't depends on Istio.

from istio.

istio-csr has this problem today and mounts the certificates manually to get around it https://raw.githubusercontent.com/cert-manager/website/master/content/docs/tutorials/istio-csr/example/istio-config-getting-started.yaml

from istio.

+1 on having some abstraction here that makes it easier to detangle istio CA from the rest of istiod, since absolutely nothing about how that CA works should be istio-specific, and out of everything istiod does, it's the thing that should be the easiest to replace with another non-Istio impl.

Whether that's SDS or some other interop channel doesn't matter much to me. I think it makes sense to have something here that is less crude than volume mounts, as those are not always acceptable, especially if they contain secrets.

from istio.

+1 on reducing the complexity of istio ca and supporting a flexible attestation model for control plane certificates.

from istio.

The current file mounted cert usage is not quite convenient, Integrate with spire agent is reasonable.
One cent from me, istiod startup should not depend on spire, fetching cert from spire api during bootstrap is risky. Can bring more dependencies on deploying

from istio.