feat: add support for external secrets to the opensearch-sync service#828
Draft
feat: add support for external secrets to the opensearch-sync service#828
Conversation
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
This experimental change adds support for external secrets to the opensearch-sync service.
External secrets support defaults to disabled, but you can enable it via:
If external secrets are enabled, then the chart will no longer template a
Secretobject for the opensearch-sync service, and instead expects externally managedSecretobjects to be created for it to consume.The current chart errs on the side of a single source of truth for secrets shared between services. So, for example, the opensearch-sync service consumes the
API_DB_PASSWORDout of theapi-dbsecret, and theKEYCLOAK_CLIENT_SECRETout of thekeycloaksecret. The external secrets support in this PR defaults to the same design of having multiple services reference a single secret, but if a different design is easier to use for external secrets then that can be changed. For example maybe a single secret per service with duplicated secret values when they are shared between services makes sense, since the external secret store is the actual source of truth??Also I assume you would need something like Stakater reloader to restart pods when secrets updated.
Feedback welcome. Including just closing this if you don't actually want to support external secrets this way 😄