Welcome to the first article of a series called 'Let's Learn' that I will be creating to share knowledge around a variety of topics - the first being Amazon Web Services (AWS).
Note: This series assumes no prior practical knowledge of AWS - for an overview of what AWS is you can get started here. We will use the AWS free tier for this series - but be mindful that not all services are within the free tier and can incur costs if not careful.
Amazon Web Services (AWS) Identity and Access Management (IAM) system provides a security blanket for individuals and organisations - enabling them to set boundaries to what is accessible, and what privileges they have within the context of AWS and the services it provides.
Previously organisations or individuals may have shared private credentials such as an admin password for their services through email, phone, instant messaging or other mode of communication which is unsecure therefore a risk. With IAM, organisations and individuals can be confident in who, what, and how users interact with the services tied to their organisation or themselves.
Since AWS can be used in both global and regional contexts (learn more about regions here) - it’s good to note that IAM is a global service (not tied to a specific region) which enables users to control AWS services across all regions - kind of like an umbrella covering all available services that controls the users access rights. This allows these access rights to be propagated across all AWS services. This will become clearer in practice, but for now understanding that the ability to create, remove and change services is configured in a global context.
We will learn about users and groups within the IAM service. Note that the instructions do not contain screenshots as it’s good to familiarise yourself with the AWS console layout.
First we have to sign up for an AWS free tier account if you don’t already have one. You can do that here. Once you are signed up - Search for the IAM service, which will bring you to the IAM dashboard. You will notice the Security Status steps with warning icons - nothing to fear! We will work through these to ensure our IAM service meets the security needs AWS sets.
Let’s begin by working through the following steps:
Step One: Activate Multi Factor Authentication (MFA) 🔐
- This is a common step of securing most types of accounts, and you can learn more about MFA specifically here
Step Two: Create an individual IAM user 👤
Guidelines surrounding IAM users:
- We should never use our root account (the account level set when we first sign up) to interact with AWS - so creating a user (which will be yourself) will avoid potential risks related to the root user privileges a default AWS account has
- Use one IAM user per physical person - avoid the sharing of account credentials and access by assigning each physical user to a IAM user
- Never store IAM credentials in code, or other unsecure places. This will ensure the safety of your services and resources in AWS
Creating the user
The user in this context will be ourselves. In an organisation this could be
another developer, manager or other role.
- Click 'Add User'
- Enter a username for this user (This is how the user will be identified within AWS and for logging in)
- Select the Access Type for the user - For our use case select AWS Management Console access - This will enable the user to login to the console and control services they have permissions for.
- Choose to use an auto-generated or custom password (Either works as an individual user, or adding another user - in the case you are adding another user you will need to communicate this to them)
- Select 'Require Password reset' - This is a great safety measure for users to create and confirm their own password once they login to access the AWS console
- Click 'Next: Permissions'
Adding the permissions
What each user is able to access and configure within AWS
- Best practice is to use groups for all users - These could be company specific functions such as Engineering and Design, or more role specific such as Development, DevOps, Admins etc
- It’s best to give the user the least amount of permissions to perform the tasks needed - for example a developer in a team may need to be able to create, remove or modify servers or storage settings - but they do not need access to the billing dashboard - this is at the discretion of the user creating others
- Select the appropriate permissions 'Add user to a group'
- Click 'Create group' and give it a name - In this case let’s call it admin
- Add a permission policy - which is a defined set of boundaries on actions the user can perform. An admin could have full access to the AWS services and resources, so we will select AdministratorAccess policy - An organisation may choose to use differing policies for user types, or create their own. Users automatically get the IAMUserChangePassword policy to allow them to change their own password
- Create a tag for the user - this is a key value pair which allows you to describe the role or other information for the user. This is optional but often good to differentiate users.
- Review the settings and click 'Create User'
- You should see a success screen with the options to download the user credentials as a CSV file, or send an email to the user with their login credentials - The password will have to be provided to them separately in a secure manner. As we have created our own password earlier when creating the user - this will be used to login the first time
Step Three: Use groups to assign permissions 👥
Assign permissions to your IAM users
- This has been completed in the previous step when creating a group for the user. The created user should be part of the group
Step Four: Apply an IAM password policy 🔏
Ensure all users create a strong password and configure if these should be changed, and how often
- This is personal preference - you can decide the criteria a user has to fulfil to have a strong password. This is optional but highly recommended. Here are some tips for a more secure password
Step Five: Rotate Access keys 🔑
Access keys are used to interact with the AWS Application Programming Interface (API)
- This is out of scope for this tutorial but it is good to know that it is recommended that these should be changed yearly and unused keys should be removed to reduce the risk of exposure of your AWS services
If you have completed the steps above and have created a user in IAM, congratulations! 🎉🥳 Awesome stuff - Often the biggest barrier to learning the unknown is starting - and you have taken that first step. If you are stuck, or need help in any way - reach out in the comments section below or tweet me @geordidearns and i’ll be super happy to help you solve the issues you have 😄 - Note the additional resources below to help you dig a little deeper or have another take on what we have achieved.