Skip to main content
Community Hub

Secret management

TL;DR

Understand how Self-Deployed Runtime handles secrets and why credentials never leave your environment.

Your AI can read this via Docs MCPInstall MCP →Connect

Secret management in Self-Deployed Runtime ensures that credentials for source systems never leave your environment. By integrating with your existing secret vaults and fetching credentials just-in-time, the runtime can authenticate with databases and applications without exposing sensitive credentials to external systems, including Atlan SaaS.

Did you know?

SDR requires additional enablement and licensing. Contact your Atlan representative for details.

How credentials are protected​

Self-Deployed Runtime deployed applications integrate with enterprise secret vaults for successful source system authentication. The key principle is that secrets are never stored locally or sent to Atlan and remain entirely within your organization's security perimeter.

Supported secret stores include:

How it works​

Secrets (like database credentials) are fetched just-in-time via Dapr when the App needs to connect to source systems. This dynamic access means credentials are only in memory during the specific authentication operation, then immediately discarded.

The secret management makes sure that credentials remain entirely within your organization's security perimeter through:

  • No local storage or transmission: Secrets are never stored locally or sent to Atlan
  • Network isolation: Network isolation for secret store access
  • Access controls: Access controls with principle of least privilege
  • Audit logging: Audit logging for all secret access and modifications
  • Regular reviews: Regular access reviews and backup/disaster recovery for secret stores

Runtime credentials​

Source-system credentials are one of two kinds of secret in a Self-Deployed Runtime deployment. The other is the OAuth credential pair the runtime uses to authenticate with your Atlan tenant, along with the credentials for the object and secret stores it talks to.

On Kubernetes, none of these have to be written into a values file. Every sensitive value in the Helm charts accepts either a literal or a reference to a Kubernetes Secret you already manage, so the values file holds only a Secret name and the key names inside it. See Reference existing Secrets.

See also​