LocalAI
LocalAI copied to clipboard
draft feat: roles for api keys
Roles
This was prepared as a quick option in case we want a demo. Currently working on an improved version using casbin for permanent version - will replace this PR when finished.
initial version of a role system for api keys, allowing users to be granted more finely grained access to specific parts of localai
Some notes:
-
adds a new configuration file that is shipped by default named
roles.json
- exists to give sane combinations of endpoints easy names, though technically this can be skipped. -
changes how api_keys are interpreted. Now it's a map of api key ==> slice of endpoints whenever api_keys.json is evaluated (including at the initial program load) we shake out the endpoint slice - reducing roles to raw endpoints and deduplicating
-
the old format for
api_keys.json
still works... and is interpreted as if all keys areui user
-
a fake api key of
"_"
represents the set of endpoints that should be authorized for unauthenticated users. Currently this also expands the access of all authenticated users - so"_"
serves as the single default set of allowed to all endpoints. Let me know if anyone can think of a reason to have the complication of two distinct lists
I'd appreciate help testing every possible use case... as well as ideas for ways to improve roles.json
such as different groupings or things I've missed
Docs will need to be updated to match this, but I want to do that in a separate PR for organizational reasons.
Deploy Preview for localai canceled.
Name | Link |
---|---|
Latest commit | 6b9170300daf7025a06c12d2d7e188b4a129e0b0 |
Latest deploy log | https://app.netlify.com/sites/localai/deploys/664426ba4ddcec0008112af8 |
I really think this adds a complexity layer that should be out of LocalAI - ideally there are reverse proxy that can work with this. What is the use-case at hand here?
I'm also ok to merge it - but it should at least use another argument to not break current API_KEY
usage - let's keep it as is and map it to have access to all the API endpoints.
I agree with Mudler. I don't like the idea of breaking existing API_KEYS for this.