Operator is not setting the Vault LDAP bindDN/password with content of LdapAuthEngineConfig.spec.bindCredentials.secret (always setting an empty string)

[dabelenda]

I create a secret named vault-ldap-access in the namespace of the vault-config-operator with following contents:

kind: Secret
apiVersion: v1
metadata:
  name: vault-ldap-access
  namespace: vault-config-operator
stringData:
  password: mysecretpassword
  username: cn=accout,dc=example,dc=com
type: kubernetes.io/basic-auth

Then, in the same namespace, I create an LdapAuthEngineConfig CR:

kind: LDAPAuthEngineConfig
apiVersion: redhatcop.redhat.io/v1alpha1
metadata:
  name: ldap
spec:
  groupAttr: cn
  groupDN: ou=groups,dc=example,dc=com
  groupFilter: '(memberUid={{.Username}})'
  path: ldap
  tokenNoDefaultPolicy: false
  url: ldaps://ldap.example.com:636
  userAttr: uid
  userDN: dc=example,dc=com
  userFilter: '(&({{.UserAttr}}={{.Username}})(memberOf=mygroup))'
  bindCredentials:
    secret:
      name: vault-ldap-access
  authentication:
    path: incluster
    role: vault-config-operator
    serviceAccount:
      name: controller-manager

But the resulting Vault configuration always has the bindDN value empty. When setting the spec.bindDN field of the CR to the expected string, I still cannot use ldap authentication successfully on the vault ui. After setting the spec.bindDN field, if I manually set the password in Vault, then I can authenticate. This means that the password was also not set from the secret.

The logs of the vault-config-operator show no error:

2024-12-31T08:14:10Z	INFO	ldapauthengineconfig-resource	default	{"name": "ldap"}
2024-12-31T08:14:10Z	DEBUG	Creating new client	{"controller": "ldapauthengineconfig", "controllerGroup": "redhatcop.redhat.io", "controllerKind": "LDAPAuthEngineConfig", "LDAPAuthEngineConfig": {"name":"ldap","namespace":"vault-config-operator"}, "namespace": "vault-config-operator", "name": "ldap", "reconcileID": "6226f354-6013-4de1-8cf7-98ea83b5a4ae"}
2024-12-31T08:14:10Z	INFO	starting reconcile cycle	{"controller": "ldapauthengineconfig", "controllerGroup": "redhatcop.redhat.io", "controllerKind": "LDAPAuthEngineConfig", "LDAPAuthEngineConfig": {"name":"ldap","namespace":"vault-config-operator"}, "namespace": "vault-config-operator", "name": "ldap", "reconcileID": "6226f354-6013-4de1-8cf7-98ea83b5a4ae"}
2024-12-31T08:14:10Z	DEBUG	reconcile	{"controller": "ldapauthengineconfig", "controllerGroup": "redhatcop.redhat.io", "controllerKind": "LDAPAuthEngineConfig", "LDAPAuthEngineConfig": {"name":"ldap","namespace":"vault-config-operator"}, "namespace": "vault-config-operator", "name": "ldap", "reconcileID": "6226f354-6013-4de1-8cf7-98ea83b5a4ae", "instance": {"apiVersion": "redhatcop.redhat.io/v1alpha1", "kind": "LDAPAuthEngineConfig", "namespace": "vault-config-operator", "name": "ldap"}}

From the code, I can see some inconsistencies with the documentation.
In the documentation it is stated that the Secret must be of type kubernetes.io/basic-auth but in the reconciliation code I cannot see such constraint (at least here: https://github.com/redhat-cop/vault-config-operator/blob/main/api/v1alpha1/ldapauthengineconfig_types.go#L131-L147 ).
Moreover if the type of the Secret must be kubernetes.io/basic-auth, bindCredentials.usernameKey and bindCredentials.passwordKey having an effect on the retrieval of the data is weird since these should always be username and password for this Secret type.

In the code, there seem to be missing input checking, and feedback for the user to understand what is happening and why. Particularly, if bindCredentials.usernameKey or bindCredentials.passwordKey do not exist in the Secret, the corresponding value the operator will get will always be an empty string. I guess the operator should, check if the secret contains these keys, and output a warning if it does not, properly telling which keys it is searching for in the secret.