Allow workloads to receive federated bundles without having to specify them on a per-entry basis

[evan2645]

We have received many questions and comments in the past relating to pain around having to specify which workloads federate with which trust domains. Sometimes it is desirable to have trust domains that all workloads implicitly federate with, and it is a use case that SPIRE should support in an effort to reduce management overhead.

That said, I think there are still use cases in which we want to be explicit about this. How do we have our cake and eat it too?

Here are some options I can think of:

• SPIRE Server configurable: SPIRE Server is configured with an option that tells it to give all workloads all federated bundles. Pro: simple Con: broad control with no ability to scope
• Bundle configurable: The federated bundle, or the federation relationship, is flagged as one that is implicitly passed to all workloads. Pro: More flexible Con: slightly more overhead, less clarity on who federates with what

Of the two, my preference is for the 2nd.

With both of these options, we need to figure out the implication on (and behavior of) the federates_with field we have on entries... and relatedly, how the user gets to know which workloads federate with what (e.g. when a user looks at an entry, do we artificially populate federates_with?)

[azdagron]

I also like the 2nd. I think it binds it closer to the thing representing the "relationship". If you were to delete the bundle or relationship, it would make sense to me that the implicit federates_with would disappear. Another benefit, is that it opens up a natural way for the agent to learn about this property on a federated bundle when it syncs it down, where it can apply the implicit federates_with relationship to all entries. Otherwise the server will have to append these dynamically to each entry before it returns them to agents.

[evan2645]

If you were to delete the bundle or relationship, it would make sense to me that the implicit federates_with would disappear. Another benefit, is that it opens up a natural way for the agent to learn about this property on a federated bundle when it syncs it down, where it can apply the implicit federates_with relationship to all entries. Otherwise the server will have to append these dynamically to each entry before it returns them to agents.

Very good points. What I'm hearing here is two things I think. First, it should be configurable on a per-bundle basis. Second, the server should dynamically append any implicit bundles to the federates_with entry fields. 👍 from me

[azdagron]

Second, the server should dynamically append any implicit bundles to the federates_with entry fields.

Heh, I was trying to communicate that we could avoid having the server dynamically append federates_with to entries by publishing the "federate with me implicitly" property of the bundles in the bundle API so that agents could handle this themselves.

[evan2645]

Heh, I was trying to communicate that we could avoid having the server dynamically append federates_with to entries by publishing the "federate with me implicitly" property of the bundles in the bundle API so that agents could handle this themselves.

Oh I see ... If we do that, we need to think carefully about how an operator can ask "what does X federate with?". Currently, entry show provides all the necessary information.

Both options feel kind of bad... one misrepresents the entry object itself, and the other makes it such that you can't see everything about a specific workload context in one place.

[azdagron]

IMO, it feels a little funny to have a federates_with show up on an entry that isn't explicit to that entry. For example, one might try and update the entry to not have it, with no effect. Which brings up another point. Can entries opt-out of a global federates_with relationship?

[amoore877]

Can entries opt-out of a global federates_with relationship?

I think this would have been the main (perhaps retroactive) reasoning for having federation relationships be per entry up to now.

IMO the biggest pain point/use case to think about for this is:

• Let's say a domain X federation has been global up to now. There are thousands, tens of thousands, or more unique workload entries that get this relationship for free.
• New workload foo is coming up soon, and operators determine that foo should not federate with X.

There are two possible paths I see:

• invent opt-out, so now we have brought back the management overhead of needing to set federation relationships for different classes of entries like foo
• remove the "globalness" of X, and update all existing entries with the explicit federation, again now brining back management overhead

If we're likely to still need to perform management of federations, I don't know how much extra value an implicit relationship brings. I think this sort of management belongs not in SPIRE itself but with SPIRE registrants, which should be in charge of knowing what federation relationships entries need and what convenience code/list might exist on their end for global relationships.

We have received many questions and comments in the past relating to pain around having to specify which workloads federate with which trust domains

Without having seen precise user stories in the linked issue, I'm not entirely convinced that managing federation relationships is a lot of overhead. Do we have examples where this is painful? Whether a SPIRE registrant is a human using scripts or an automated service, "global" relationships should already be extracted out to some common functionality for re-use.

[dennisgove]

Is this a situation where a new plugin type might be useful? Similar to the SVID Field Customization plugin discussed in issue #3253, the plugin(s) could be executed when building the list of federated trust domains for an entry. This would allow users to support their preferred rules for this.

The project could provide default implementations for common use-cases, including one implementing the current logic.

[esweiss]

Looking for a group of trust domains that a WL would federate with. The groups could be modified and every WL that uses it would have its federations updated automatically.

[esweiss]

@azdagron Should I open a new issue for the use case above? Both HPE and Bloomberg want this.

[azdagron]

Yes, feel free to open an issue. Please add the relevant bits from the discussion above that propose the new behavior as well as a link to this issue. We can hash out the proposed approach there.

[github-actions[bot]]

This issue is stale because it has been open for 365 days with no activity.

[github-actions[bot]]

This issue was closed because it has been inactive for 30 days since being marked as stale.

[kfox1111]

Re-opening due to issue #5797

For users of the delegated api, they need to be able to fetch all the federated bundles that their delegates may need. The bundles are not included in the delgated api calls directly.

So, currently you need to add every possible federated name to the federates_with option of the workload being the delegate. That can be quite burdensome. Some way to flag it as '*' so that all bundles get pushed would be very useful.

[punmechanic]

This feature would be useful in some scenarios for us where a workload might not be interested necessarily in the precise identity of the SVID it is receiving, just that the workload is identified by a SVID that is either within its domain or a domain it trusts.

Needing to specify every trust domain a workload might authenticate with means that workloads that may authenticate with many trust domains need to have multiple entries and need to have bespoke code that determines an entry to select at any time if the recipient service must identify itself to some other service. The -hint flag assists in this.

This is not a very high burden, since any workload that is likely to authenticate in this way is likely going to want some user land logic anyway - but it would be nice if it could be made easier for workloads that really do not care about who they are talking to.

[rturner3]

It would be good to open a new issue with a design proposal for this problem, as it's been a long-standing pain point in the project.

Another idea about how this could be solved that was discussed in a contributor sync call was to define the concept of a Federation Group, which can be used to assign a group of federated bundles with a set of workloads.