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.
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.
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:
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 (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.
New Content: Alibaba, Azure AZ-303 and AZ-304, Site Reliability Engineering (SRE) Foundation, Python 3 Programming, 16 Hands-on Labs, and Much More
This month our Content Team did an amazing job at publishing and updating a ton of new content. Not only did our experts release the brand new AZ-303 and AZ-304 Certification Learning Paths, but they also created 16 new hands-on labs — and so much more! New content on Cloud Academy At...
Blog Digest: Which Certifications Should I Get?, The 12 Microsoft Azure Certifications, 6 Ways to Prevent a Data Breach, and More
This month, we were excited to announce that Cloud Academy was recognized in the G2 Summer 2020 reports! These reports highlight the top-rated solutions in the industry, as chosen by the source that matters most: customers. We're grateful to have been nominated as a High Performer in se...
Which Certifications Should I Get?
The old AWS slogan, “Cloud is the new normal” is indeed a reality today. Really, cloud has been the new normal for a while now and getting credentials has become an increasingly effective way to quickly showcase your abilities to recruiters and companies. With all that in mind, the s...
New Content: AWS, Azure, Typescript, Java, Docker, 13 New Labs, and Much More
This month, our Content Team released a whopping 13 new labs in real cloud environments! If you haven't tried out our labs, you might not understand why we think that number is so impressive. Our labs are not “simulated” experiences — they are real cloud environments using accounts on A...
Kickstart Your Tech Training With a Free Week on Cloud Academy
Are you looking to make a jump in your technical career? Want to get trained or certified on AWS, Azure, Google Cloud Platform, DevOps, Kubernetes, Python, or another in-demand skill? Then you'll want to mark your calendar. Starting Monday, June 22 at 12:00 a.m. PDT (3:00 a.m. EDT), ...
New Content: AZ-500 and AZ-400 Updates, 3 Google Professional Exam Preps, Practical ML Learning Path, C# Programming, and More
This month, our Content Team released tons of new content and labs in real cloud environments. Not only that, but we introduced our very first highly interactive "Office Hours" webinar. This webinar, Acing the AWS Solutions Architect Associate Certification, started with a quick overvie...
Azure vs. AWS: Which Certification Provides the Brighter Future?
More and more companies are using cloud services, prompting more and more people to switch their current IT position to something cloud-related. The problem is most people only have that much time after work to learn new technologies, and there are plenty of cloud services that you can ...
Blog Digest: 5 Reasons to Get AWS Certified, OWASP Top 10, Getting Started with VPCs, Top 10 Soft Skills, and More
Thank you for being a valued member of our community! We recently sent out a short survey to understand what type of content you would like us to add to Cloud Academy, and we want to thank everyone who gave us their input. If you would like to complete the survey, it's not too late. It ...
New Content: Alibaba, Azure Cert Prep: AI-100, AZ-104, AZ-204 & AZ-400, Amazon Athena Playground, Google Cloud Developer Challenge, and much more
This month, our Content Team released 8 new learning paths, 4 courses, 7 labs in real cloud environments, and 4 new knowledge check assessments. Not only that, but we introduced our very first course on Alibaba Cloud, and our expert instructors are working 'round the clock to create 6 n...
Top 5 Reasons to Get AWS Certified Right Now
Cloud computing trends are on the rise and have been for some time already. Fortunately, it’s never too late to start learning cloud computing. Skills like AWS and others associated with cloud computing are in high demand because cloud technologies have become crucial for many businesse...
Introducing Our Newest Lab Environments: Lab Playgrounds
Want to train in a real cloud environment, but feel slowed down by spinning up your own deployments? When you consider security or pricing costs, it can be costly and challenging to get up to speed quickly for self-training. To solve this problem, Cloud Academy created a new suite of la...
Blog Digest: AWS Breaking News, Azure DevOps, AWS Study Guide, 8 Ways to Prevent a Ransomware Attack, and More
New articles by topic AWS Azure Data Science Google Cloud Cloud Adoption Platform Updates & New Content Security Women in Tech AWS Breaking News: All AWS Certification Exams Now Available Online As an Advanced AWS Technology Partner, C...