Support for importing AWS vault credentials from encrypted files

[williamhpark]

Summary

Resolves: #248

Currently, if you store AWS credentials using AWS vault with an encrypted file as the backend, then try to import credentials into 1Password using the AWS vault importer, you get a long invalid memory address or nil pointer dereference error in the terminal and no import candidates are shown. We want to support importing credentials from encrypted files.

Also, while importing using a build of the AWS plugin that isn't a local build, several log messages display in the terminal. These messages are invoked in the AWS vault code - we want to silence these. Example:

2023/04/21 13:19:32 Loading config file /Users/williampark/.aws/config
2023/04/21 13:19:32 Parsing config file /Users/williampark/.aws/config
2023/04/21 13:19:32 Unrecognised ini file section: DEFAULT

How to Test

1. Add a profile through aws-vault using an encrypted file as the backend: aws-vault add file-profile --backend file
2. Run op plugin init aws (don't use a local build) > Import into 1Password...

Expected Behaviour

No unnecessary log messages should be displayed.

You should get a prompt in the terminal: Enter passphrase to unlock "~/.awsvault/keys/": . After inputting the correct password, Encrypted file (file-profile) should be displayed as an import candidate. You should be able to import the credential into 1Password successfully.

[williamhpark]

There's currently a gap in this PR that I haven't been able to find a good solution for.

When a non-local build for the AWS plugin is used, everything behaves as desired (i.e. like in the PR description). However, when a local build is used, the Enter passphrase to unlock "~/.awsvault/keys/": prompt doesn't display in the terminal. This makes it seem like the terminal is just hanging while it waits for the user's password input:

I had a discussion with @AndyTitu and he mentioned that this is likely because of the use of RPC for local builds causing issues outputting to the terminal.

One simple-ish solution could be to detect if the AWS build is local or not in importers.go, and if it is local, simply skip encrypted files as a possible backend by removing it from the availableBackends list. If we don't want to do this, would anyone have any other suggestions on how to fix this issue?

[AndyTitu]

I wasn't able to test this because I cannot get encrypted files to work correctly as a backend to my aws-vault.

Is this working as expected for you @williamhpark ?

[williamhpark]

Hey @AndyTitu, the issue is that you need to specify --backend file when you run aws exec as well (I know kind of weird). So running aws-vault exec file-profile --backend file -- aws sts get-caller-identity should work for you. It works for me.

[AndyTitu]

This doesn't show up when running a local profile through RPC. However, the line underneath for the Stdin works as expected. @jpcoenen do you know why that is, and how could we overcome that? This is the only aspect that blocks this PR.

However, when a local build is used, the Enter passphrase to unlock "~/.awsvault/keys/": prompt doesn't display in the terminal. This makes it seem like the terminal is just hanging while it waits for the user's password input:

[accraw]

Why are we printing to Stderr?

[jpcoenen]

Apologies; I missed this comment originally. I think there is a way to read the output a plugin writes to stderr, but I am not sure whether that is the preferred way to go here.

Might be interesting to see if there are any Terraform Providers that prompt the users. If so, we could see how they tackle that.