Open ipedrazas opened 7 years ago
Drone has built-in Vault support now, FWIW.
Oh, that's awesome!
The use case was slightly different: having the secrets in Vault and having Kubernetes integrated with Vault means not having to worry about secrets being leaked during CI/CD.
I'll take a look anyway!
We use VaultController
in our clusters and our Charts get secrets using secretClaims
- so we never expose secrets in Drone.
However, we do have scenarios where the helm release requires different user defined values per helm deploy, and current way of passing key value pairs in the drone pipeline is too verbose.
For this, we are adding skuid/helm-value-store support, which is strictly for non-secrets. (and tied into AWS DynamoDb atm)
I will open a PR, but doubt the functionality would benefit the majority of the user base of this plugin, thus I wonder if this should be split off in a different plugin?
Actually, this has been a long time standing issue in my backlog. Truth is that if Helm supports plugins, we should make this drone plugin
to support Helm plugins
.
I should approach it that way, idd
helm value store does require a specific plugin config (yaml file)
how would the drone-plugin pull that config
scrap that - I need to re-read https://github.com/kubernetes/helm/blob/master/docs/plugins.md
but it would eat CI time if plugins can't be baked into the drone-helm plugin image
Ideally, we want to have secrets defined in Vault.
The plugin could receive a vault token/host pair and pull the secrets from there.