search

istio / istio

Connect, secure, control, and observe services.
https://istio.io
Apache License 2.0
35.94k stars 7.76k forks source link

Customisation of envoy SDS secret names #41414

Closed lodthe closed 1 year ago

lodthe commented 2 years ago

Describe the feature request

At the moment Istio tells envoy to fetch TLS certificates via SDS with secret names default and ROOTCA (for validation context).

For some developers it might be useful to have the ability to change these secrets names (for example, to set service spiffe id instead of default).

This configuration opens opportunities to have several selector-matching certificates when Spire agents are used as envoy SDS.

Describe alternatives you've considered

To have only one matching certificate for a workload.

Affected product area (please put an X in all that apply)

[ ] Ambient [ x] Docs [ ] Installation [ ] Networking [ ] Performance and Scalability [ ] Extensions and Telemetry [x ] Security [ ] Test and Release [ ] User Experience [x ] Developer Infrastructure

Affected features (please put an X in all that apply)

[ ] Multi Cluster [ ] Virtual Machine [ ] Multi Control Plane

Additional context

Thanks to this patch, default identity names were supported, and now spire-agent can be used as SDS for istio envoys.

My scenario is having several selector-matching Spire certificates for a workload. At the moment, spire-agent returns the certificate with the lexicographically lowest entry id. I'd like to change the default secret name with the workload SPIFFE id.

I imagine this setting as an optional field in one of the CRDs required for a workload. I will be glad to hear your criticism of the proposed approach and learn about potential difficulties during implementation.

howardjohn commented 1 year ago

IMO this is something the CA integration should handle. Istio itself has no need for custom names and integrations have sufficient context to figure this out. I would not be in favor of this, at least with the current context

lodthe commented 1 year ago

Indeed, CA integrations have enough information to identify a workload. The question is how much has to be done to identify it, and how much CA providers are limited in functionality. Some features on behalf of integration cannot be supported due to the lack of fine-grained information.

The idea was to broaden the set of features, that can be supported by external integrations, and simplify their logic. I'm not aware of potential future applications and plans toward secret names, which might not be combined with the allowance of arbitrary secret names. Indeed, this question requires deeper research.

As for me, I've found a workaround for my initial problem, and I don't insist on the proposed changes now. If from your point it may become a problem in the future, let's put this idea aside and close the issue.

istio-policy-bot commented 1 year ago

🚧 This issue or pull request has been closed due to not having had activity from an Istio team member since 2023-02-20. If you feel this issue or pull request deserves attention, please reopen the issue. Please see this wiki page for more information. Thank you for your contributions.

Created by the issue and PR lifecycle manager.