Skip to main content

Kubernetes Secrets Manager

OpenMetadata can use Kubernetes Secrets as its secrets manager backend, storing sensitive values (passwords, tokens, keys, etc.) as native K8s Secret objects instead of encrypted fields in the database.

1. Permissions (Kubernetes RBAC)

The OpenMetadata Server needs RBAC access to Kubernetes Secret objects in the target namespace. The Python ingestion runtime only needs read access.

Required verbs

Example: Role + RoleBinding (namespace-scoped)

If the ingestion runtime runs in a separate ServiceAccount, grant it a read-only Role with only get.
If OpenMetadata and the target secrets live in the same namespace, <om-namespace> and <secrets-namespace> are the same.

2. Update configuration

2.1 OpenMetadata Server (openmetadata.yaml)

Choosing inCluster vs kubeconfigPath

  • In-cluster (recommended for K8s deployments): set OM_SM_IN_CLUSTER=true. Uses the pod’s ServiceAccount and the RBAC from section 1. Leave kubeconfigPath empty.
  • Out-of-cluster: set OM_SM_IN_CLUSTER=false and OM_SM_KUBECONFIG_PATH to a kubeconfig file readable by the OpenMetadata process. If the kubeconfig path is also empty, the default kubeconfig (~/.kube/config) is used.

2.2 Pipeline Service Client

In the pipelineServiceClientConfiguration section of openmetadata.yaml, set the secrets manager loader so the ingestion framework knows how to authenticate:
Supported values: noop, airflow, env.

2.3 Airflow configuration (self-managed Airflow)

If you run ingestion via your own Airflow deployment, configure it to resolve K8s secrets. Option A: airflow.cfg
Option B: Airflow environment variables Airflow auto-maps env vars with the pattern AIRFLOW__<SECTION>__<KEY>:
If Airflow runs inside the cluster, use KUBERNETES_IN_CLUSTER=true and ensure Airflow’s ServiceAccount has get permissions on Secrets in the target namespace.

2.4 Non-Airflow ingestion (env loader)

When using the env secrets manager loader (e.g., standalone ingestion containers), configure via plain environment variables:
The Python env loader also auto-detects the current namespace from /var/run/secrets/kubernetes.io/serviceaccount/namespace when running in-cluster, falling back to default.

3. Migrate secrets and restart services

After updating configuration, migrate existing sensitive values from database encryption to Kubernetes Secrets:
This migrates secrets from the DB to the configured Secrets Manager. It does not support migrating between external Secrets Managers (e.g., from AWS SSM to Kubernetes). Then restart:
  1. OpenMetadata Server — so it reads/writes secrets to K8s.
  2. Airflow / ingestion runtime — so it picks up the secrets manager settings.

4. Workflow YAML (self-managed Airflow)

If you use your own Airflow to run ingestion workflows, configure the workflow YAML:

5. How secrets are stored

Naming convention

Secret names use hyphens as separators (not slashes) to comply with Kubernetes DNS naming rules:
  • prefix comes from secretsManagerConfiguration.prefix
  • clusterName comes from the top-level clusterName in openmetadata.yaml (default: openmetadata)
  • The remaining path components are derived from the entity/connection being stored
Examples (assuming default clusterName: openmetadata, no prefix):
Names are sanitized for Kubernetes compatibility:
  • Only lowercase alphanumeric characters and hyphens are allowed
  • Consecutive hyphens are collapsed to a single hyphen
  • Leading and trailing hyphens are stripped
  • Truncated to 253 characters (K8s Secret name limit)

Data format

Each secret is stored as a Kubernetes Secret object with:
  • A single data key: value — containing the secret as UTF-8 bytes
  • Labels:
  • app: openmetadata
  • managed-by: openmetadata-secrets-manager
  • Plus any custom labels from the tags configuration