What permissions to give a new employee in AWS (and which not to)

Someone new joins the company and needs "access to AWS". The quick way is to create a user, give them AdministratorAccess and get on with the day. It is also what turns an intern's mistake, or a stolen password, into an empty account or a bill for thousands of euros. Almost every AWS scare in small companies starts with someone who had far more permissions than they needed.

The rule is simple: each person can do only what they need for their job, and nothing more. It is called least privilege and it does not require knowing about security. It requires thinking for a minute about what that person is going to do: look? start and stop machines? create and delete things? With that answer, AWS already has the permissions ready and you only have to choose them.

This guide uses groups instead of giving permissions to each user one by one. It is the difference between deciding once per role and deciding every time someone joins.

Step by step

1. Decide what role the person has

   Before touching the console, answer one question: what does this person have to do in AWS? For a small company, almost everything fits into three roles:

   • View: look at the state of the machines, check the bill, read logs. It is what someone doing support, someone keeping the books or a boss who wants to "see how it is going" needs.
   • Operate: in addition to viewing, start, stop and reboot machines, take snapshots, restore. It is what the person running the server day to day needs.
   • Administer: create and delete machines, change networking, manage users. Only one or two people need this, and they should be the ones who know the most.

   If you hesitate between two, start with the one with fewer permissions. Going up is one click; finding out that someone deleted something they should not have is not.

2. Create the three groups in IAM

   Open IAM, left-hand menu User groups, Create group button. Make three, with names anyone understands: ver, operar and administrar. When creating each group, in the Attach permissions policies block search for and tick the policy that belongs to it:

   • Group ver: ReadOnlyAccess. Allows querying any service without changing anything. If you only want them to see the bill, there is AWSBillingReadOnlyAccess, more limited.
   • Group operar: ReadOnlyAccess plus a custom policy with the start, stop and reboot actions (next step). For Lightsail there is no intermediate managed policy, so you will write it yourself; for EC2 there is none either that only starts and stops.
   • Group administrar: PowerUserAccess, which allows almost everything except managing users and permissions. Leave AdministratorAccess for a single person, the one who also keeps the root account.

   Groups are created once. From then on, giving someone access means putting them in the right group.

3. Write the "operate" group's policy

   In IAM, Policies, Create policy. Click the JSON tab and paste this, which allows starting, stopping and rebooting Lightsail and EC2 machines, and taking snapshots, but not creating or deleting machines:

   {
     "Version": "2012-10-17",
     "Statement": [
       { "Effect": "Allow", "Action": [
           "lightsail:StartInstance", "lightsail:StopInstance", "lightsail:RebootInstance",
           "lightsail:CreateInstanceSnapshot",
           "ec2:StartInstances", "ec2:StopInstances", "ec2:RebootInstances",
           "ec2:CreateSnapshot"
         ], "Resource": "*" }
     ]
   }

   Click Next, name it operar-maquinas and create it. Then, in User groups, open operar, Permissions tab, Add permissions, Attach policies, and tick operar-maquinas.

   Notice that no action with "Delete" or "Terminate" appears. It is the difference between being able to shut down a machine and being able to make it disappear. If you also want to limit it to specific machines, in Resource you can put each one's identifier instead of the asterisk; for EC2 it is simple, for Lightsail you have to use each instance's ARN.

4. Create the user and put them in a group

   IAM, Users, Create user. Name: the person's (maria.lopez), never something shared like soporte. Tick Provide user access to the AWS Management Console, choose I want to create an IAM user and leave ticked that the user must create a new password at next sign-in.

   On the permissions screen choose Add user to group and tick only the group you decided on in step 1. Do not attach policies directly to the user: in six months nobody will remember why they have that stray permission. Create the user and note the sign-in URL (it carries your account number) to send it along with the temporary password through different channels: the URL by email, the password in person or in a message that expires.

   If the person is not going to use programs that talk to AWS, do not create access keys. They can be added the day they are needed.

5. Make two-factor authentication mandatory

   Ask the person, on their first login, to go to their name menu, Security credentials, and assign an MFA device with the phone app. But do not leave it to goodwill: in IAM, Policies, create a policy that denies everything except setting up MFA when the user has not signed in with two-factor authentication, and attach it to the three groups. AWS has it as an example in its documentation under the name "allow users to manage their own MFA"; copy the JSON from there as is.

   The effect: whoever signs in without MFA only sees the screen to enable it. Everything else appears blocked until they do. It is the only way to make sure everyone really has it.

6. Review what nobody should have

   Before considering the onboarding closed, go over IAM, Users, attached policies column:

   • AdministratorAccess on more than one or two people: too many. Nobody who only operates machines needs it.
   • IAMFullAccess on someone who does not manage users: with that permission they can grant themselves any other.
   • Permissions attached directly to the user instead of through groups: move them to the group or delete them.
   • Access keys on users of people who do not program anything.

   If you find any of this on old users, take the chance to fix it. It is the moment when it is easiest.

7. Prepare the offboarding from day one

   The day someone leaves, their access to AWS must disappear the same day, before they hand in the computer. In IAM, Users, select the user: first deactivate console access and access keys (Security credentials tab), wait a week or two to check that nothing depended on that person, and then delete the user.

   Put it on the leaving checklist along with the email and the office keys. And once a quarter, download the IAM Credential report: it tells you for each user when they last signed in, whether they have MFA and whether their keys are used. A user who has not signed in for three months is a user who probably should no longer exist.

What can go wrong