search

Haidra-Org / AI-Horde

A crowdsourced distributed cluster for AI art and text generation
GNU Affero General Public License v3.0
1.03k stars 121 forks source link

'Worker-only' API key feature request #274

Open tazlin opened 10 months ago

tazlin commented 10 months ago

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 commented 10 months ago

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 commented 8 months ago

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

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 commented 8 months ago

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 commented 8 months ago

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