You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
While working through some of the issues at fixing rebootstrapping (#4624), one standalone piece poped of discussions.
I would like to be able to have custom, TrustBundleSource plugins.
There are currently 2 implemented in spire-server itself. Lets call them, fetch_from_file and fetch_from_single_url.
I can think of at least three more basic ones, without thinking a lot about it:
Give it a list of URLs and require a majority to respond with the same bundle, and use the majority opinion. This would allow (re)bootstrapping from various cloud providers without completely trusting any one provider.
A break glass one used as a last resort to recover a large number of agents in case of great failure, where it points at an untrusted server (http) and the bundle is signed with a pgp key.
call to the kubernetes apiserver with kubernetes in cluster credentials to fetch the bundle directly from the apiserver
Some of these could be started out of tree and then merged in as their use is proven reliable/useful.
But it would also provide a base for more complex plugins, such as policy aware plugins and/or aggregate plugins.
For example,
when in a spire-ha-agent setup, the trust bundle is synced between independent spire-servers. If side A is still functioning but side B needs to (re)bootstrap, it could use side A's trust bundle record for side B to (re)bootstrap in a completely trusted way.
But, if both side A and slide B have lost trust, then a different mechanism would be needed. so some complex TrustBundleSource plugin that can fail between more preferred and less preferred (re)bootstrapping plugins using some policy would be needed.
Keeping this all in a plugin and potentially out of tree while the design is iterated on and proven out would really help progress.
So, alll this to say, I think we want a TrustBundleSource plugin type.
The text was updated successfully, but these errors were encountered:
Rough idea is, provide the trust domain for which bundle to fetch, along with some metadata about what it might be used for, for more complicated plugins to be able to use.
While working through some of the issues at fixing rebootstrapping (#4624), one standalone piece poped of discussions.
I would like to be able to have custom, TrustBundleSource plugins.
There are currently 2 implemented in spire-server itself. Lets call them, fetch_from_file and fetch_from_single_url.
I can think of at least three more basic ones, without thinking a lot about it:
Some of these could be started out of tree and then merged in as their use is proven reliable/useful.
But it would also provide a base for more complex plugins, such as policy aware plugins and/or aggregate plugins.
For example,
when in a spire-ha-agent setup, the trust bundle is synced between independent spire-servers. If side A is still functioning but side B needs to (re)bootstrap, it could use side A's trust bundle record for side B to (re)bootstrap in a completely trusted way.
But, if both side A and slide B have lost trust, then a different mechanism would be needed. so some complex TrustBundleSource plugin that can fail between more preferred and less preferred (re)bootstrapping plugins using some policy would be needed.
Keeping this all in a plugin and potentially out of tree while the design is iterated on and proven out would really help progress.
So, alll this to say, I think we want a TrustBundleSource plugin type.
The text was updated successfully, but these errors were encountered: