'Worker-only' API key feature request

[tazlin]

Certain cloud hosting setups rely on trusting the host to not be a bad actor. Presently, this involves the possibility a worker's API key being extracted while the worker is running in these third party environments.

Implementing this feature request would allow the generation of 'worker-only' API keys (perhaps adapting the existing approach that is used with shared keys?), which would not work on any of the generate/interrogate or kudos transfer end points. (IE, could not be used to spend kudos), allowing workers to use their keys in these environments with less potential risk.

From this discussion on discord: https://discord.com/channels/781145214752129095/1081743238194536458/1143995718353293372.

[db0]

This will require me extending the shared keys to allow specifying roles for them. Will require a new table to hold sharedkey role enums per key

[Cubox]

I would see this feature as more of a dedicated "worker key" new type of API key. You would generate a new worker specific key, then upon using that key, it is linked permanently to a worker. This key only allows operations related to that worker (or maybe a group of workers for automated scripts?)

API routes will allow you to

• create a new worker API key
• obtain the API key of an existing worker
• reroll the API key of an existing worker (if compromised)

This allows for an user to have each worker using a dedicated API key, making sure that even if one is compromised, no harm can be done to other workers.

Limitations need to be implemented in the number of API keys and stale worker API keys to avoid the DB exploding in size

[tazlin]

I think as I noted in the opening post, a flavor of shared key would be sufficient in my view, so long as that 'worker api shared key' could only job pop and job submit or do the other worker related read-only operations, and perhaps with the additional restriction of doing jobs as a prespecified worker name.

[Cubox]

I was concerned about people being restricted by the amount of shared keys they can create if they want one per worker, but you could just have the max amount be normal amount + number of workers they own on their account and be fine