Security — OpenMetadata

ChartVersion3.0.1TypeapplicationAppVersion1.12.4

CompatibilityKubernetes1.32+OpenShift4.19+Rancher2.10.x+

General security standards

For concepts that apply to all TDP components — such as Secrets management, credential rotation, NetworkPolicy, rate limiting, and auditing — see Security — General Standards.

Authentication configuration

The parameters below control the authentication mode, user self-registration, and initial administrator configuration.

Parameter	Description	Default
tdp-openmetadata.openmetadata.config.authentication.provider	Authentication mode: basic (local user/password) or ldap	basic
tdp-openmetadata.openmetadata.config.authentication.enableSelfSignup	Allow new users to self-register via the UI	true
tdp-openmetadata.openmetadata.config.authorizer.initialAdmins	List of admin users created at bootstrap	["admin"]
tdp-openmetadata.openmetadata.config.authorizer.principalDomain	Domain appended to initialAdmins names	open-metadata.org
datasourcesIntegration.openmetadata.auth.*	Credentials used by the datasources Job to authenticate to the API; when provider=basic, also displayed in Helm NOTES	admin@open-metadata.org / admin

To disable self-registration in production environments:

tdp-openmetadata:
  openmetadata:
    config:
      authentication:
        enableSelfSignup: false

LDAP authentication

The tdp-openmetadata chart supports LDAP authentication, allowing the use of corporate directories for logging into OpenMetadata.

To enable this mode, create a Kubernetes Secret with the bind password and add the LDAP configuration to your values ​​file.

The configuration allows customizing user and group DNs, email and login attributes, group-to-role mapping, and truststore behavior.

After activation, login is done with the user's LDAP credentials.

How to enable

1. Enable ldap.enabled: true in values.yaml.
2. Include the LDAP definitions in your values ​​file.

Example installation/upgrade with overlay:

Terminal input

helm upgrade --install <RELEASE_NAME> \
  oci://registry.tecnisys.com.br/tdp/charts/tdp-openmetadata \
  -n <NAMESPACE> --create-namespace \
  -f <VALUES_FILE>

Prerequisites

• LDAP server accessible from the Kubernetes cluster
• Bind DN with permissions to search users and groups
• Kubernetes Secret with the bind password

Credentials and Secrets

Terminal input

kubectl create secret generic tdp-openmetadata-ldap-secret \
  --from-literal=bind-password=<PASSWORD> \
  -n <NAMESPACE>

LDAP configuration

Define in the overlay the main LDAP parameters: host, port, admin DN, user and group base DNs, plus attributes and role mapping.

<VALUES_FILE>

ldap:
  enabled: true

tdp-openmetadata:
  openmetadata:
    config:
      authentication:
        enabled: true
        provider: ldap
        enableSelfSignup: true
        ldapConfiguration:
          host: "ldap.example.local"
          port: 389
          dnAdminPrincipal: "cn=admin,dc=example,dc=local"
          dnAdminPassword:
            secretRef: tdp-openmetadata-ldap-secret   # Secret created in the previous step
            secretKey: bind-password
          userBaseDN: "ou=users,dc=example,dc=local"
          groupBaseDN: "ou=groups,dc=example,dc=local"
          mailAttributeName: mail
          usernameAttributeName: mail
          groupAttributeName: memberOf
          groupMemberAttributeName: member
          maxPoolSize: 3
          authRolesMapping: '{"cn=tdp-admins,ou=groups,dc=example,dc=local": ["Admin"]}'
          authReassignRoles: []
          sslEnabled: false
          truststoreConfigType: TrustAll   # Use CustomTrustStore or JVMDefault to validate certificates

Bind password via Secret

The dnAdminPassword field must always reference a Kubernetes Secret — never put the password as plain text in the values file. Create the Secret before deploying as described above.

What this configuration covers

• Host, port, admin DN, and user/group bases
• Customizable attributes for email, user, and groups
• LDAP group-to-OpenMetadata role mapping via authRolesMapping
• Default TrustAll truststore, which does not require LDAPS, but can be adjusted for your environment

Login

Terminal input

kubectl port-forward svc/<RELEASE_NAME> 8585:8585 -n <NAMESPACE>

Then open http://localhost:8585 and log in with the user's LDAP credentials.

For the full parameter list, run helm show values for the installed chart version and see the OpenMetadata official documentation.

OpenShift: SCC configuration

On OpenShift, OpenMetadata ingestion jobs run with runAsUser: 0 (root) to install Python packages via pip. This requires the anyuid Security Context Constraint (SCC).

To automatically configure the SCC, enable openshift.enabled: true in the values file:

openshift:
  enabled: true

Or via command line:

Terminal input

helm upgrade --install <RELEASE_NAME> \
  oci://registry.tecnisys.com.br/tdp/charts/tdp-openmetadata \
  -n <NAMESPACE> --create-namespace \
  --set openshift.enabled=true

When enabled, the chart creates a RoleBinding that adds the following ServiceAccounts to the anyuid SCC:

• openmetadata-ingestion — used by OpenMetadata ingestion jobs
• <RELEASE_NAME>-openmetadata-sa — used by the datasource registration job

warning

Without this configuration on OpenShift, ingestion jobs fail when attempting to install Python dependencies.

Datasource registration job security

The integration job authenticates to the OpenMetadata API and accesses external services. Follow these practices:

• Never store passwords as plain text in values files in production. Use passwordSecret with a reference to a separately created Kubernetes Secret.
• Restrict access to Secrets via RBAC: the job uses a dedicated ServiceAccount; do not expand its permissions beyond what is needed.
• Use HTTPS for service endpoints outside the cluster: set scheme: "https" for ClickHouse and Trino, and verifySSL: "validate" for Superset and Airflow.
• Rotate passwords regularly: after changing a service password, update the corresponding Kubernetes Secret and re-run the registration job.

Example Secret for the ClickHouse credential:

Terminal input

kubectl create secret generic tdp-clickhouse-tdp-user \
  --from-literal=password=<PASSWORD> \
  -n <NAMESPACE>

Reference in the values file:

datasourcesIntegration:
  clickhouse:
    connection:
      passwordSecret:
        name: "tdp-clickhouse-tdp-user"
        key: "password"