Security — CloudBeaver

ChartVersion3.0.1TypeapplicationAppVersion25.3.0

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

Feature SupportLDAPsupported

Configure LDAP authentication for CloudBeaver Community, allowing users to authenticate against your corporate LDAP server instead of using local accounts.

Follow the best practices of not committing passwords in versioned files and using Kubernetes Secrets or secret management operators.

Prerequisites

• LDAP server reachable from the cluster (e.g., ldap.company.local:389)
• Bind DN with permission to search users in the directory
• Bind credentials (user and password)
• Base DN where users are located
• LDAP filter to locate users by ID

Credentials and Secrets

Terminal input

kubectl -n <NAMESPACE> create secret generic tdp-cloudbeaver-ldap-bind \
  --from-literal=password='<LDAP_BIND_PASSWORD>'

This Secret securely stores the bind password, referenced by the chart values.

LDAP configuration

The LDAP configuration uses the ldap.server, ldap.bind, ldap.userSearch, and ldap.extraEnvVars blocks to inject CLOUDBEAVER_AUTH_LDAP_BIND_PASSWORD via secretKeyRef.

The chart automatically generates the cloudbeaver.conf file with the authConfigurations block from these fields — no need to provide JSON manually.

tdp-cloudbeaver:
  ldap:
    enabled: true
    server:
      host: "<LDAP_HOST>"
      port: 389
      useSSL: false
      useTLS: false
      insecureSkipVerify: true
    bind:
      dn: "<LDAP_BIND_DN>"
      passwordSecretName: "tdp-cloudbeaver-ldap-bind"
      passwordSecretKey: "password"
    userSearch:
      baseDN: "<LDAP_USER_BASE_DN>"
      filter: "(objectClass=person)"
      userIdAttribute: "uid"
    extraEnvVars: |
      - name: CLOUDBEAVER_AUTH_LDAP_BIND_PASSWORD
        valueFrom:
          secretKeyRef:
            name: tdp-cloudbeaver-ldap-bind
            key: password

Configuration automatically generated by the chart

The chart automatically generates the cloudbeaver.conf file with the authConfigurations block from the ldap.server.*, ldap.bind.*, and ldap.userSearch.* fields. No need to define settings manually in values. The ldap.extraEnvVars field injects the bind password at runtime via secretKeyRef.

Placeholders to replace:

• <LDAP_HOST>: LDAP server hostname or IP
• <LDAP_BIND_DN>: Full DN of the bind user (e.g., cn=admin,dc=company,dc=local)
• <LDAP_USER_BASE_DN>: Base DN where users are located (e.g., ou=people,dc=company,dc=local)

Installation or upgrade

Terminal input

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

Parameters

Area	Use	Example
ldap.server.*	Host, port, SSL/TLS	host: "ldap.company.local"
ldap.bind.*	Bind DN + Secret name with password	dn: "cn=admin,dc=company,dc=local"
ldap.userSearch.*	Base DN, filter, login attribute	baseDN: "ou=people,dc=company,dc=local"
ldap.extraEnvVars	Bind password injection via secretKeyRef	Always include CLOUDBEAVER_AUTH_LDAP_BIND_PASSWORD

Troubleshooting

LDAP option not appearing on login

Check 1: confirm LDAP is enabled

tdp-cloudbeaver:
  ldap:
    enabled: true

Check 2: validate the authConfigurations section in the generated ConfigMap

Terminal input

kubectl get configmap tdp-cloudbeaver-auto-config -n <NAMESPACE> -o yaml | grep -A 20 "authConfigurations"

Check 3: check pod logs

Terminal input

kubectl logs -n <NAMESPACE> -l app.kubernetes.io/name=tdp-cloudbeaver | grep -i ldap

LDAP authentication failed

Check 1: test connectivity to LDAP server

Terminal input

kubectl exec -it -n <NAMESPACE> <POD_NAME> -- nc -zv <LDAP_HOST> 389

Check 2: verify bind credentials

Terminal input

ldapwhoami -x -H ldap://<LDAP_HOST>:389 \
  -D "<LDAP_BIND_DN>" \
  -w '<LDAP_BIND_PASSWORD>'

Check 3: validate filter and base DN

Terminal input

ldapsearch -x -H ldap://<LDAP_HOST>:389 \
  -D "<LDAP_BIND_DN>" \
  -w '<LDAP_BIND_PASSWORD>' \
  -b "<LDAP_USER_BASE_DN>" \
  "<LDAP_FILTER>"

Check 4: verify user ID attribute

Terminal input

ldapsearch -x -H ldap://<LDAP_HOST>:389 \
  -D "<LDAP_BIND_DN>" \
  -w '<LDAP_BIND_PASSWORD>' \
  -b "<LDAP_USER_BASE_DN>" \
  "uid=<USERNAME>"

Confirm that userIdAttribute matches an existing attribute (e.g., uid, mail, sAMAccountName).

LDAP authentication flow

1. User selects "LDAP" on the CloudBeaver login screen.
2. CloudBeaver performs a bind to the LDAP server using credentials configured in ldap.bind.
3. Searches for the user with the filter defined in ldap.userSearch.filter and the userIdAttribute.
4. Authenticates the user with the password entered at login.
5. Creates or updates the user profile in CloudBeaver with LDAP attributes.

Security considerations

• Use LDAPS in production: enable ldap.server.useSSL: true to encrypt LDAP traffic.
• Dedicated bind user: use a bind user with minimal permissions (read-only in the directory).
• Network security: the LDAP server should be accessible only from authorized networks.
• Password management: never commit passwords to Git; use Kubernetes Secrets with Sealed Secrets, External Secrets Operator, or HashiCorp Vault in production.
• insecureSkipVerify: set to false in production to validate the LDAP server TLS certificate.

LDAP vs local authentication

CloudBeaver supports both local and LDAP authentication simultaneously:

Type	Users	When to use
Local	Users created directly in CloudBeaver (e.g., admin)	Always available; required for initial administration
LDAP	Corporate directory users	Environments with SSO or centralized authentication

Local admin user

The local admin user (configured via initialData.adminName) remains available regardless of LDAP. Keep it as a fallback for administrative access if LDAP becomes unavailable.