feat: existingSecrets support, separate-of-concerns enhancements, custom secret field names support #186
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
- Added new pre-defined names to helpers to introduce new secrets to deployment to separate concerns - Implemented the ability to specify existing secret field keys if not default - Added conditions to checksum annotations in deployment and cronjob if existing secret is used instead of default one - Bumped chart version to 3.1.0 - Updated README to reflect values structure changes
- Fixed a bug found in pull request twuni#185 where if an existing secret was defined, its data wasn't mounted to the deployment and env vars referencing to the auth credentials location inside containers were not created - Fixed multiple whitespace and indenation issues during templating when specifying custom fields for existing secrets
Gridness
changed the title
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 pull request is similar to #185 but it takes things a bit further: it adds the existing secret support and also allows to specify field names in secrets if those are not default. Updates also include separate-of-concerns features, allowing to specify additional secrets containing only credentials for external services. This makes secret management more precise and customizable if the user prefers to work with external secrets. Documentation, templates and values have all been updated to reflect changes. Also fixed a bug found in #185 where if an existing secret was defined, its data wasn't mounted to the deployment and env vars referencing to the auth credentials location inside containers were not created. Also some missing fields in documentation were added
Azure and Swift values were named
secretRefinstead ofexisingSecretto make naming consistent with already presentsecretRefvalue for S3 and proxy. At the same timeexistingSecretvalue forsecretswith authentication credentials was named this way because it was already requested to be named that way (see #58) and because many other helm charts use this name to allow users reference their own secrets instead of using generated ones, so this is a UX reasonImplements #58
Key Changes
secrets.existingSecretvalue invalues.yamland documented it inREADME, allowing users to use an external Kubernetes Secret resource with authentication data for docker registrysecrets.haSharedSecretKeyandsecrets.htpasswdKeyvalues tovalues.yamland documented them inREADME, allowing users to specify field names defined insecrets.existingSecret. If none is set, they default tohaSharedSecretandhtpasswdrespectivelysecrets.azure.secretRefvalue invalues.yamland documented it inREADME, allowing users to use an external Kubernetes Secret resource with authentication data for azuresecrets.azure.accountNameKey,secrets.azure.accountKeyKeyandsecrets.azure.containerKeyvalues tovalues.yamland documented them inREADME, allowing users to specify field names defined insecrets.azure.secretRef. If none is set, they default toaccountName,accountKeyandcontainerrespectivelysecrets.swift.secretRefvalue invalues.yamland documented it inREADME, allowing users to use an external Kubernetes Secret resource with authentication data for swiftsecrets.swift.usernameKeyandsecrets.swift.passwordKeyvalues tovalues.yamland documented them inREADME, allowing users to specify field names defined insecrets.swift.secretRef. If none is set, they default toswiftUsernameandswiftPasswordrespectivelyproxy.usernameKeyandproxy.passwordKeyvalues tovalues.yamland documented them inREADME, allowing users to specify field names defined insecrets.existingSecret. If none is set, they default toproxyUsernameandproxyPasswordrespectivelyTemplate and Resource adjustments
secret.yamlto only create a new Secret ifsecrets.existingSecretis not set, preventing duplicate or unnecessary secretsdeployment.yamlandcronjob.yamlto only annotate with the secret checksum when a new secret is created, ensuring correct rolling updatesDocumentation updates
READMEwith new values entries added with this pull request. See Key ChangesREADMEforsecrets.haSharedSecretandsecrets.azure.*Version Bump
3.1.0to reflect new features