Enable connections and clusters

Connections give the model tools from MCP servers, Slurm clusters and Kubernetes clusters. What people see is in Connections. This page covers what you set up as the operator.

Choose what people can add

Connections are on whenever Chat has a gateway signing key. OBLETH_CHAT_CONNECTIONS narrows them:

Restart Chat after changing it. Connections saved under a wider setting are kept but hidden, and their tools aren't offered.

Tokens belong to people

A call to a connection always carries one person's token, so the server's own permissions decide what that person may do:

• Someone's own connection uses the token they entered.
• A shared Slurm or Kubernetes cluster never has a token of its own. The administrator stores its address; each person adds their own token, and until they do, the cluster stays out of their chats.
• A shared MCP server uses the administrator's token for everyone, unless it's set to Each person adds their own token. Then it works like a shared cluster. Use that setting for any server whose tokens are personal, such as one that submits jobs as the caller.

Tokens are checked when they're saved, encrypted, and never shown again.

Auto mode

By default a tool that may change something waits for the person's Allow. A person can switch a chat to Auto mode, where every tool runs without asking; research chats start that way so long runs don't stall. Calls still carry that person's own token. Set OBLETH_CHAT_AUTO_MODE=off to remove the switch for everyone; chats already in Auto mode then ask again.

Share an MCP server

1. 1

   Add it

   In Settings › MCP servers, choose Add MCP server and enter its URL. Shared servers may use http and internal addresses.

2. 2

   Share it

   Tick Share with everyone. To have each person use their own token, also tick Each person adds their own token.

3. 3

   Give it a token to list tools

   Enter a token if the server needs one to list its tools. With personal tokens, this token is used only for that. Chat connects once, lists the tools and keeps the list until you choose Refresh tools.

People then see the server under Shared with everyone, with Add your token when it needs theirs.

Share a Slurm cluster

slurmrestd must run with rest_auth/jwt. REST API versions v0.0.40 to v0.0.42 work.

1. 1

   Add the cluster

   In Compute › Clusters, choose Add a cluster, then Slurm cluster. Enter the slurmrestd URL without /slurm/v0.0.x, and tick Share with everyone.

2. 2

   Each person adds a token

   Each person chooses Add your token, enters their Slurm user name and a JWT. Chat checks it against slurmrestd before saving it.

   # On a login node, as yourself
   scontrol token lifespan=2592000
   # Paste the part after SLURM_JWT=
   

   Jobs then run as that Slurm user.

Share a Kubernetes cluster

1. 1

   Add the cluster

   In Compute › Clusters, choose Add a cluster, then Kubernetes cluster. Enter the API server URL and, for a private CA, the certificate from certificate-authority-data (base64-decoded). Tick Share with everyone.

2. 2

   Give each person an identity

   Each person needs their own token: a service account per person, or a token your identity provider issues. Bind it to what they may do.

   kubectl create namespace alice
   kubectl -n alice create serviceaccount alice
   kubectl -n alice create rolebinding alice-edit --clusterrole=edit --serviceaccount=alice:alice
   kubectl -n alice create token alice --duration=720h
   

3. 3

   Each person adds a token

   Each person chooses Add your token and pastes it, with a default namespace if they like. Chat checks it with a SelfSubjectReview and shows whom it acts as.

Network access

• Chat's own pods must reach each server. Under a NetworkPolicy, allow egress to slurmrestd, the Kubernetes API servers and MCP servers.
• People's own connections must use https and public addresses. Chat resolves the host itself and refuses loopback, private and link-local ranges. OBLETH_CHAT_CONNECTIONS_ALLOW_PRIVATE=true lifts that for development only.
• Shared connections, added by administrators, may use http and internal addresses.

How tokens are stored+

• Tokens are encrypted at rest with XChaCha20-Poly1305. The key is derived from the gateway signing key, so no other secret needs provisioning. Replacing that key makes saved tokens unreadable, and people enter them again.
• A person's token for a shared connection is bound to both the connection and their account, so it can't be decrypted for anyone else.
• Removing a shared connection deletes everyone's tokens for it. Removing your own token takes that connection out of your chats.
• Creating, changing and removing shared connections is recorded in Settings › Administration › Activity.
• Each account can have up to 20 connections, and there can be up to 20 shared ones.