I'd like to have sensitive data like password, api-keys, ... stored not directly with the DB entity which it belongs to, but instead store it in a separate vault.
Example: Storing a new llm provider with api-key (latter one is the piece of sensitive information):
- the UI for the llm provider supports adding the Name, URL, etc. for the LLM Provider
- the UI does NOT offer to directly configure the api key.
- the UI instead offers to pick an existing vault key OR it offers to create a new vault key
- if a new vault key should be created, the UI can do this in place, or just redirect to the vault UI
- new or old; the result is the same: the ID for the vault entry
- instead of the api-key, the valut-key-id is stored along with the LLM provider informaiton
What a vault entry should have
- id
- type: free string which can be used to define what type of information the vault entry is like 'llm-provider', ...
- name: something to be displayed in the UI (e.g. in a dropdown)
- secret: the actual password, key, ...
vault entries could belong to users, (groups), global, so that means probably a api-key for a llm-provider is more of global nature as some private vault entry for a user could be private to the user.
There is also a separate UI in the admin and user-settings area, which lists all the vault entries.
I'd like to have sensitive data like password, api-keys, ... stored not directly with the DB entity which it belongs to, but instead store it in a separate vault.
Example: Storing a new llm provider with api-key (latter one is the piece of sensitive information):
What a vault entry should have
vault entries could belong to users, (groups), global, so that means probably a api-key for a llm-provider is more of global nature as some private vault entry for a user could be private to the user.
There is also a separate UI in the admin and user-settings area, which lists all the vault entries.