If you’re doing a lot with AWS, you’ll find yourself using two things… multiple IAM users and the AWS CLI. One of the things I kept seeing the instructors in a certification training course (3rd party) doing was reconfiguring the CLI with new credentials every time they created a new user for a demo.
That’s nice and all, but you can only view your credentials once and then you have to generate new ones if you haven’t stored them somewhere. Storing them in the CLI config is good… until you clobber them with the credentials for another IAM user you created.
But the AWS CLI has user management features with the profile argument.
The easiest way to add a new profile is to simply add a profile argument when you issue a configure command.
aws configure --profile myUserName
You can substitute whatever name you gave to the IAM user for myUserName and a profile will be created with that user name, storing both the user’s credentials and preferred region. Then, to issue a command in the CLI as that user, like creating an S3 bucket…
aws s3 mb s3://bucket-name --profile myUserName
But what if I don’t want to specify the profile on every single command?
First, if you don’t specify a profile argument during configuration, AWS CLI will store the credentials and region under a user named “default.” So, the user you configure without a name will be the one used whenever you don’t specify a name… unless…
The AWS CLI looks for an environment variable called AWS_DEFAULT_PROFILE. If it’s not set, the default profile is “default,” but if you set it, the CLI will use whichever profile name it specifies.
So, let’s say you just created a mySysOp user who will be your default user for all your CI/CD commands related to CodeBuild and CodeDeploy. You open a terminal window (or DOS prompt, or PowerShell), and you can run one of the following commands to set the user for that shell session…
Windows: set AWS_DEFAULT_PROFILE mySysOp
Linux/Mac export AWS_DEFAULT_PROFILE=mySysOp
To make it more permanent (all subsequent terminals opened, but not any other ones that are currently open), you’d use setx in Windows, or add the value to your .profile file for your Bash shell user.
I’d literally considered spinning up VMs via Docker and remoting into them for each IAM user to avoid CLI clobberification, so I was really glad I did some investigating and found out about profiles. For the full skinny on profiles, visit the AWS docs page about profiles.
Top comments (2)
I love
--profileI have yet to get around to it but I was considering seeing if I could remove the
[default]because I want to ensure I always specify a profile so I don't by mistake deploy to default for something intended for another account.Uncertain if credentials will complain if
[default]is not present.I was also thinking about what is the best means of securing the credentials files on a workstation.
I believe you can set MFA for API calls via IAM policy maybe as a Permissions Boundary but this would not protect the local file.
I suppose if your workstation is password protected but lets say you walked away from your workstation and someone then just
catyour credentials file and take a screenshot with their phone.The MFA would protect again API calls but not from capturing all those keys.
Just some thoughts going around in my head.
Just brainstorming here as a curious dev and not on behalf of Amazon (the CLI is not my product and I cannot provide official guidance), but check out docs.aws.amazon.com/cli/latest/use...
Seems like you could have the credentials encrypted within a secure store and set up a retrieval app. You just need some asynchronous way to provide authorization to the app so it can return the credentials when they're requested before the credential request times out.
You can still use profiles too it seems.