What is IAM?
Why IAM?
There was a time, not so long ago, when IT was simpler, perhaps even naive. A time when a single username and password was the golden key, passed around like a treasured artefact among teams, granting anyone who possessed it the power to access everything. It was a time of trust, but also a time of vulnerability. A single point of failure, where one misplaced password could lead to catastrophic consequences.
Fast forward to today, and so much has changed. With the advent of AWS Identity and Access Management (IAM), the days of shared logins feel like tales from a bygone era. No longer do we hand over the keys so freely.
Instead, IAM empowers us to grant specific permissions to specific users, ensuring that they have just the right amount of access they need, and nothing more. It's a world where security and flexibility coexist, allowing businesses to thrive without the looming shadow of potential breaches.
What are the fundamental IAM components?
Users:
An IAM user represents a unique identity with specific credentials and permissions. This identity can correspond to an individual or even an application. With IAM, you can enhance security by assigning distinct IAM usernames to every member of your organisation, ensuring controlled access to AWS services. Each IAM user is linked exclusively to a single AWS account (root user). Initially, these users have no permissions for AWS tasks, so have to be assigned separately.
Groups:
An IAM group is simply a group of IAM users. By using IAM groups, you can streamline permission assignments for numerous users; any permissions granted to the group extend to its individual members. Group management is straightforward: assign permissions to the group, and every member instantly benefits. When a new user joins the group, they automatically receive the group's existing policies and permissions, simplifying administrative tasks.
Policies:
An IAM policy defines permissions and governs access to AWS resources, encapsulated as JSON documents within AWS. These permissions delineate both who can access the resources and the actions they're permitted to execute.
Policies fall into two categories:
Managed Policies are pre-defined and can be associated with various entities - users, groups, or roles - in your AWS account. Whether originating from AWS or created by customers, these policies are versatile, standalone directives that can be linked to multiple users or groups.
Inline Policies are custom-made and directly integrated into a singular entity, be it a user, group, or role.
Roles:
IAM Roles are just like a hat, which anyone within AWS can wear, and get the powers presented by the hat, and lose the powers as soon as the hat is removed. The hat does not discriminate between real users or hardware, anyone can wear this hat. In technical terms, an IAM role is an identity you can create that has specific permissions. The only difference being you are not associating this policy to any particular user or services at the time of creation. This IAM role can be assumed by anyone who needs it, be it a user or an AWS resource.
Creating a role consists of 3 simple steps:
Select the trusted entity
Attach a permission policy
Review
Roles for Users - Use Cases:
When you are creating AWS users, you must adhere to the principle of least privileges and only give them access to what they need.
Additionally, organisations typically already have their own email setups so creating individual AWS accounts for each employee is unnecessary duplication. This can be solved with roles and third party sign in integrations.
Roles for Services - Use Cases:
For additional security AWS requires that resources cannot have policies attached directly. AWS also requires that credentials should not be stored on EC2 instances.
Given the above, initially it is not possible for any AWS service to communicate with another AWS service or resource.
Roles - Solution
For both user and service use cases, roles provide a neat solution that allows either users or services to be granted elevated permissions for as long as needed. For example if an EC2 instance requires access to S3 it can be temporarily granted with a role. Likewise employees without an AWS account can gain temporary access to AWS.
How does IAM work?
On top of the IAM components mentioned previously we also need to bear in mind the following processes:
Principal: Can be a user, role, or application that has the capability to act on an AWS asset.
Authentication: Verification of the principal's identity when it tries to access an AWS service, using provided credentials or keys.
Request: What is made by the principal to AWS, detailing the desired action and the targeted resource.
Authorisation: By default, access to resources is restricted. IAM grants permission only if the request aligns with an applicable policy. Once verified and authorised, AWS allows the action.
Actions: Tasks undertaken for example viewing, adding, modifying, or removing resources.
Resources: AWS services / resources on which a series of actions can be executed.
How do I get started?
If you don't already have a Free Tier AWS account then follow this CourseWizz tutorial. The account you create or your main login account for AWS is called the Root User. This account has unrestricted access hence we want to avoid using this account for actual tasks.
Depending on the task we are doing we want to create a separate user with access to only the resources they need to complete the task.
Example 1 - Create a single user with full access to Amazon Simple Email Service
Step 1: Open AWS Console navigate to IAM dashboard - Click on Users
Step 2: Click on Create User
Step 3: Give user a name - Click next
Step 4: Search for and attach SimpleEmailService Full Access policy
Step 5: Confirm creation of user by clicking Create user
Step 6: Click on your new User
Congratulations, you have now created your first IAM user! Depending on your requirements you can utilise this user in many ways!
Example 2 - Create a group for Content Editors
For large organisations with many employees, managing permissions for individual accounts can add significant administrative burden. Thankfully AWS thought of this and allow us to create groups where any member gains the groups permissions. For this example
Step 1: Navigate to groups
Step 2: Create a group
Step 3: Assign permissions to group members
Step 4: Open group to add users
Step 5: Add users to group
Step 6: Finished
Example 3: Roles
In this example we are going to create a role that an EC2 instance can take which will allow it access to S3. The steps to create roles for users are practically identical the only difference being you click on Roles to begin.
Step 1: Click on Create role button
Step 2: Choose service - Select Trusted Entity
Step 3: Search for and assign Policies
Step 4: Confirm Creation
Hopefully you should now have an understanding on IAM and the key moving parts. Stay tuned for more tutorials!