Protecting persistent-worker pool token

[cevich]

I'm wanting to run public cirrus tasks on bare-metal[*]. This seems to require(?) executing the task's script commands as the same user that executed cirrus worker run. If the pool token is passed on the command-line, it's easily recovered (e.g. from ps output) by a CI script. This is less than desirable. However, if I instead put the token into a YAML config. for the worker, is there any guarantee the worker will continue functioning properly (now and in the future) if I then rm the config file (to hide the token) after the worker is started?

---

[*]Note: I realize using none "isolation" carries many risks. Leaking the worker token is probably not a world-ending event. Removing the config. file also isn't perfect, but maybe slightly better than leaving it in the clear.

[fkorotkov]

Theoretically worker doesn't need the registration token after a registration is performed and it has a session token. The tricky part in this scenario will be how to handle restarts and receive a registration token again.

Which environment are you running the worker in? It might be an option to add --token-stdin option to cirrus worker run so you can handle passing it on your end.

[cevich]

The tricky part in this scenario will be how to handle restarts and receive a registration token again.

For our setup, I'm thinking we don't need to restart it. Rather we'll just rebuild the host, perhaps daily.

Which environment are you running the worker in?

In my case it's the M1 (arm) Macs in Ec2. I'm running it as a non-admin user through sudo su -l <user> -c "cirrus worker run ...". A stdin token option would work great actually. If it's easier, a --token - form would be fine as well.