Boto3: keyring support didn't make the leap from boto2

[handlerbot]

Original: https://github.com/boto/boto/issues/1154. I'm very glad to write a to-guidelines PR with tests for this, but wanted to check that this is something the maintainers would be largely happy to see come forward to boto3 before I started on the work. Thanks for your time!

[handlerbot]

Ofc, I just noticed https://github.com/boto/botocore/pull/72 right after opening this issue... :-)

Would folks be amenable now that https://github.com/boto/botocore/pull/251 is submitted? This would let out-of-the-box awscli, e.g. via brew on MacOS, store secret_access_key in system keychains cross-platform (keyring supports MacOS, multiple Linux options, Windows Credential Vault).

[jamesls]

We don't have any plans to support this as of now, but that can change based on customer feedback.

In botocore, it's much more straightforward to inject additional credential providers than it was in boto. It's possible for a keychain provider to live as a separate package (such as botocore-keyring) you can install along with botocore.

I think whether or not this lives in botocore vs. a separate package will depend on customer feedback.

I'm going to mark this as feature-request / others-chime-in and leave this open for a while. If we get enough people interested, we will reconsider.

boto2 users, would you find keychain support in boto3 useful?

Feel free to +1 the issue.

[handlerbot]

Thanks for the update and info, @jamesls!

Can you provide an extant example of how injecting additional credential providers into botocore from separate packages works, or would this be the first instance?

[jamesls]

Essentially, you create a credential provider that subclasses from CredentialProvider. Then you inject it into the session:

cred_provider = session.get_component('credential_provider')
cred_provider.insert_before('shared-credentials-file', provider)

The botocore/credentials.py file has a lot of credential providers you can use as examples.

A good complete example would be the assume role provider that use to be in the AWS CLI: https://github.com/aws/aws-cli/blob/1.7.43/awscli/customizations/assumerole.py#L33

There's a little more code involved because it handles automatically refreshing temporary credentials. Interestingly, this code is no longer in the AWS CLI. It was initially only in the CLI and not botocore, but was moved over to botocore based on customer feedback.

[handlerbot]

So if my goal is to have aws-cli ship with an easy way for most people to activate keyring storage of the secret key on most platforms, would you recommend that I write a credential provider using the botocore injection mechanism, and try and get it integrated into aws-cli rather than adding functionality at the botocore level?

[handlerbot]

ping @jamesls re: previous comment

[glyph]

Speaking as a customer I would really appreciate this being built-in, for two reasons.

One is that managing and keeping track of lots of secrets in plain-text files on disk is a security nightmare. By contrast — on macOS, at least — locking down the keychain is as easy as the "show keychain status in menu bar" option and glancing up there to see what state things are in[1] the operating system will at least encrypt the credentials at rest when you're not logged in.

Another is to prevent mistakes. I have tests for my automation tooling, and I want to force them to talk to mocks, and not make real AWS connections, even if I'm running them on my own account. I can set up Keychain to prompt me for each access to credentials for a Python process, and if my tests start popping that dialog I know I've made a mistake, and I can fix it before any damage is done.

---

[joguSD]

We recently added external process credential providers. This might be a good way to get keychain support into the CLI without the kechain support having to directly live in botocore/boto3/CLI codebase.