AWS Identity and Access Management (IAM) combines with multi-factor authentication for a powerful and secure solution. We’ll explore using Roles, Groups, and Users for AWS identity and access management.
Welcome to part 5 of this AWS Security Series. Last week we finished looking at VPC Network Security.
This week I’ll explore Identity and Access Management (IAM) — one of the key security services within AWS. This service primarily governs and controls user access to your AWS resources. It achieves this through Users/Group/Roles and Policies. IAM uses a number of critical access methods such as MFA (Multi-factor Authentication) to manage federated identities.
I believe that IAM is an impressively powerful service that must be understood. This week, I’ll focus on Users, Groups, and Roles and touch on MFA.
What’s the difference between IAM Users, Groups & Roles?
There is a distinction between Users, Groups, and Roles, and understanding the difference is pivotal in your deployment of access security within your environment. All of these elements are created and configured through IAM. You can find out more in a popular previous blog post here.
IAM Users are account objects that allow an individual user to access your AWS environment with a set of credentials. You can issue user accounts to anyone you want to view or administer objects and resources within your AWS environment. Permissions can be applied individually to a user, but the best practice for permission assignments is to assign them via the use of Groups.
IAM Groups are objects that have permissions assigned to them via Policies allowing the members of the Group access to specific resources. Having Users assigned to these groups allows for a uniform approach to access management and control.
IAM Roles are again objects created within IAM which have Policy permissions associated to them. However, instead of being associated with Users as Groups are, Roles are assigned to instances at the time of launch. This allows the instance to adopt the permissions given by the Role without the need to have Access Keys stored locally on the instance.
IAM Users
When you first create your AWS root account, that account will have Administrative privileges and you will be able to access everything within your environment. I strongly recommend you do not use this account to perform day to day tasks within your environment. Instead, I encourage you to create a new User account with the required privileges to perform your work. If you need to create further Administrator users, keep it to a minimum for obvious reasons and place them in a single Group.
When creating your User accounts, or any object for that matter, ensure you have a sensible naming convention and adhere to it. This will help with the identification of objects going forward throughout IAM and other services. Only create users who genuinely require access to your AWS infrastructure, those who have a purpose such as providing operational support for your project, for example.
Before you come up with a naming convention for your accounts be mindful that you are not able to use the following characters + = , . @_-. There is also a limit to the number of users who can be associated within your AWS account — which is currently set to 500 Users.
How to Create a User
Use the AWS Console to log in to your account and select Identity Access Management under “Security and Identity”.
When the IAM service opens, you will be presented with the IAM Dashboard. This offers you an overview of your IAM resources and settings. The Dashboard shows a Sign-in link that you can send users once they have an account pointing them to a login URL for your AWS environment. This Dashboard also details the IAM resources you have set up and configured, for example, the number or Users, Groups and Roles you have.
To create your users, select ‘Users > Create New Users’.
Enter the user names on the following screen. Names are limited to a maximum of 64 characters. If your users need to make secure REST or Query protocol requests to AWS APIs, then select the check box to generate access keys for each user. If this is not necessary, un-tick the checkbox and click Create.
Your users are now created and will show up in the Users page of IAM.
Now that your User objects are created, they require a password to sign in. Select the User object and then select ‘User Actions > Manage Password’.
You can allow AWS to generate its own password for the user or you can choose to manually create your own. Either way, you can optionally allow users to change their passwords on their first login. Depending on current security policies, you may choose to select this option or not. When you have made your choices, click Apply.
If you allow AWS to automatically assign the password, the system will use the options specified in your AWS Password Policy. This policy can be found and modified within IAM under Account Settings.
Depending on your own security requirements, you can adapt this policy to fit your existing needs.
From the User window, you are may configure other elements, such as adding the user to a Group, setting up MFA, creating access keys, or deleting the user. All these options are located under the ‘User Actions’ menu.
As I explained earlier, it is possible to set permissions for an individual user. To do this, select the User and click on the Permissions Tab. From here you can attach a policy of permissions. You can use either a predefined policy supplied by AWS or a custom policy that you have written yourself. Remember assigning permissions and policies to individual Users can create headaches, and it’s an accepted best practice to assign permissions using Group associations.
IAM Groups
Groups within IAM are objects that allow you to efficiently manage permissions and access your resources within your AWS environment. Using Groups to control permissions is the desired best practice from a management perspective. This is especially important if you have a large number of users to administer/control. Another advantage of this best practice is when a user changes roles or departments and their responsibilities change, it’s easy to remove them from one group and add them to another without worrying about individual access policies.
Group permissions are governed by policies. There are excellent predefined policies supplied by AWS, and you can always create your own if the predefined policies don’t suit your needs. The policies are scripts that dictate what resources can be accessed and by whom. The policy/script is then attached to a group whereupon users are made members of that group and adopt those set permissions. Next week I will delve deeper into the way these policies are constructed and the best methods of writing your own.
When associating Users with a Group, there is an upper limit of 10 groups per User. You are also limited to 100 groups per AWS account — so be sure to plan your access carefully.
Creating a Group
From within IAM, select ‘Groups > Create New Group’.
Enter a meaningful Group Name (in this example I used ‘RDSFullAccess’) and select ‘Next Step’. Now you need to choose the permissions that will apply to the Group through Policies.
Scroll through the list until you find the permissions that you wish to add (either using AWS predefined policies or selecting your own). For this example, I will use ‘AmazonRDSFullAccess’.
Select ‘Next Step’ to review your selection and select ‘Create Group’.
Your new Group will now appear in the Group section of your IAM Service. However, it won’t yet have any Users associated with it. To associate users, select the ‘Group Name > Add Users to Group’ > Select the Users > Add Users’. Your Group summary will then show the Users that you added. These will now have the permissions given to them by the policy you selected at the Group creation. The below screenshot shows that I added CloudAcademyUser1 and CloudAcademyUser2.
Viewing the IAM Policy Permissions
If you want to view the IAM Policy, select ‘Group Name > Permissions Tab > Show Policy’. This will display the code that is used to create the policy.
For the example we used in this Group Creation, the output is as follows:
IAM Roles
Roles are similar to Groups in that they are objects created within IAM. Instead of providing permissions for Users, they provide permissions for instances, such as EC2. Policies are associated with Roles and during instance creation, a Role can be selected to grant that instance access to whatever the associated policy dictates.
The great benefit of assigning roles to Instances is that it avoids the need to store Access Keys for API calls from the local instance. Storing any kind of access key locally on an instance is a bad practice (especially if you have key information hardcoded within any code held locally on the instance). As a result, Roles allow instances to adopt the permissions required without the use of the access keys being assigned.
As with Users and Groups, there are some associated limitations to Roles. Note that an instance can only be associated with ONE role, but you have the capacity for up to 250 Roles within your AWS Account.
Creating an IAM Role
From within the AWS Console select the IAM Service > Roles > Create New Role > Enter a ‘Role Name’ > Next Step’.
In the above example, I decided that I want an EC2 instance to communicate with S3 and named the Role appropriately.
Once your Role Name is set you need to specify a Role Type:
I want an EC2 instance to call an AWS service (S3) on my behalf, so I select ‘Amazon EC2’.
The next step will look familiar because it’s the same screen from the Group creation when we ‘Attached a Policy’. This step allows you to set the permissions, so I will select AmazonS3FullAccess for my example and Click ‘Next Step’.
In the ‘Review’ screen, confirm that your selections are correct and click ‘Create Role’. Your new Role will now appear under the Roles section within IAM and you can apply that Role to any new Instance. The Role is applied to a new Instance at Step 3: Configure Instance Details when launching your instance.
When the instance is launched with this Role attached, the EC2 instance will make an API request to S3 that it needs without Access Keys. This is a great way to apply permissions to resources.
Take note that you are not able to change the Role of an Instance once it is launched. If you need to change the Role, you must create a new instance and select the new Role. Depending on your circumstances, it may be a good idea to create an AMI of your existing Instance first and then create a new instance using this AMI before selecting the new Role.
Multi-factor Authentication
Multi-factor Authentication (MFA) adds an additional layer of security through the requirement of additional credentials via an MFA device (typically a 6 digit number) on top of the username and password. This number is a randomly generated single-use code that lasts for a very short period of time. At a minimum, MFA should be employed for users who have the greatest privileges, such as Administrators and Power Users.
AWS does not charge for the use of MFA on activated User accounts, but you will need a 3rd party MFA device whether it’s a virtual or physical one. AWS provides a summary of all supported devices here. Personally, I use Google Authenticator for the iPhone because it is simple and easy to set up & configure.
Setting up a user for MFA
From within the AWS Console, select ‘IAM > Users > Select User > User Actions > Manage MFA Device’.
Select the Virtual or Physical Device (in this example we will use the Google Authenticator on the iPhone) and select ‘Next Step’.
After confirming you have a valid virtual MFA Device open Google Authenticator on your phone, scan the QR Code, then enter the codes in the corresponding boxes.
Once the codes have been entered you will be notified that your MFA device was successfully associated. From now on, when the users log in they will be prompted with the following screen.
bios grub 1.5
Users will then need to open Google Authenticator and enter the corresponding code and access will be granted. This adds a powerful additional protective layer, making your resources significantly harder to hack.
Let’s summarize what we’ve covered this week:
• Identity & Access Management: What it is and why it’s an important Service for controlling access to resources within your AWS environment
• Users: How to log into the AWS environment and why a corresponding User account is required with specified credentials
• Groups: How they allow multiple users to gain access to resources by associating policy permissions
• Roles: How roles help maintain security by preventing the use of Access Keys to be held locally on Instances
• Multi-factor Authentication. How MFA can be used to increase security by adding an additional layer of credentials
If you want to start a project and need further guidance I suggest you spend a few minutes reviewing an Introduction to IAM by David Clinton. Next week I’ll be looking at IAM again, but I will dig deeper into the best ways of creating your own policies — including the syntax and format. I’ll also explore the AWS Policy creator and simulator. In the meantime, I recommend a solid lab Introduction to IAM Lab where you can use your new knowledge to build lasting skills.
Thank you for taking the time to read my article. If you have any feedback please leave a comment below.
If you’re interested to learn more about AWS Identity & Access Management, I recommend the Cloud Academy’s AWS: Overview of AWS Identity & Access Management (IAM). Watch this short video for an overview of the course.
