Access LDAP credential from kube secrets

I am running z2jh in my internal hosted k8s using ldap authentication. All works well. But the credentials are in plain text, how do i access that from my k8s (kind:Secret) secret.

Hi! Welcome to the forum.

Which credentials are in plain text? If you can show us your Z2JH config with secrests redacted that might also be helpful.

in my org, i am using argo ci/cd for the pipeline, so the config.yaml (override) is in out git plain text. needs to use from secret, but there is no env variable exposed to pass this. not sure how to do. wondering how others are passing clientid, client_secret et., for various authenticator.

“lookup_dn_search_password: password”

          authenticator_class: ldapauthenticator.LDAPAuthenticator
          server_address: ldap://
          server_port: 3268
          use_ssl: False
          escape_userdn: false
          lookup_dn: true
          lookup_dn_search_filter: ({login_attr}={login})
          lookup_dn_search_password: password
          lookup_dn_search_user: sa-d1airflow
          lookup_dn_user_dn_attribute: sAMAccountName
          user_attribute: sAMAccountName
          user_search_base: ou=Users,dc=tc,dc=com
          use_lookup_dn_username: false
            - CN=Admin,OU=Groups,OU=Users,DC=tc,DC=com
          storageClassName: rook-ceph-block

I know of two ways, they take advantage of how Helm can merge multiple configurations passed as dictionaries:

  • Commit an encrypted secret-config.yaml file into git, and decrypt it in your CI/CD pipeline before running Helm. If you pass multiple config files the latter overrides the former.
  • Save the secret values in separate environment variables, and pass them to Helm on the command line (something like helm ... --set a.b.c=$SECRET_ENV_VAR)

both the cases it is still visible when we access the namespaces or hlem repo, what i need is like db.password for hub storage.

need teh hub image to expose those credentials as env variable, so that we can pass those values from hub.secret or own secret file, that is more secure.

There’s an option to provide the name of an existing secret containing values which will be merged in:

that does not work for ad account password logic, coz first it has to be exposed via hub image and then in

refer this line, it has to be in same way for all such credentials.

but for today, it is loading all in just inmemory config

or if i am wrong, kindly provide example for hub.existingsecret to pass ad pwd.