Using different namespaces for authentication vs. secret requests

[estimmerman]

Describe the feature request or question In HashiCorp Vault, namespaces have a hierarchy, and permissions can be granted to children namespaces for entities within a parent namespace. As far as my reading of the VaultSharp source code for namespace support and from my experimentation, the feature is too limiting for real-world setups you can have in practice where different namespaces must be used for retrieving a Vault token vs. the namespace used in a downstream secret request. See below for an example and the workaround I had to use, but it'd be great if there was more flexibility here. Ideally we could override the Namespace as a named parameter within any of the individual secret engine methods, just like how you can specify a mount path.

At our company (all identifiers/names are fake), we have a root namespace admin. There are also multiple children namespaces for development teams within our engineering org, such as team-1, team-2, ..., team-N. The full namespace path for the children namespaces are therefore admin/team-[1-N]. We have an administrative AppRole role within the admin namespace which is granted read-only policies on secrets within children namespaces. Individual teams have their own auth methods for authenticating into their child namespace (no ability to authenticate with/retrieve a token from the root admin namespace), with full read/write policies for their own secrets.

We are building an integration that requires using our administrative AppRole role to read secrets from these children namespaces. The namespace used to retrieve the Vault token for the AppRole must use admin (it will fail if using admin/team-1, for example, since the AppRole method is enabled within the root namespace), but when reading a secret from a child namespace, the namespace must be the fully qualified child namespace, admin/team-[1-N].

Currently you can only set the Namespace on the VaultClientSettings globally. The only workaround to this issue that I found was the perform an immediate login within the root namespace and then override the client namespace with the secret namespace before reading. This has the drawback of no longer lazily invoking Vault token retrieval, which we would like. I suppose there may be a path to also override the namespace header using BeforeApiRequestAction, but that feels even more messy and non-idiomatic.

Here's the workaround pseudocode:

var vaultClient = new VaultClient(new VaultClientSettings(server, admin AppRoleMethodInfo));
vaultClient.Settings.Namespace = "admin";
await vaultClient.V1.Auth.PerformImmediateLogin().ConfigureAwait(false);

// ... some amount of time elapses

vaultClient.Settings.Namespace = "admin/team-1";
var secret = await vaultClient.V1.Secrets.KeyValue.V2.ReadSecretAsync(path: some path, mountPoint: some mount path).ConfigureAwait(false);

Link to the Vault API Docs that support this feature https://developer.hashicorp.com/vault/docs/enterprise/namespaces/namespace-structure

Additional context N/A

[veleek]

We have almost this exact same code in our library where we set the namespace for login and then immediately change it after login succeeds.