QwikLabs: Introduction to AWS Identity and Access Management (IAM)

AWS facilitates security and user control over accounts through IAM. In a business environment, there would be different restrictions on certain accounts pertaining to their respective level of clearance within the business system. This QwikLabs course aims to provide a basic understanding of how to manage and utilize the IAM system for various accounts.

Topics covered in this Lab

  • Exploring pre-created IAM users and groups
  • Inspecting IAM policies as applied to the pre-created groups
  • Following a real-world scenario, adding users to groups with specific capabilities enabled
  • Updating passwords for users
  • Locating and using the IAM sign-in URL
  • Experimenting with the effects of policies on service access

Exploring Users and Groups

AWS Management Console –> Services –> IAM

In the lab, there are already three users set up: “userone”, “usertwo”, and “userthree”. Since the lab is being used as a guideline, rather than practical use, I need to set up three new users on my own AWS account in order to follow through with the instructions given in QwikLabs.

Username Password

This is where the lab script and my practical application of it, start to differ. Rather than add groups to the already created users, I will add the user to one of the script suggested groups as part of the user set-up.

UserUno: Group  = “EC2Support”, Attached Policies = “SupportUser”
UserDos: Group = “EC2Admin”, Attached Policies = “SystemAdministrator”
UserTres: Group = “S3Admin”, Attached Policies = “DatabaseAdministrator”

Determining what policies to attach to these groups was harder than I first anticipated. Having never looked around at all the different policies available before, I was slightly overwhelmed. However, I looked around at my choices and realized that I could define the polices by their job functions. From this point onward I sought help from the AWS user guide and from the code supplied under each policy choice.

The AWS policy user guide can be found here: docs.aws.amazon.com/IAM/latest/UserGuide/access_policies_job-functions.html?icmpid=docs_iam_console

Setting Passwords
Once the three new users had been created and associated with a group, I logged into each user and was forced to create a new password. The new passwords had to follow certain specifications that I had arranged prior through my Administrator account.

Password Settings

Experimentation of Policies on Access
This part involves the application of my accounts to determine whether I have grouped them with the right access restrictions and permissions.

  • UserUno: User Uno is under the group labelled “EC2 Support”. As such, I organized with the job policy of “SupportUser”, which the AWS Policy User Guide records as ‘This policy grants permission to create and update AWS support cases.’ The user in this case can ‘contact AWS support, create support cases, and view the existing cases.’

With this is mind, I gave UserUno three tasks: View other users, access EC2, and access S3 buckets.

Access other users:
InkedUno User Permission_LIResult: UserUno has permission to see other users.

Access EC2
InkedUno EC2_LIResult: Uno can access EC2

Access S3 bucket
InkedS3 uno_LIResult: Uno cannot access the bucket

Conclusion: The job policy of UserSupport for Uno has many of the required authorizations, but is not quite correct as it shouldn’t be able to access EC2.

  • User Dos: User Dos is labelled under the group “EC2Admin”, and has the job policy of “SystemAdministrator”. The AWS Policy Guide states that ‘This user sets up and maintains resources for development operations.’ To gain a more comprehensive understanding of this user’s role, I gave it the three tasks I had given User Uno.

Access other Users:InkedDos user permission_LI
Result: Dos does not have permission to manipulate the other users

Access EC2:
InkedInstance Dos_LI
Result: Dos is able to access EC2

Access S3 bucket:
Inkeds3 dos_LI
Result: Dos is able to access S3 buckets

Conclusion: Again Dos’ job policy incorporates most of the features that I desired. However Dos should only be able to access EC2 as EC2Admin, but not S3.

  • User Tres: User Tres is labelled under the group “S3Admin” and has been assigned the job policy of “DatabaseAdministrator”. The AWS Policy Guide states that ‘This user sets up, configures, and maintains databases in the AWS cloud.’ Below are the results of the three tasks.

Access other users
InkedTres User Permission_LI
Result: Tres is unable to access other users

Access EC2:
InkedInstance Tres_LI
Result: Tres is unauthorized to access EC2

Access S3 bucket:
InkedS3 tres_LI
Result: Tres is able to access the S3 bucket

Conclusion: The job policy applied to Tres is exactly what I want for a user that is an S3Admin only.

Final Remarks
Although this practical digressed from the QwikLab script due lack of pre-created users, the application still provided me with plenty of information into how to create and define users within AWS. The job policies that I had associated with users Uno and Dos weren’t quite what I was after. Perhaps, the minor discrepancies of the chosen job policies could be resolved by using some inline policies, which, as the AWS guides defines, are policies inherent or unique to a user.