g-w should be able to not do user management (i.e. multi g-w is too complex)

[aerickson]

• For our productivity and to reduce complexity, we (RelSRE) prefer to keep all user configuration in Puppet. Multi g-w forces us to move our Puppet code for user configuration to shell scripts (run via the g-w config option that runs a script after user creation) that perform configuration on the dynamic host user.
  • We're willing to deal with occasional environment pollution in exchange for the simplicity and ease of configuration with a single user.
  • Moving to g-w multi it technically possible, but it is overly burdensome on our commplexity and time.
• A specific case where the complexity of a per-task user is not needed is in containerized workloads, see multi g-w is inappropriate for containerized workloads #6975.
• Simple g-w served that purpose for us, but has now been deemed insecure and deprecated.
  • We'd like a g-w that is secure, can do CoT, is supported, and doesn't do user management... a multi g-w that can use a static user.

[petemoore]

Is the user setup this?
https://github.com/mozilla-platform-ops/ronin_puppet/blob/aafed7cf0da01055a80c6ba167429f814d1d3385/modules/roles_profiles/manifests/profiles/cltbld_user.pp
Or is there other stuff too?

[aerickson]

That's part of it. We have additional bits for linux performance testing (disabling services, etc) and mac safaridriver testing (TCC database and Applescript stuff).

• I don't really want to discuss the technical feasibility... it is technically possible to do this in multi g-w via the various hooks and pre/post scripts (but it increases the complexity and time taken to perform configuration and maintenance).

For containerized workloads, doing user management doesn't make sense (#6975 was closed and redirected here).

[petemoore]

Fortunately this already exists as an (undocumented) feature. Generic Worker uses whichever user name/password is stored in next-task-user.json file, if it exists. So if you pre-generate next-task-user.json like this on the host before running Generic Worker, the task will run as cltbld user:

{
  "name": "cltbld",
  "password": "whatever-the-cltbld-password-is"
}

This file should only be readable as root user (or whatever Generic Worker runs as).

Make sure to set numberOfTasksToRun to 1 so that no new users get created for future tasks.

If that doesn't work, let me know!

[petemoore]

Note, we could move this config into the Generic Worker config file too, with e.g. something like:

"staticUser": {
  "name": "cltbld",
  "password": "whatever-the-cltbld-password-is"
}

Then you wouldn't have to explicitly set numberOfTasksToRun to 1, and the config would live with the rest of the Generic Worker config, and e.g. would be visible inside the Worker Pool definition.

The reason I suggested the above approach using next-task-user.json directly was mostly to unblock you if you want to try it now, as it should already be possible by using this undocumented feature.