Workload Identity: SPIFFE Federation and Join Method RFD #43348
Conversation
strideynet
added
the
no-changelog
| ### Federation | ||
|
|
||
| SPIFFE federation relationships are one-way. One trust domain can be configured | ||
| to trust identities issued by another trust domain, but the reverse may not |
There was a problem hiding this comment.
Sounds a lot like trusted clusters. I wonder if Teleport trusted clusters should automatically create a SPIFFE federation relationship..
There was a problem hiding this comment.
Hah - I think technically this is already the case today as we currently just pull the CAs, so if you're in a leaf cluster, the root cluster SPIFFE CA is already there. But, we should definitely formalize that as a thing that happens. I think it should be possible to make the federation syncer automatically create a SPIFFEFederation resource in these cases as well so it's "visible" in the same way. I'll have a think about it.
There was a problem hiding this comment.
So I've opted against this for now. I think there's a lot of cases where folks will want this relationship to be "two way" and I think providing an easier mechanism for configuring that (or the one way relationship) makes more sense rather than having a default that won't actually serve most people's needs
I think for now it makes sense to tackle this as a future improvement because the existing mechanism already works between two Teleport clusters and I don't want to expand the scope too much.
We'll achieve that through a custom "bundle source" that's optimised for Teleport clusters and will leverage the existing CA syncing that Teleport performs. It'll make it easier to setup, but leave the control in the hands of the operator.
Part of #36639
Part of #38927
Closes #44859
RFD for the introduction of SPIFFE Federation to Teleport Workload Identity and support for a SPIFFE SVID based join method.