create k8s secrets for DEIS_SECRET_KEY and DEIS_BUILDER_KEY

[bacongobbler]

These two keys are auto-generated by the controller on boot, then templated out in the controller and the builder using confd. We should plug into the kubernetes secrets API instead, if possible.

[rimusz]

yes, we should certainly use kubernetes secrets for that

[bacongobbler]

I guess my only open questions for that is:

a) how can we generate the secret key like we do today with openssl -rand? I think secret manifests are fairly static so that would have to get baked into helm somehow.

b) is there any technical benefit to moving from etcd/confd? The legacy way of configuring the components will still exist in v2 and I can't think of any reason where kubernetes secrets beat good ol' etcd/confd. "Don't fix what isn't broken" and all that...

[technosophos]

For (a), I was playing with helm sec --password, which now generates long random strings and populates secrets files with them. It's a first stab at solving exactly that problem.

For (b), nominally the reason is security. I think the longer-view reason is that we want to push as much stuff into the k8s storage as possible so that we can reduce reliance on extra tools. If someday we can run without confd or without etcd, that's a move toward architectural simplicity. And I think we want that.

[helgi]

Looks like DEIS_SECRET_KEY does not need to be ported over, it was used by Ceph. Is there an alternative usage for it I am not aware off?

[helgi]

helm/helm#282 could help solve this problem and it already has a PR that needs some love / reviewing

[bacongobbler]

I thought DEIS_SECRET_KEY is the secret key used by django: https://docs.djangoproject.com/en/1.9/ref/settings/#std:setting-SECRET_KEY

[helgi]

It is - we need to keep it for sure. I noted that in another place but forgot here

[helgi]

https://github.com/deis/charts/pull/67