Well, I got a bit farther. This time I’m stuck on a certificate. Looks like I can just set VAULT_SKIP_VERIFY! Let’s try it out.

At this point I’m questioning my approach with our platform. We’ve got certain cross cutting concerns which aren’t unique to any specific application. We’ve got to do logging and we must be able to communciate secrets. Since this is the case I’m considering in the real long term to provide our own pid 1 which establishes both of these. This would drastically reduce the burden I have maintaining them.

The VAULT_SKIP_VERIFY flag worked well, however now it’s complaining it can’t get a token. Time to add more debugging statements.

Alright, this time I got a slightly different error message: The security token included in the request is invalid.. Well that isn’t too fun.

I’m guessin the singned enitty which is forwarded to AWS for verification is incorrect. So it looks like the underlying problem is related to only looking at the environment for credentials. I’ll have to use the AWS library to extract the signing keys and inject them. The AWS code to retrieve the values is fairly straight forward.

let credentials = await new aws.CredentialProviderChain().resolvePromise()

After all this I’m getting a Error: permission denied from Vault :-/. That is a bummer. Turns out some of my automated tools were too fancy and I overlooked that they logged me in as root. Okay. Helps if I read the log files more often. Turns out the client isn’t attaching the token at all, so I broke that some where. Binding teh token to the clinet again restored the request and fixed the underlying errors. Now to just cleanup the other minor errors I have in the code.