granted.dev - A CLI application which provides the world’s best developer UX for finding and accessing cloud roles to multiple cloud accounts, fast!

🧠 USE CASE

AWS IAM Permissions and Access Management Simplified

IAM is the backbone of security in modern IT environments. It determines who or what can access specific resources and perform specific actions.

Key IAM components include:

Principals: Users, groups, or services requesting access.
Policies: JSON based documents that define permissions.
Roles: Temporary identities assumed by trusted principals.
Permission Boundaries: Limits on maximum permissions a principal can have.

Understand that IAM policies are evaluated based on a combination of allow and deny statements. Knowing this evaluation order is key to troubleshooting access issues.

Policy evaluation logic:

Credit: AWS Perspective Guide

Explicit Deny – If any policy denies an action, it is denied.
Explicit Allow – If an explicit allow exists and no deny, the action is permitted.
Implicit Deny – If no policy explicitly allows the action, it is denied by default.

Key Concepts and Terminology

1. Identity Based Policies

These are attached directly to an identity (user, group, or role) and specify which actions are allowed or denied. They are critical in enforcing the principle of least privilege.

Example: Granting an EC2 instance access to an S3 bucket, but denying deletions.

{

"Version": "2012-10-17",

"Statement": [

{

"Effect": "Allow",

"Action": "s3:GetObject",

"Resource": "arn:aws:s3:::secure-bucket/"

{

"Effect": "Deny",

"Action": "s3:DeleteObject",

"Resource": "arn:aws:s3:::secure-bucket/"

}

]

}

2. Resource Based Policies

Attached directly to a resource, these policies allow resource owners to define who can access them. They are especially useful for cross account access scenarios.

Example: Allowing another AWS account read only access to an S3 bucket.

{

"Version": "2012-10-17",

"Statement": [

{

"Effect": "Allow",

"Principal": { "AWS": "arn:aws:iam::123456789012:root" },

"Action": "s3:GetObject",

"Resource": "arn:aws:s3:::secure-bucket/*"

}

]

}

3. Roles and Trust Policies

Roles are assumed by trusted entities and are essential in dynamic environments where temporary credentials are needed. Trust policies define who can assume a role, ensuring that only authorized principals can gain the associated permissions.

Example: EC2 assumes a role that allows DynamoDB access.

{

"Version": "2012-10-17",

"Statement": [

{

"Effect": "Allow",

"Principal": { "Service": "ec2.amazonaws.com" },

"Action": "sts:AssumeRole"

}

]

}

4. Permission Boundaries

These act as an upper limit for permissions. Even if a principal’s identity based policy allows broad actions, a permission boundary can restrict them to a safer subset.

Things To Take Seriously

Principle of Least Privilege (Grant only the permissions required)
Use Managed Policies (Reduce complexity with reusable IAM policies)
Use IAM Policy Simulator (Test policies before applying them)

Testing a policy’s effect using AWS CLI:

aws iam simulate-custom-policy --policy-input-list file://policy.json --action-names "s3:GetObject"

AWS services that work with IAM

As infrastructures grow more complex, the importance of robust IAM permission management cannot be overstated. Keep it tight.

25 Blogs to Learn 25 DevOps Concepts:
1) Terraform Project Structure: techopsexamples.com/p/guide-to-a-w…
2) Terraform State: techopsexamples.com/p/steps-to-pre…
3) Terraform Graphs: techopsexamples.com/p/terraform-gr…
4) Terraform Dynamic Blocks: techopsexamples.com/p/the-problem-…
5) Crossplane with ArgoCD:… x.com/i/web/status/1…
— Govardhana Miriyala Kannaiah (@govardhana_mk)
3:00 PM • Mar 18, 2025

Looking to promote your company, product, service, or event to 40,000+ Cloud Native Professionals? Let's work together.