The buildpack images will not have access to NFS. For the initial stages, we've discussed providing just replica.my.cnf for all web tools that access the wiki replicas without needing full blown secrets management.
maintain-dbusers is the script that already creates the credentials, so if it takes care of putting it in a k8s secret then it simplifies the rotation process too.
| Status | Subtype | Assigned | Task | ||
|---|---|---|---|---|---|
| Stalled | LucasWerkmeister | T320140 Migrate wd-shex-infer from Toolforge GridEngine to Toolforge Kubernetes | |||
| Stalled | matmarex | T319707 Migrate dtcheck from Toolforge GridEngine to Toolforge Kubernetes | |||
| Open | None | T320062 Migrate steve-adder from Toolforge GridEngine to Toolforge Kubernetes | |||
| Open | None | T320011 Migrate rfa-voting-history from Toolforge GridEngine to Toolforge Kubernetes | |||
| Open | dcaro | T194332 [Epic] Make Toolforge a proper platform as a service with push-to-deploy and build packs | |||
| In Progress | dcaro | T267374 [tbs.beta] Create a toolforge build service beta release | |||
| Open | None | T265691 [tbs.maintaindbusers] Update maintain-dbusers to create a k8s secret with replica.my.cnf to be used by buildpack images | |||
| Duplicate | None | T291409 [NFS] Update maintain_dbusers so it can run on a VM |
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.