"I'll send you my AWS username and password, log in and take a look." It is what everyone does and it is the worst possible idea: that person can do anything, you will not know what they did, and when they stop working with you, you will have to change your password and hope they did not write it down. AWS is designed so that each person has their own user with just the right permissions: the outside technician who should only look, the accountant who only needs the invoices, the colleague who operates two machines. This guide creates one of those users and locks it down properly.
Before you start: what each thing means
- IAM
- The AWS service where users are created and permissions are assigned to them.
- IAM user
- An identity of its own inside your account, with its own name, password and permissions. It is not another AWS account: it is a person inside yours.
- Policy
- The list of permissions assigned to a user. AWS ships many ready-made ones (read only, billing, administrator...) and you can write your own.
- Group
- A set of users who share the same policies. More convenient than assigning permissions one by one.
- Two-factor authentication (MFA)
- The code from your phone when you sign in. You can require it from each user.
- Account alias
- An easy name for your account's sign-in address, instead of the twelve-digit number.
- IAM Identity Center
- AWS's more modern system for managing people, designed for companies with several accounts. For one account and a few people, IAM users are enough.
Step by step
Decide what they should be able to do
Three profiles cover almost everything: view only (a technician who diagnoses, an auditor): the
ReadOnlyAccesspolicy; billing (the accountant): theAWSBillingReadOnlyAccessorBillingpolicy, and you will have to enable "IAM user access to billing" in Account; operate a few machines (a colleague): a custom policy with the view, start and stop actions, like the one in the minimum-permissions guide. NeverAdministratorAccessunless they really are an administrator.Give the account an alias
In IAM, on the main dashboard to the right, Account Alias, Create:
miempresa. Your users' sign-in address becomeshttps://miempresa.signin.aws.amazon.com/console, much easier to hand out than a number.Create a group with the permissions
IAM, User groups, Create group: name
solo-lectura(or whatever the profile is), and in the policy list tick the one that applies. Create. Permissions are assigned to the group; people are simply added to the group. When a permission has to change, you change it once for everyone.Create the user
Users, Create user. Name: the person's name (
ana.garcia), not "external1". Tick Provide user access to the AWS Management Console, choose Autogenerated password and leave Users must create a new password at next sign-in ticked. Next: Add user to group and tick the group. Create. The last screen shows the sign-in address, the username and the temporary password: send them through two different channels (the address and username by email, the password by message), never together.Require two-factor authentication
Ask them, once signed in, to go to their name at the top right, Security credentials, and assign an MFA device using the app on their phone. To make it truly mandatory, there is a well-known AWS policy that denies everything until the user sets up MFA; the IAM documentation has it ready to copy ("Allows MFA-authenticated IAM users to manage their own credentials"). Add it to the group.
Remove their access when they are done
When the collaboration ends: IAM, Users, select the person, Delete. If you would rather keep the user in case they come back, Security credentials, Disable console access. And once a quarter, look at the Last activity column in the user list: anyone who has not signed in for months probably no longer needs it.
What can go wrong
The user signs in but sees nothing or gets permission errors
That is expected outside what their policy allows. If something legitimate is missing, the error message says which action, and you add it to the group's policy. If it is read only and they see "not authorized" in billing, IAM access to billing still needs to be enabled in the account settings.
They need to do one specific thing that is not in any AWS policy
Write a custom policy with that action (minimum-permissions guide). It is usually easier than it looks: the name of the action is in the error message.
We are more than ten people and several accounts
That is when IAM Identity Center makes sense: a single sign-in for all accounts, with permissions by permission set. More setup at the start, far less work afterwards.
An outside contractor asks me for an access key instead of a console user
If they are going to use programs, that is reasonable; give them a user without a console password, with an access key and minimum permissions, or better still a cross-account role (guides in this section). And have them rotate it.
In Simplio
In Simplio you invite a person by email and tick boxes for what they can do (view, start and stop, snapshots, files, terminal) and on which machines, buckets or databases; they sign in with their own user and mandatory two-factor authentication, without ever touching your AWS account or knowing any key. When they stop working with you, you deactivate them with one click and everything they did stays in the activity log.
The same task, in AWS and in Simplio
| In the AWS console | In Simplio | |
|---|---|---|
| Give limited access to a person | Alias, group, policy, user, MFA, two channels: 6 steps, 15 minutes if you know which policy | Invite by email and tick boxes: view, start/stop, snapshots, terminal, and which machines. 1 minute |
| Two-factor authentication | Ask for it and trust them, or an advanced policy | Mandatory for every Simplio user |
| Remove access | IAM, search, delete | Deactivate the user; their actions stay in the activity log |