ldap.LDAPAuth type does not handle alternate namespaces

[yabberyabber]

Describe the bug
When authenticating Vault Enterprise namespaces using the ldap.LDAPAuth type,there is no way to pass in the namespace to authenticate against.

Based on the REST API docs, I would expect that either of the following mechanisms would work to authenticate to a specific namespace:

• add namespace to path e.g. /v1/${NAMESPACE}/auth/ldap/login/${USERNAME}
• add X-Vault-Namespace header to request

The existing Path parameter can be used to inject additional components between auth and ldap, but in order to use namespaces, the additional path component must be between v1 and auth ref https://github.com/hashicorp/vault/blob/main/api/auth/ldap/ldap.go#L112

For additional context, my usecase involves using the ExternalSecrets operator to authenticate to vault --- the ExternalSecrets operator lets me embed an ldap.LDAPAuth into my CRD so that's why I am using this particular API https://external-secrets.io/latest/api/generator/vault/

Expected behavior
I would imagine the LDAPAuth type to accept an additional namespace arg here https://github.com/hashicorp/vault/blob/main/api/auth/ldap/ldap.go#L17

which, if nonempty, would get injected here https://github.com/hashicorp/vault/blob/main/api/auth/ldap/ldap.go#L112 before the auth component.

Environment:
Using the VaultDynamicSecret CRD which is handled by the ExternalSecrets operator in k8s https://external-secrets.io/latest/api/generator/vault/. Once the API is added into this hashicorp vault repo, the ExternalSecrets operator will also need to be updated to consume the new type.

I'm happy to make a PR for this if a maintainer thinks this is a reasonable understanding of the issue and a reasonable solution.

[heatherezell]

Hi @yabberyabber! I'd recommend opening a support ticket and referencing this issue. You'll potentially get a faster response that way as an enterprise customer.