Setting up your Identity and Access Management for AWS
Before we can get started using AWS we need to set up Identity and Access Management specifications for the user(s) you will want to allow access to your EC2 instances, storage buckets and other services you or your team may use. The gist of the IAM management settings is to give specific users specific permissions to access only the services and data they will need during the development and deployment process.
Here you can find some information on IAM best practices and how to remove root access to your account, but first, we need to create a user for your account.
Clicking through to the IAM page from the AWS console will bring you to a checklist of options that you will need to configure to ensure that your account is secure. The first item on the list is “Delete root access keys”, when you click on it a drop down will appear with a button that says “Manage Security Credentials”, click on it. A pop-up should appear with two options, “Continue to Security Credentials” and “Get Started with IAM Users”. The first thing we are going to do is create your user so lets click “Get Started with IAM Users”. This should bring you to a blank list of users (assuming you have not created a user to this point); at the top of the page there is a blue button that says “Add User”, click it.
A warning from AWS:
Don’t use your AWS root account credentials to access AWS, and don’t give your credentials to anyone else. Instead, create individual users for anyone who needs access to your AWS account. Create an IAM user for yourself as well, give that user administrative privileges, and use that IAM user for all your work.
User creation is a four step process that will ask us to set the details of the user account; these include the User Name and access types, the AWS permissions groups you would like to give this user access to, a review of the new user, and creation.
Step 1: Details
Enter your desired user name in the field provided and select your AWS access type. The AWS access type is where you are going to define the initial access permissions this user is going to have. Selecting ‘programmatic access’ is going to supply your user with an AWS ‘access key ID’ and ‘secret access key’ that will be used in your web app environments to access the AWS API, CLI, SDK and other development tools (we will discuss these keys and what they are used for in future posts). Selecting the ‘AWS Management Console access’ option will give this user access to AWS console you are currently using. I would also recommend you keep the ‘Auto-generate password’ and ‘Require password reset’ options selected. When you are finished, click ‘Next: Permissions’.
Step 2: Permissions
Setting the permissions for your user includes creating a ‘Permissions Group’ and defining policies for that group. There are dozens of policies available but we are simply going to assign one policy to our group and our new user. Ensure you have the ‘Add user to group’ tablet selected, then click on the ‘Create group’ button to get started.
Use AWS-define policies to assign permissions whenever possible:
We recommend that you use the managed policies that are created and maintained by AWS to grant permissions whenever possible. A key advantage of using these policies is that they are maintained and updated by AWS as new services or new APIs are introduced.
Within the ‘Create group’ pop-up we can assign one or multiple policies to a policy group. In the window, define a group name, and for this user and group we are going to add the “AdministratorAccess” policy to the group (in the search bar at the top of the policy selection window, type “Admin” and press enter).
Find the “AdministratorAccess” policy and select it, click the ‘Create Group’ button at the bottom of the window. The new policy group should appear in the group selection window on the permissions page, if it is not selected, select it and press the ‘Next: Review’ button at the bottom of the page.
Use groups to assign permissions to IAM users:
Instead of defining permissions for individual IAM users, it’s usually more convenient to create groups that relate to job functions (administrators, developers, accounting, etc.), define the relevant permissions for each group, and then assign IAM users to those groups. All the users in an IAM group inherit the permissions assigned to the group. That way, you can make changes for everyone in a group in just one place. As people move around in your company, you can simply change what IAM group their IAM user belongs to.
Step 3: Review
This page will provide you with an overview of the user you have created, the access type that user has, your password options and the permissions group(s) you have supplied for the user. If you are satisfied, you may click the ‘Create User’ button at the bottom of the screen, or, if you would like to make a change, you can click previous.
Step 4: Create
After a moment, your user will be created and you will be redirected to the complete screen. A flash message will appear at the top of the screen if the user was created successfully and some omitted password and key information will be displayed for your user. If you would you like, you can select to have this information emailed to you using the option in the user row.
To conclude, what we have done here is created your first AWS identity or user. In this case, the user is you. AWS will allow you to create multiple users and provide them with specific access to only the services you want them to have access to. You can control these permissions by assigning your user either Programmatic access and/or AWS Console access on the user details screen, and by selecting the policy groups they belong to.
In the tutorial we assigned the user we crated AdministrativeAccess under the assumption that the user we created belongs to you, the AWS account holder. If we were assigning access to this account to another team member of yours, and we knew that team member might need access to the S3 storage services, we can can create a security group that includes access to S3 and add the user to only that group. AWS ‘best practices’ always suggest you “grant least privilege” to any user on the account. This mean that when we create a new user, and assign that user’s role, we only add permissions to services we know they are going to need access to. If that user requires access to another service in the future, the administrator can modify the user’s credentials to include that new service when demanded.
From the AWS Identity Access Management Docs:
One feature that can help with this is the Access Advisor tab, which is available on the IAM console Summary page whenever you inspect a user, group, role, or policy. This tab includes information about which services are actually used by a user, group, role, or by anyone using a policy. You can use this information to identify unnecessary permissions so that you can refine your IAM policies to better adhere to the principle of least privilege.
As the documents suggest, it is always a good idea to review which users are using which services and compare their security group access to their actual practice. If a user has access to services they are not utilizing in the course of their work, we can remove permissions to those services from the user. This allows us to tie up loose ends and makes our account more secure. If a team member compromises their account and they only have access to what it is they use, we can easily figure out what information and data has been compromised.
Originally published at www.nzenitram.com on December 4, 2016.
