External Secret Integration for MCP Servers

[cloudnautique]

Problem:

Teams would like to leverage their existing secret store (Vault, AWS Secret Manager, etc) and credential operations with Obot.

Teams already have secret management solutions for their Kubernetes clusters. The solutions have mechanisms to place secrets into the cluster already, and would like Obot MCP servers to consume them.

Example Use Case

A multi-user Datadog MCP server needs a single API key. Anyone who logs in through the enterprise IdP and has access to the server via a Registry should be able to use it. The API key is managed in Vault and synced to the cluster by the Vault Secrets Operator — it should never be entered or stored in Obot.

Proposed Solution

Allow MCPServerCatalogEntry env var definitions to bind to pre-existing Kubernetes Secrets instead of requiring manual credential entry.

How it works:

Vault/AWS/ESO  ──creates & manages──>  K8s Secret (in Obot's namespace)
                                              │
                                    Obot references via secretKeyRef
                                    in the pod spec at deploy time
                                              │
                                              ▼
                                    K8s injects value into container

Obot never sees or handles the secret value. It places a secretKeyRef in the pod spec, and Kubernetes natively injects the value into the container at deploy time. The secret flows from the external store to the k8s Secret (via the operator) to the container (via kubelet) — Obot is just wiring the reference.

On a catalog entry's env var, a secret binding specifies the k8s Secret name and key to reference:

env:
  - name: Datadog API Key
    key: DD_API_KEY
    sensitive: true
    required: true
    secretBinding:
      name: datadog-creds      # k8s Secret name
      key: api_key             # key within that Secret
At deploy time, instead of resolving the value from the GPTScript credential store and creating an Obot-managed Secret, the k8s runner wires the reference directly into the pod spec:

env:
  - name: DD_API_KEY
    valueFrom:
      secretKeyRef:
        name: datadog-creds
        key: api_key

Kubernetes handles the rest. Obot never touches the value.

Configuration: Git Catalog Only (V1)

Discussion point: If any admin, or PUP/PUP+ user, can bind env vars to arbitrary k8s Secret names through the UI, there is only a single MCP namespace.

V1 proposal: Secret bindings can only be defined in git-managed catalog sync sources (YAML checked into a repo), not through the UI. This means:

Bindings are code-reviewed and version-controlled
Only people with commit access to the catalog repo can set them
Aligns with GitOps patterns that teams using Vault/ESO are already following
The UI shows "bound to k8s secret X" as read-only

vNext Proposal: scope registries to their own namespace and align Obot roles with secret selection.

Composites
No special handling needed. Composites are orchestrators of independently deployed component servers. Each component.