LocalAI icon indicating copy to clipboard operation
LocalAI copied to clipboard

draft feat: roles for api keys

Open dave-gray101 opened this issue 9 months ago • 3 comments

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 are ui 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.

dave-gray101 avatar May 14 '24 06:05 dave-gray101

Deploy Preview for localai canceled.

Name Link
Latest commit 6b9170300daf7025a06c12d2d7e188b4a129e0b0
Latest deploy log https://app.netlify.com/sites/localai/deploys/664426ba4ddcec0008112af8

netlify[bot] avatar May 14 '24 06:05 netlify[bot]

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.

mudler avatar May 14 '24 07:05 mudler

I agree with Mudler. I don't like the idea of breaking existing API_KEYS for this.

cryptk avatar May 14 '24 10:05 cryptk