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

Add new secret store providers #10

Open
4 tasks
ramizpolic opened this issue Sep 4, 2023 · 2 comments
Open
4 tasks

Add new secret store providers #10

ramizpolic opened this issue Sep 4, 2023 · 2 comments
Labels
kind/enhancement Categorizes issue or PR as related to an improvement. lifecycle/keep Denotes an issue or PR that should be preserved from going stale.
Milestone

Comments

@ramizpolic
Copy link
Member

ramizpolic commented Sep 4, 2023

Goal

Currently we only support Vault by HashiCorp as a secret store provider. It would be beneficial to add additional providers, namely:

@sagikazarmark
Copy link
Member

Would it make sense to create a batch provider that fans secrets out to multiple providers?

Similarly, would it make sense to try to read from multiple sources (ie. if not found in store A, try store B).

Not sure these make sense or should be a priority, but it's something to consider.

We can wait for feedback from the community to see if someone needs this behavior.

@ramizpolic
Copy link
Member Author

We can certainly add support for that, but I think it will bring more complications than benefits (validation, handling collisions, tracking changes,...). I think it makes more sense to add support for N-to-1 syncs (N sources, 1 dest) to keep things simpler and cleaner. This way, each sync job would uniquely identify a destination store.

Rather than creating a provider that does this, this could be enabled on the API level itself. Consider this sync plan:

source: main-source
dest: main-dest
plan: 
  - secret:
      key: "from-main"
  - secret:
      key: "from-override"
      source: override-source

This is definitely something we want to have at some point, but for now, it is not a priority.

@ramizpolic ramizpolic self-assigned this Oct 10, 2023
@ramizpolic ramizpolic added this to the v0.2.0 milestone Oct 10, 2023
@github-actions github-actions bot added the lifecycle/stale Denotes an issue or PR that has become stale and will be auto-closed. label Dec 10, 2023
@ramizpolic ramizpolic removed the lifecycle/stale Denotes an issue or PR that has become stale and will be auto-closed. label Dec 12, 2023
@github-actions github-actions bot added the lifecycle/stale Denotes an issue or PR that has become stale and will be auto-closed. label Apr 21, 2024
@csatib02 csatib02 added kind/enhancement Categorizes issue or PR as related to an improvement. and removed lifecycle/stale Denotes an issue or PR that has become stale and will be auto-closed. labels Apr 21, 2024
@ramizpolic ramizpolic removed their assignment Jun 11, 2024
@github-actions github-actions bot added the lifecycle/stale Denotes an issue or PR that has become stale and will be auto-closed. label Aug 11, 2024
@csatib02 csatib02 added lifecycle/keep Denotes an issue or PR that should be preserved from going stale. and removed lifecycle/stale Denotes an issue or PR that has become stale and will be auto-closed. labels Aug 11, 2024
@bank-vaults bank-vaults deleted a comment from github-actions bot Aug 11, 2024
@bank-vaults bank-vaults deleted a comment from github-actions bot Aug 11, 2024
@bank-vaults bank-vaults deleted a comment from github-actions bot Aug 11, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
kind/enhancement Categorizes issue or PR as related to an improvement. lifecycle/keep Denotes an issue or PR that should be preserved from going stale.
Projects
None yet
Development

No branches or pull requests

3 participants