Use Secret Manager in Integrations

Use the Secret in an Integration

When adding or editing an integration, such as a Model provider, an MCP server, or a Guardrail, use one of the three options below in any API key or other sensitive field instead of pasting the raw value.

Using secret FQN in an integration API key field (example: OpenAI)

Option A: Create the secret in TrueFoundry, then add the secret FQN

Create the secret in a secret group in TrueFoundry, then use its fully-qualified name (FQN) in the integration.Format: tfy-secret://<tenant>:<secret-group>:<secret-key>Example: For tenant my-tenant, secret group openai-keys, and key OPENAI_API_KEY:

tfy-secret://my-tenant:openai-keys:OPENAI_API_KEY

Copy secret FQN from the secret group in TrueFoundry

For full steps on creating secret groups and adding keys, see Secret Management. TrueFoundry resolves the FQN at runtime and injects the value.

Option B: Use any existing secret in your secret manager directly

Use a secret that already exists in your secret manager. You do not create the secret in TrueFoundry—reference it by your secret store FQN and the path in your store.Format: <secret-store-fqn>::<path-to-secret-in-secret-manager>Example: If your secret store FQN is my-tenant:aws:my-aws-provider:secret-store:aws-ssm and the secret path is /tfy-secret/openai/api-key:

my-tenant:aws:my-aws-provider:secret-store:aws-ssm::/tfy-secret/openai/api-key

You can find the Secret Store FQN on Platform → Integrations, as shown below:

Secret Store FQN on Platform Integrations page

Option C: Use a Kubernetes secret for integrations auth data

Use a Kubernetes secret when you want the integration auth value to come from a secret mounted into the servicefoundry-server pod.

Self-hosted control plane only. This option is available only when you host your own control plane. It is not available on the TrueFoundry managed control plane.

How it works:

Create a Kubernetes secret in the namespace where your TrueFoundry control plane is installed.
Set servicefoundryServer.tfyK8sSecretName in your Helm values to that secret name.
Upgrade your TrueFoundry Helm release.
In the integration field, reference a key from that secret using tfy-k8s-secret://<KEY_NAME>.

Set the Helm valueThis field is documented in the TrueFoundry chart’s values.yaml.

servicefoundryServer:
  tfyK8sSecretName: provider-integration-secrets

When this value is set, the secret is mounted into the servicefoundry-server pod at /opt/truefoundry/tfy-k8s-secrets.Create the Kubernetes secret

secrets.yaml

apiVersion: v1
kind: Secret
metadata:
  name: provider-integration-secrets
  namespace: truefoundry
type: Opaque
stringData:
  HASHICORP: "replace-with-your-vault-token"
  GITHUB_APP_PRIVATE_KEY: |
    -----BEGIN PRIVATE KEY-----
    replace-with-your-private-key
    -----END PRIVATE KEY-----

Replace truefoundry with the namespace where your TrueFoundry control plane is installed.Apply it with:

kubectl apply -f secrets.yaml -n <namespace>

Replace <namespace> with the namespace where your TrueFoundry control plane is installed.Reference a secret key in the integration Format: tfy-k8s-secret://<KEY_NAME> Example:

tfy-k8s-secret://HASHICORP

The value after tfy-k8s-secret:// must exactly match the key inside the Kubernetes secret.For example, if your secret contains:

stringData:
  HASHICORP: "replace-with-your-vault-token"

then in the HashiCorp Vault integration form you can enter:

Vault URL: https://vault.example.com
HashiCorp Vault Auth Token: tfy-k8s-secret://HASHICORP

HashiCorp Vault integration form using a Kubernetes secret reference

You can use the same secret reference formats in YAML/GitOps when defining provider accounts and other integrations, so API keys stay out of version control.

Get Started

LLM Gateway

MCP Registry and Gateway

Skills Registry

Prompt Registry

Guardrails and Security

Observability

Deployment

Admin Guide

Chat

Messages

Embeddings

Rerank

Responses

Image

Audio

Batch

Files

Fine-tuning

Moderations

Models

Use Secret Manager in Integrations