This repository has been archived by the owner on Jul 26, 2022. It is now read-only.
Add 'dataFromLiteral' to ExternalSecret API #790
Closed
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.
I have a use case where I need a Kubernetes secret which contains a file
meant to be mounted to a container. In this file there is sensitive data
so it must be templated using the
spec.template.stringData
functionality. Within this file there is also recurring, non-sensitive,
data that would benefit from being templated.
More specifically, I had a dozen references to a GCP project ID which
would need to be hard coded in that many locations.
I tried to supply this within the
spec.template.stringData
, butexpectedly, that data is not part of the map which renders the template;
only
spec.data
andspec.dataFrom
are merged for that.It would be possible to use Helm to fill Golang templates within the
lodash template, however, if feels like a bad practice to have 2
templating patterns operating on the same text.
This led me to introduce the
dataFromLiteral
key-value pairing for theabstract kvbackend so all backends can template non-sensitive data along
side their sensitive, cloud secrets.