Now that we have a secrets management service (envvars service), we can make maintain-dbusers put in an envar with the credentials for the database access, that will allow a lot of tools to not need NFS at all and unblock the first NFS-less webservices.
We ended up creating 4 environment variables:
| Subject | Repo | Branch | Lines +/- | |
|---|---|---|---|---|
| replica_cnf_api: add envvars backend | operations/puppet | production | +443 -63 | |
| replica_cnf_api: refactor to use multiple backends | operations/puppet | production | +1 K -605 |
One option I just thought of is that the deploy mechanism (or even maintain-kubeusers) could copy the contents into a secret (which is encrypted at rest in our cluster) and then we could mount it into the pod like a file.
Having maintain-kubeusers do it seems nicer as it means the deploy mechanism doesn't have to have access to any secret stuff (I haven't fully reasoned about the security model of it yet though). Is there any overhead/risk to having maintain-kubeusers create all the secrets ahead of time?
There shouldn't be. The secrets are scoped to the namespaces and the only people who can see into them are people who can do so anyway via NFS. They are encrypted in etcd.
The ideal might actually be that the service that creates the credentials in the first place ("maintain-dbusers"...very creative naming conventions are hard) on NFS also creates the secrets in my mind because then they could both be rotated the same way. To do *that*, we'd have to give it a k8s certificate, but that's not hard. We have a script for it as long as the need for the cert and its rotation is added to the docs.
maintain-dbusers needs work this quarter anyway, so it might be a good time to consider adding a new function to create secrets in k8s (probably based on the webservice methods for interacting with it to avoid pip libraries on physical servers).
Sounds good to me.
maintain-dbusers needs work this quarter anyway, so it might be a good time to consider adding a new function to create secrets in k8s (probably based on the webservice methods for interacting with it to avoid pip libraries on physical servers).
Would it make sense to do this before or after that other work?
Maybe during? I'll check how bad it is :-D
It's tricky to test because the maintain-dbusers script is a PITA to test. The function to create the secrets is probably not going to be too bad to test.
Change 933973 had a related patch set uploaded (by David Caro; author: David Caro):
[operations/puppet@production] replica_cnf_api: refactor to use multiple backends
Change 936232 had a related patch set uploaded (by David Caro; author: David Caro):
[operations/puppet@production] WIP: replica_cnf_api: add envvars backend
Change 933973 merged by David Caro:
[operations/puppet@production] replica_cnf_api: refactor to use multiple backends
Change 936232 merged by David Caro:
[operations/puppet@production] replica_cnf_api: add envvars backend