Creating an AWS IAM Policy: AWS Security
However you choose to do it: your AWS IAM policy must be a good fit for your application's actual access needs. We'll discuss three ways to get it ...Learn More
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.
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.
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.
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.
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.
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.
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.
• 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.
July has been a very exciting month for us at Cloud Academy. On July 10, we officially joined forces with QA, the UK’s largest B2B skills provider (read the announcement). Over the coming weeks, you will see additions from QA’s massive catalog of 500+ certification courses and 1500+ ins...
If you are just starting out on your journey toward mastering AWS cloud computing, then your first stop should be to understand the AWS fundamentals. This will enable you to get a solid foundation to then expand your knowledge across the entire AWS service catalog. It can be both d...
The DevOps Handbook introduces DevOps as a framework for improving the process for converting a business hypothesis into a technology-enabled service that delivers value to the customer. This process is called the value stream. Accelerate finds that applying DevOps principles of flow, f...
The speed at which machine learning (ML) is evolving within the cloud industry is exponentially growing, and public cloud providers such as AWS are releasing more and more services and feature updates to run in parallel with the trend and demand of this technology within organizations t...
AWS re:Inforce 2019 is a two-day conference for security, identity, and compliance learning and community building. This year's keynote, presented by AWS Vice President and CIO, Stephen Schmidt, announced the general availability of AWS Control Tower and the new VPC Traffic Mirroring fe...
Being able to architect your own isolated segment of AWS is a simple process using VPCs; understanding how to architect its related networking components and connectivity architecture is key to making it a powerful service. Many services within Amazon Web Services (AWS) require you t...
AWS is renowned for the rate at which it reinvents, revolutionizes, and meets customer demands and expectations through its continuous cycle of feature and service updates. With hundreds of updates a month, it can be difficult to stay on top of all the changes made available. Here ...
Amazon Web Services (AWS) offers three different ways to pay for EC2 Instances: On-Demand, Reserved Instances, and Spot Instances. This article will focus on effective strategies for purchasing Reserved Instances. While most of the major cloud platforms offer pre-pay and reservation dis...
If you’re building applications on the AWS cloud or looking to get started in cloud computing, certification is a way to build deep knowledge in key services unique to the AWS platform. AWS currently offers 11 certifications that cover major cloud roles including Solutions Architect, De...
The AWS Solutions Architect - Associate Certification (or Sol Arch Associate for short) offers some clear benefits: Increases marketability to employers Provides solid credentials in a growing industry (with projected growth of as much as 70 percent in five years) Market anal...
Moving data to the cloud is one of the cornerstones of any cloud migration. Apache NiFi is an open source tool that enables you to easily move and process data using a graphical user interface (GUI). In this blog post, we will examine a simple way to move data to the cloud using NiFi c...
Amazon DynamoDB is a managed NoSQL service with strong consistency and predictable performance that shields users from the complexities of manual setup. Whether or not you've actually used a NoSQL data store yourself, it's probably a good idea to make sure you fully understand the key ...