Perhaps the worst security mistake you can make is leaving highly confidential secret access keys on a web-facing server. So, when it comes time to install and authenticate the AWS CLI on a remote EC2 instance, how do you configure it?
You Should Be Using IAM Users
The answer is definitely not using your root access keys—these are the most important tokens in your account, and they can bypass any multi-factor authentication device you have set up. (You can actually set up MFA-protected API access but not for the root account.)
AWS provides a service to fix this. The “Identity and Access Management” (IAM) Console enables you to create child users separate from your root account. These can either be service users with API access, or full-on user accounts (with access to the AWS Management Console) that you can use for employee accounts.
Each IAM user has managed access to the AWS resources within your account. Access is controlled with Policies, which give out a set of permissions that control what each user can do. These in-depth policies can control just about every action you can do in the AWS Management Console.
You can also manually set a permissions boundary, which acts as a maximum permission that a user cannot go past, overriding any policy that may grant them more. It’s an advanced feature used to delegate permission management to IAM employees, and enables them to create additional service roles without privilege escalation.
How to Set Up IAM Users
From the IAM Management Console, click on the “Users” tab and select “Add User.”
Give it a name, then select how you want this user to access AWS. Programmatic access gives you an access key ID and secret access key, used for authenticating with the AWS API and CLI.
Management Console access enables the user to access the web console, which is what you enable if you’re giving employee access. If you’re setting this up, AWS defaults into giving an auto-generated password and forces the employee to change it when they sign in.
You can give both types of access if you want.
Next, you configure permissions. AWS provides a lot of premade policies, which you can attach directly to the user. You can also create a group and add the user to that group, which enables you to more easily manage multiple users.
Really, we don’t recommend using most of these premade policies. You really don’t want to give “Full Access” to any individual service, and the other alternative is usually “Read Only,” which is probably not enough access by itself. Some of the more fine-tuned permissions are fine, but you should really create your own.
You’ll quickly see why “Full Access” is a bad idea. Say you’re configuring a server that needs to access S3 and upload objects. You might want to give it “Write” access, but this also enables that user to delete entire buckets, which is not ideal at all. A better solution is to give the “PutObject” permission, which enable PUT requests to be made.
These permissions are quite intensive and vary from service to service, but you can always click on the question mark next to the permission name to pull up a quick definition. Otherwise, you can read our guide to IAM Permissions to learn more.
Once you’re done attaching permissions, you can create the user (optionally adding tags first). You’re brought to a screen where you can download or copy the access keys, and if you’re adding management console access, a sign-in link will appear where you can send to the employee holding the account.
Replace Your Root Account with an IAM User
AWS actually highly recommends this for organizational accounts. Instead of using your root account for things like your personal CLI, you should create an “Administrator” IAM User with management console access, and use the access token from it to authenticate your personal terminal.
This doesn’t mean you should treat the credentials for this IAM user as any less secure than your root account—it would still ruin your day to have your administrator account compromised, so you should continue using service accounts for remote applications, and you should still definitely enable multi-factor authentication for your administrator IAM account. Using an IAM user instead of the root account is more secure, however, as there are certain account-wide actions that only the actual root account can perform.
With this setup, the only thing you use your root account for is the super-secure things that are tied directly to your root account, such as account maintenance and billing. For everything else, administrator permissions is enough and enables you to actually delete your root access keys so that you only can access the root account by signing in manually (and passing MFA).
