support for annotation based secret generation

[jstrachan]

we found when making charts that often they require secrets to be imported or created and sometimes secrets are shared between charts.

e.g. when using Gerrit, Jenkins and SonarQube we need to share public keys to Gerrit for things like Jenkins and SonarQube which have their own generated/imported public/private keys. Or to install our full CI / CD system so it can do real releases to github, maven central and docker hub we need to import our real SSH & GPG keys.

So we came up with a simple set of annotations we could put onto our charts: https://github.com/fabric8io/fabric8/blob/master/docs/secretAnnotations.md

which a tool can then process to import (if they are on disk) or generate Secrets if they don't exist as charts are installed. Then users can install/setup the secrets however they like before you install things; otherwise the install just works and worst case you get auto-generated secrets in each environment.

Up to now we've been using the gofabric8 secrets command to do this. e.g. here's the code... https://github.com/fabric8io/gofabric8/blob/master/cmds/secrets.go#L84

we basically iterate through all installed OpenShift Templates and then create or import from the file system any secrets for the annotations.

It would be pretty simple to do the same thing inside helm; that just before the chart is uploaded we iterate through all the resources in a chart (Replication Controllers really to look at the PodTemplates) and look for these annotations and if so lazily create any secrets.

Before I submit a PR I just wanted to check if you were happy with this general approach.

We could leave the secret generation as a separate CLI step in helm; then we could add a 'pre install command' into the charts to install gofabric8 if its not already and then just run gofabric8 secrets on the charts before they are uploaded.

Though secret generation sounds like its going to be so common for any vaguely secure chart - and the code is so simple; it does feel like we should just add native support for secret generation/import at chart installation/update time?

[technosophos]

If you take a look at plugins/sec, we were just starting down the road of making it easy to generate secrets (as a separate step).

I really like the idea of using annotations to indicate that a secret needs to be generated. It means we don't even have to parse the full RC/Pod to figure out what we need to generate.

We've gone back and forth about hooks like pre/post install, and for the time being we decided to hold back. I would really like to see a separate issue on that so that we can all discuss. We're learning a lot about how Helm uses are trying to use Helm. I think that'd be a great place to get some feedback.

In summary, my view is:

• +1 on the annotations approach.
• +1 on a command for adding secrets. We should figure out how best to do this.
• And we should discuss pre-install hooks on an issue

Would also like to hear from @gabrtv

[jstrachan]

@technosophos assuming we went down the road of detecting annotations at installation time, do you think we should use helm install command line arguments to enable/disable secret generation?

I'd personally prefer the default OOTB command to Just Work (tm), though I guess the default could be to not create any secrets if it finds a missing secret and output something to the user. e.g.

$ helm update
$ helm repo add fabric8 https://github.com/fabric8/charts.git
$ helm install fabric8/cd-pipeline

Helm cannot install cd-pipline as the following secrets are missing

    jenkins-ssh
    jenkins-gpg
    sonarqube-ssh

Please specify the --create-secrets option to automatically create secrets.
This command will look in the current directory for secrets to import or use --secrets-dir to specify another folder

[technosophos]

I do like that idea. It feels right to me that we handle secrets in install. Otherwise, what we're going to end up with is many frustrated admins and a bunch of insecure defaults.

[jstrachan]

I've closed the previous PR and raised a new leaner meaner rebased & cherry picked PR: https://github.com/helm/helm/pull/326