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
We are thinking about integrating SPIRE and spire-controller-manager in one of our products. One thing that we don't like about it is the fact that bundles are shared between trustdomains via mutual network requests to download each other's bundle. In highly regulated environments we want to keep network requirements as small as possible.
Currently the ClusterFederatedTrustDomain is handled like this as of my understanding:
ClusterFederatedTrustDomain is read by spire-controller-manager
spire-controller-manager creates a federationRelationship through the trustdomain-api
trustdomain-api saves a federatedTrustDomain (equal to federationRelationship) and the bundle
spire-servers internal task manager runs bundleRefresher frequently for each federatedTrustDomain
bundleRefresher reads localBundle and foreignBundle and saves forgeinBundle to the database if it was updated
The clusters own bundle is rotated by spire-server frequently through internals.
Proposed Changes
CRUD ClusterFederatedTrustDomain
make bundleEndpointUrl and bundleEndpointProfile OPTIONAL
IF no bundleEndpointUrl is given, only create a bundle in the datastore
on each update/ delete to the ClusterFederatedTrustdomain CR act accordingly
Expose clusters own bundle to make available for a gitops tool
every x minutes, read servers own trustbundle
compare with configmap holding the current one and update / write it to the configmap if necessary
Please let me know what y'all think and if this would be valuable for the project.
tagging @azdagron since we had a very short chat about it in slack.
The text was updated successfully, but these errors were encountered:
We are thinking about integrating SPIRE and spire-controller-manager in one of our products. One thing that we don't like about it is the fact that bundles are shared between trustdomains via mutual network requests to download each other's bundle. In highly regulated environments we want to keep network requirements as small as possible.
Currently the ClusterFederatedTrustDomain is handled like this as of my understanding:
The clusters own bundle is rotated by spire-server frequently through internals.
Proposed Changes
Please let me know what y'all think and if this would be valuable for the project.
tagging @azdagron since we had a very short chat about it in slack.
The text was updated successfully, but these errors were encountered: