Credential management best practice
tigris opened this issue · comments
At $COMPANY we use some internal tooling that exposes some short lived AWS credentials to the command you wish to run.
For example: get-credentials aws s3 ls would expose some AWS credentials to the aws command, and then they'd be gone.
This is great because I don't have long lived credentials in my shell, exposing me to such dangers as typosquatting that has managed to steal many many AWS credentials over the years.
Since bma things are functions in the shell, they can't be executed nicely by other things such as the get-credentials program in the above example.
I can currently get around this by using the bma executable that exists in the bin/ folder and is in $PATH as per normal setup instructions. As a result, an example now looks like get-credentials bma ecr-repositories
I wonder if this is worth documenting somewhere? I was doing some reading and couldn't find anything about suggestions for credential management. I saw this comment fly by, and I guess currently it's just assumed that if you know how to get your credentials into the aws CLI tool, then it's exactly the same for bash-my-aws? If that's the case, that's also cool, but also maybe worth mentioning somewhere that "bash-my-aws assumes you get your credentials to it on your own"?
Sounds like the problem is with your tool not allowing you to call aliases.
The installation instructions recommend sourcing the alias file.
$ type instances
instances is aliased to `~/.bash-my-aws/bin/bma instances'If you want to allow staff to call bma commands from your tool, you'll need to update it to allow them to call aliases (or functions).
Sounds like the problem is with your tool not allowing you to call aliases.
I don't think it's possible to create tools that call the bma aliases unless the tool is also bash and the user has setup any normal invocation of /bin/bash (or) /usr/bin/env bash to source the bma functions, or the tool has intimate knowledge of bma and sources the functions itself.
To be clear, I wasn't raising that as the issue here. This issue wasn't about fixing any code. It was about creating some documentation for users around credential best practice (currently there is nothing about credential management), and perhaps how to continue to use bma if you don't wish to put creds on disk / in your shell. Which I'm happy to help curate BTW.
The awscli documentation on credentials is IMO extremely bad. To the point where they actually instruct you to put your long lived IAM user credentials on disk, in known locations in your home folder. Many people who are not that comfortable in their shell, may not be aware of the dangers this brings.
I'm all for making things easier for people. The fact bma gets it's best benefits (IMO) from piping, does probably mean you get the most benefit by having credentials readily available to your shell. But whilst making things easier, we could also be making them more secure, or at least making users more aware.
BMA is a thin wrapper around AWSCLI and doesn't concern itself with credentials.
Maintaining documentation around best practice for AWS credentials is out of scope for this project.
AWS documentation might be a better place for this.