VaultSharp.Core.VaultApiException: {"errors":["1 error occurred:\n\t* permission denied\n\n"]}

[gitisz]

Hello Raja, et Al.

My Org is an extensive user of HashiCorp Vault and AWS, but has no dotnet implementation. I would like to change that.

For our use case, we use ECS which spins up containers that use Go to perform wrapped signed calls to Vault, and expose KV secrets as environment variables using envconsul. This means VAULT_TOKEN is preset for every ECS task.

We would like to honor the VAULT_TOKEN for normal application secrets needs, but for our application we would like to access different Vaults with user-specified on-demand VaultRole names. This implies for each request, we need to generate base64 encoded AWS4Signer headers based on the IAM credentials, to send to Vault.

I read from this issue that VAULT_TOKEN overrides the token for any subsequent request for secrets.

When logging out VAULT_TOKEN and the IAM generated awsCredentials token, they are clearly different.

How can we have VAULT_TOKEN handle normal secrets required by the application, while our side-chain requests for other Vaults honor the awsCredentials Token required for on-demand requests?

Happy to share code. Thank you for the promising VaultSharp solution!

[gitisz]

Looks like I figured it out, just took a few days to unravel (yes, was working on it for that long).

await vaultClient.V1.Auth.PerformImmediateLogin();

With the above line passing, e.g. not throwing an exception, it was clear I was successful logging in, which informs the Signed request was correct. I came to know that what solved it for me wasn't that VAULT_TOKEN was taking priority, but instead the following:

1. We are using KeyValueV1 and not V2. I was having KeyValue.V2.ReadSecretAsync originally.
2. The mountPoint in our Org for authenticating with IAuthMethodInfo is not the same as the mountPoint we have for each Vault.

        IAuthMethodInfo authMethodInfo = new IAMAWSAuthMethodInfo(
            roleName: vaultRoleID,
            requestHeaders: encodedIamRequestHeaders,
            mountPoint: "<some-uuid>"
            );

        var secrets = await vaultClient.V1.Secrets.KeyValue.V1.ReadSecretAsync(secretPath, mountPoint: "<some-other-uuid>");

Disregard.

Glad to be clear of this issue, and now quite able to build on top of this library.

[rajanadar]

glad to hear @gitisz