Amazon IAM - The Backbone of AWS

7 min readMay 23, 2022

Background

In my previous post, I shared some security best practices cloud engineers can adhere to when developing applications on AWS.

The purpose of this post is to go into depth explaining the main AWS service behind all of those measures that makes security possible: Amazon Identity & Access Management (IAM).

IAM at a High-Level

Amazon Identity & Access Management comprises of a system of entities that can gain (or request to gain) access to an AWS application. Entities can literally be anything — other applications/services, human users, outside requests, the list goes on.

At a high-level, IAM provides a hierarchical system of rules to either allow or deny access to other entities.

Key Players of IAM 🧩

These are the key components at play when it comes to IAM security:

Resource: This is the (or really any) application/service that is worth protecting. Could be a SPA (Single-Page Application) hosted and stored via S3. An event-driven serverless API built using Lambda. A database in RDS. An always-up-and-running API built using containers (ECS or EKS).
Policy: This is the system(s) of rules that say what/who can or cannot do something on either a single resource, or a group of resources.
Action: The specific action(s) or anything someone can do inside the AWS Cloud environment. Could be something like: DELETE contents from a bucket(s), Create an IAM User, etc. the list goes on.
User: An IAM User (not to be confused with AWS database users). IAM Users belong to AWS Accounts. One of them being the Root user. NEVER use Root for ANYTHING!
Group: A set of users with the same permissions granted (or denied).
Principal: The actual user or application/service requesting access to a resource.
Role: A set of permissions provided to a principal. Typically for an allowed period of time, until the access is no longer required.

So.. Why is IAM being called the backbone of AWS? 🤔

IAM is super important for maintaining and enforcing Least-Privileged Access to resources in AWS Cloud.

Responsible Cloud Engineers must ensure that each application/user that is connecting to their service/application has only the privileges required for a specific purpose.

Some quick examples:

You do not want a Lambda that uploads your monitoring logs to your log bucket to have WRITE access to your actual application bucket.
You do not want your automated Glue Job to overwrite the data snapshot in RDS for May 21. ONLY create new records for the day it has ran (i.e. May 22).
You would not want just any Redshift DB User to automatically have permissions to CreateGroup or JoinGroup once created.

Now, what does Amazon IAM provide? 🤔

Least-Privileged Access: Any user/entity is ONLY given the access it needs for a specific request. This helps enable granularity.
Granular Access: The set of permissions that dictate and control each action that can be applied on a resource. Quick example: An IAM User may have permissions to see an S3 Bucket, but might not have permissions to change bucket policies or the bucket contents itself. This is highly-tied an implemented via role-based access management.
Authentication: Telling something (or someone) and verifying who you are. Or what is the application/service trying to connect.
Authorization: Once authenticated, process of identifying whether something or someone can perform the action(s) they are requesting to make.
Governance: The process or set of action AWS Account Administrators in organizations implement to know what is happening within their company’s AWS Accounts. For security, compliance, and budgetary purposes to ensure least-privileged access.

If you are part of a large organization with numerous departments and numerous teams within those departments, you must use IAM Solutions to scale application access to ensure security.

So, what happens if IAM is not implemented? 🔥🔥🔥

I won’t cover all the mishaps that can happen. Just some of the major ones to scare you enough to consider IAM. 🙂

Increased Risk of Insider Threats 👾

When an employee (or groups of employees) possess more access than they need. And nobody knew.

They leave to another team (or company), but still have access because they have not been offboarded.

How would you audit such access? How would you administer any access to new employees?

Arduous Account Setup & Time-Consuming (loss to business) 💸

If you use IAM-based solutions to administer account setup and access, this part becomes just a matter of a few minutes with a few clicks.

Pretty much, you would ideally just setup the users, and nest them under the same IAM Groups that their teams are part of. Boom, done!

Now, what if you did not have IAM Groups to add new users to? You’d need to grant and setup permissions for EACH account/user manually by hand. Which is error-prone, time-consuming, and highly unsafe.

Now granted, you may just have a reference account or user to copy the similar permissions settings from. But then you should ask yourself — does every new account have to have all of the permissions the reference account/user has? How would you handle user accounts older than say 6 months? Less than 6 months old?

Worst: Can the reference account or user have admin/superuser permissions that MUST NOT be assigned to a new employee’s account? …

Offboarding employees securely can be risky ⚠️

Similar situation to the issues when you have new employees. But how do you ensure you are not leaving the door open when an employee is leaving the company?

At the very least, you will need to make that any static passwords to shared accounts have been changed.

BUT — this has impacts too, and who knows how many other teammates would be affected by the password change.

And imagine having to change the password for every script, application/service, and resources whenever someone is offboarding. Imagine teammates changing 4–5 times a month?

Ooof, team productivity would go down the drain reeeaaaalll fast.

So, use RBAC (Role-Based Access Control). Engineers can be part of a group for provisioning engineer-only permissions. Admins can be part of a group for enabling admin-only permissions. Then when it’s time to leave, just remove the teammates from the necessary group(s).

You’d need to use manual human intervention for the simplest changes 😠

Say, you need to reset a password, unlock a locked account, or rotate some KMS keys. That would all have to be done manually.

With IAM, all of that can be done much quicker.

Alright! I am sold on using IAM! Got any Best Practices to adhere to? 🤯

This is by no means an exhaustive list of all best practices. Just some quick tidbits based off of my experience working with AWS for the past 3.5 years.

1) 🛡️NEVER Grant Full (*) Wildcard Access… EVER!

In an Enterprise IT setting, you would not want every user to have unlimited access to an account. Matter of fact, nobody should possess full access to anything (apart from the account owner).

Example: If an employee’s job is to monitor application logs, they should simply have READONLY access to CloudWatch logs, or the log bucket in S3. They should not be able to delete or restart other services/applications, or view billing history details.

2) 🛡️Implement Groups instead of Multiple Users

It is safer to use groups instead of multiple users when possible. Groups make access provisioning and administration extremely easy.

Example: If a new engineer joins your company, they can be added to an IAM group for the engineers. That new person will then automatically inherit all the permissions allocated to that particular IAM group.

Whereas the alternative, in creating a user for each type of varied access read_abdul, write_abdul, admin_abdul is considered arduous, and obsolete due to maintenance overhead.

3) 🛡️Implement RBAC on Existing Users for Creating New Users

When possible, go towards assigning a role to existing users instead of creating brand new users.

Example: Do not create an admin user, and then share the password between 6 different individuals. Instead, create an admin role, and then assign that role to whichever person or application needs it for a limited period of time.

4) 🛡️Audit Permissions Frequently

It is super easy to make mistakes, or perform malicious actions. At the very least, you should audit permissions on a regular cadence, to ensure that only the proper applications/individuals have the least-privileged access needed for their jobs.

You should also look into sending automated alerts to certain team(s) when a suspicious/accidental action occurs. Example: When an admin role is assigned to a new, or offshore employee.

5) 🛡️Implement Permissions Boundaries early!

If your IAM setup allows for it, try adding permission boundaries to your AWS setup.

Per the AWS Documentation:

AWS supports permissions boundaries for IAM entities (users or roles). A permissions boundary is an advanced feature for using a managed policy to set the maximum permissions that an identity-based policy can grant to an IAM entity. An entity’s permissions boundary allows it to perform only the actions that are allowed by both its identity-based policies and its permissions boundaries.

Basically, you are able to define the maximum permissions that can be assigned to anybody.

Example: A user will at most be able to view the logs from CloudWatch, and restart a Redshift. But if they attempt to do anything outside of those permissions (such as: get a role to create a new EKS Cluster, they will be denied permissions).