[aws-profile] Added profile functions to mirror the region functions

[XaosTX]

I know some of this may overlap existing "account" functions and I'm willing to merge over there if that's your desire. I needed something that would handle the multiple profiles (accounts) that we have in a sane way.

[mbailey]

Are you still using this? How's it been working out for you?

Re-reading this PR, you've done a neat job and if I used profiles I would want to use it.

I don't use profiles. They keep your creds in plaintext in a predictable location on your filesystem don't they?

If so, I'd be reluctant to include any endorsement of this approach in BMA because while I'm sure it's reasonable in some circumstances (risk assessed and appropriate controls in place), I think it could also lead to people having their creds compromised.

I realise AWSCLI recommends running aws configure when you call it without creds. I think they try to make things easy for users but that also seems like a super dangerous way to store long lived creds. I keep mine in gpg encrypted files. If a process wants to read them it needs to convince me to touch my yubikey - and it needs to find them as they're not in a predictable place.

[nitrocode]

This is pretty cool. I usually run my bma functions with profiles using an inline env variable.

AWS_PROFILE=dev_sre buckets
AWS_PROFILE=staging_sre buckets
AWS_PROFILE=production_sre buckets

I like my approach as I need to be explicit which profile to use, however, it would be nice in some cases to select a single one so I can shorten my commands.

I don't use profiles. They keep your creds in plaintext in a predictable location on your filesystem don't they?

This used to be true but now thanks to aws-vault you can store keys encrypted in your keychain and generate temporary keys from your stored keys. If you pair that tool up with AWS SSO (we use it with Okta), now you don't have keys anymore and everything is temporary and through role assumption.