[litellm] Add API key input

[dlqqq]

Problem

Users need to be able to add API keys from the UI in #1426.

Furthermore, we should probably store these in a file separate from the config.

Proposed Solution

• Add the API keys form section back to the AI settings.

• Read API keys from the environment variables passed to the jupyter-lab process. These should be listed in the UI but should also be read-only.

• Allow users to add API keys. Upon doing so, they should be saved in a new/existing .env file at the root of the current workspace.

• Read API keys from the .env file. These should be listed in the UI and be made editable.

• Make sure to create a .gitignore file containing .env automatically to ensure users don't accidentally commit the .env file to the repo. Add .env to .gitignore if the file already exists.

Additional questions

1. Are there any new risks with this approach? We are now saving secrets in a local .env file instead of the global config under the Jupyter data directory. We are moving towards having local config files because we want to allow different Jupyter AI configurations in different directories.

2. Should we use a secrets manager instead? What is the status of that work? cc @brichet @jtpio

   • [v3-future] Enhance and generalize secret/key management? #1237

[brichet]

Should we use a secrets manager instead? What is the status of that work?

The secrets manager is still experimental but usable safely AFAIK.

How it works ?

• the secrets manager uses a secrets connector to get/set secrets. A secrets connector is basically a class that implements IDataConnector, which means that it can fetch secrets form a rest API for example.
• an input in a form can be "attached" to the manager (using a namespace and id). When an input is attached, the manager will try to fetch a secret by providing the namespace/id to the connector. If a value is retrieved, the input is filled with it. If the user updates the input value, the manager will try to save that new value, using the connector.

What it doesn't do ?

• there is currently no UI to set all the secrets, it is only a mechanism to associate an input to a secret
• the secrets are not shared with the kernel, secrets are only usable in the frontend

Why is this secure ?

• only one connector can be associated to the manager. If several connectors try to be associated, the manager is locked. This is to prevent "malicious" extensions from being able to add their own connector.
• a plugin can only register one namespace (its ID), and a namespace can only be registered once, again to prevent possible leeks from malicious extensions. When the namespace is registered, a unique token is returned, and must be provided for any action using this namespace (attach input, get or set secret).

Here is an example of registering a namespace from a plugin.

[dlqqq]

Thanks for the reply Nicolas. It seems like this may have to wait until the next major release of Jupyter AI to be ready for our use. We need to give users a way to specify API keys from the frontend, and we need to be able to access them from the backend.

We've implemented our own Secrets UI & REST API in #1439. We will use environment variables and a .env file to store secrets. Closing this issue.