Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Support Federation without direct (bi-dir.) Network Connection between spire-servers #133

Open
dherbrich opened this issue Apr 6, 2023 · 0 comments

Comments

@dherbrich
Copy link

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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

1 participant