-
Notifications
You must be signed in to change notification settings - Fork 9
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
Feature/secret override #154
Conversation
- Configured Secrets to use scoped releases
…object-management-service into feature/secretOverride
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
StringData is not a good design pattern. I do see the current misalignment concern with the overrides not being base64 encoded, but this should be done via a proper string operation and pipe instead of depending on StringData. As it is implemented right now, this would work for the override, but this would double encrypt the default generated password values instead, leading to unintended results.
I'll be taking a look at this and doing parallel adjustments to the helm chart to compensate for the issue.
Renames variables in secrets template to be more consistent with purpose Signed-off-by: Jeremy Ho <[email protected]>
Superceded by #158 |
Description
Refactored Secret objects to use stringData instead of Data as field. This prevents base64 error when trying to pull data into the secret that may not be base64 (such as usernames).
Types of changes
Refactor w/ encryption side effects (should make Secrets work as intended).
Checklist
Further comments
Tested with manual helm install, and NOT piping secrets to | base64.
This wasn't a tested workflow during the original PR (was feeding test data to base64, overlooking the usual flow of just placing stringData into the secret)