spiffe
[WIP] SPIFFE Broker API & Endpoint
This PR adds a SPIFFE Broker API and Endpoint to the SPIFFE specification.
See Google doc for design.
Work in progress, this is a first attempt and feedback will help to refine the specification.
Resolves #313.
are there plans to continue work on this proposal? with istio ambient mode reaching GA, spire support is needed.
https://github.com/istio/istio/issues/42339#issuecomment-3382357524
Hi @apexlnc,
this topic was discussed at the Istio spec call last week. The Istio community has yet to decide if they want to support a SPIFFE API at ztunnel or other flavors such as Envoy xDS. Until this decision is made this work here is put on hold.
Feel free to join today and express your opinion in this topic.
- There are some of us that are avoiding using istio (ambient) right now because it does not support spiffe. So they really should take that into consideration.
- I think we should have this functionality here, regardless if istio will support it or not.
@kfox1111 I'm not a bit hesitant adding this API into the standard if we have no client in sight that's picking it up. (In case Istio decides against it)
I agree with Arndt's sentiment here - if we don't have a clear adopter in mind, I would be hesitant to introduce the new specification. It'll be difficult for us to validate the specification is fit for purpose.
I'd use it for making spire-ha-agent -> spiffe-ha-agent.
There's also a chicken and the egg issue around it. We may never get users if we dont produce it in the first place. As is, istio ambient has been delaying as "we dont have spiffe support" If we had it, then it would shine light on the issue and prevent that from being used as a reason for not supporting it.
I'd use it for making spire-ha-agent -> spiffe-ha-agent.
Is there some documentation/design somewhere for this? It'd be great to explore this in SIG-Spec
I'd use it for making spire-ha-agent -> spiffe-ha-agent.
There's also a chicken and the egg issue around it. We may never get users if we dont produce it in the first place. As is, istio ambient has been delaying as "we dont have spiffe support" If we had it, then it would shine light on the issue and prevent that from being used as a reason for not supporting it.
I agree. We already use SPIRE with Istio's sidecar mode. I am eager to replace the sidecars with ambient ... but without the SPIRE/SPIFFE support, that is actually the only pain point why we did not migrate to ambient ;-(
I actually wonder a bit. Just stumpled over: https://www.solo.io/blog/kubernetes-identity-the-right-way-with-spire-and-ambient
I actually wonder a bit. Just stumpled over: https://www.solo.io/blog/kubernetes-identity-the-right-way-with-spire-and-ambient
Solo has spire integration with the enterprise version of ztunnel. I am currently putting together a github issue in ztunnel to start a channel to get my version of ztunnel that supports Spire upstreamed for the broader community.
Mhm...too bad SOLO did not contribute it to open source community. @MikeZappa87 if there is something to test, let me know. I'd be eager to try this out.
As @kfox1111 said, there seems to be a chicken-and-egg problem here.
Further up in this issue
@kfox1111 I'm not a bit hesitant adding this API into the standard if we have no client in sight that's picking it up. (In case Istio decides against it)
An Istio maintainer saying a few months ago:
That would be ok with me; moving from e.g. experimental -> alpha would be gated on the spiffe API
Seems like the kind of thing where a relatively short synchronous conversation between two parties could sort out if both projects are willing to move forward.
(Also posting on the reciprocal issue on istio.)
@kamalmarhubi I'm working together with the Istio community to get this work finished. There is a weekly community call where this topic is discussed.
@arndt-s appreciate you taking this forward. are there meeting notes and/or next steps on this?
The latest update (approx. 3 weeks ago) is that the Istio community is looking at various alternative approaches before making a decision. One of them being leveraging CAP_SYS_ADMIN to make the existing Workload API incl. PID attestation work. Another alternative is using Envoy SDS (not the current variant SPIRE has implemented but an alternative to it where PID is passed as resource names IIRC)
Please feel free to reach out or comment here if you have perspectives. The notes/agenda from the Istio Working Group meeting can be found here: https://docs.google.com/document/d/1wsa06GGiq1LEGwhkiPP0FKIZJqdAiue-VeBonWAzAyk/edit?tab=t.0#heading=h.o8pz6aqnzzgk
The latest update (approx. 3 weeks ago) is that the Istio community is looking at various alternative approaches before making a decision. One of them being leveraging CAP_SYS_ADMIN to make the existing Workload API incl. PID attestation work. Another alternative is using Envoy SDS (not the current variant SPIRE has implemented but an alternative to it where PID is passed as resource names IIRC)
Please feel free to reach out or comment here if you have perspectives. The notes/agenda from the Istio Working Group meeting can be found here: https://docs.google.com/document/d/1wsa06GGiq1LEGwhkiPP0FKIZJqdAiue-VeBonWAzAyk/edit?tab=t.0#heading=h.o8pz6aqnzzgk
We have this working however we required to use the host pid namespace (hostPid: true)
@MikeZappa87 Which option do you have working? The one that uses the existing WorkloadAPI or via SDS?