AWS IAM Deep Dive. Chapter 4: Policy Evaluation Logic, Permission Boundaries, Identity Federation

Karen Tovmasyan
Sep 9 · 7 min read

Chapters:

Welcome back to the final chapter on IAM! Let’s wait no longer.


Policy Evaluation Logic and Permission Boundaries

If you got this far, you already know that we have several entities which have Policies.

You can have a user which has policies allowing him to make these calls:

s3:ListBucket
s3:GetObject

This user is a member of a group which has additional policies attached:

s3:PutObject
s3:DeleteObject

Now question: which call can this particular user make? The answer is simple — all of them.

The nice thing here is that IAM appends the policies of the specific entity. That doesn’t work with IAM Role — once you assume it, you will only have the policies which are attached to it.

The same model applies to Resource-Based Policies (the ones which are attached to the resource, not to an entity)

Permission schema

How do we limit access to the users? Please welcome Permission Boundaries and Service Control Policies.


AWS documentation on IAM policy evaluation logic provides a comprehensive picture of policy evaluation.

Pretty simple, right? ;)

Denny Devito tends to disagree

We know that explicit Deny overrides Allow. This feature here is to ease the limits to certain set of operations. Let’s say you want to allow all operations except for Delete.

{
"Version: "2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Action": "s3:*",
"Resource": "*"
},
{
"Effect": "Deny",
"Action": "s3:Delete*",
"Resource": "*"
}
]
}

But let’s say we have 2 groups of users: Developers and Admins. Admins are allowed to make any calls, but Developers are not allowed to delete things.

We could create different groups for them or make them assume two different roles… My Occam’s razor is triggered! Instead, we could use Permission Boundaries in the single Role and let both groups assume it.

{
"Version: "2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Action": "s3:*",
"Resource": "*"
},
{
"Effect": "Deny",
"Action": "s3:Delete*",
"Resource": "*",
"Condition":
{
"StringEqual":
{
"aws:username": "arn:aws::*:user/dev/*"
}
}
}
]
}

Let’s look at the different example which better falls in the boundary schema. We have two roles: Sales and Marketing. We also have two S3 buckets, Sales and Marketing. Our use case: Sales can get objects from both buckets, while Marketing can get objects only from Marketing bucket.

We could add 2 statements, one using the Condition element like above, or we could use Boundary for that.

Policy:

{
"Version: "2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Action": "s3:GetObject",
"Resource":
[
"arn:aws::s3:marketingbucket/*",
"arn:aws::s3:salesbucket/*"
]
}
]
}

Boundary:

{
"Version: "2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Action": "s3:GetObject",
"Resource": "arn:aws::s3:marketingbucket/*",
"Condition":
{
"StringEquals":
{
"aws:username": "arn:aws::*:user/marketing/*"
}
}
}
]
}

Not that both — Policy and Boundary — have the same “Allow” effect. However, due to Boundary’s nature, only overlapping API calls are allowed.

All in all, individual (User, Group or Role wide) permission boundaries have quite limited functionality, but the idea behind them releases a far more powerful beast, called…

Service Control Policies

Now, this is where stuff gets serious. If permission boundaries operate on an entity/resource level, SCPs operate on the account level.

Yes, ACCOUNT LEVEL.

SCP-173

So much enterprise here, right? Before we dive into this, we need to be aware that SCPs work in conjunction with AWS Organizations. Few words on that.

AWS Organizations provide a way to separate your workloads the same way as your organization or environment. We can have accounts for Dev, Test, and Production. We can have accounts for Project A, Project B, and Project C. We can even have accounts for Project A Dev, Project A Test, Project A Prod, Project B Dev, and so on. While the use of “different account per environment per project” is mostly for huge AWS workloads, separation per environment is quite common. In the end — all bills are consolidated and are being paid by the master (payer) account. Let’s get back to SCPs.


So we know that SCPs permit API calls on the account level. There is a ton of use cases for it, but I’ll go with the most common ones.

Scenario A: Strict policy/procedure driven development

We have an enterprise ITIL powered company. This company has a strict list of standards, allowing development using only specific AWS services. Our task is to limit access to API calls only for:

  1. EC2
  2. S3
  3. DynamoDB
  4. RDS
  5. CloudWatch
  6. Lambda
  7. SQS

We create a Service Control Policy which looks like this:

{
"Version: "2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Action":
[
"s3:*",
"ec2:*",
"rds:*",
"dynamodb:*",
"cloudwatch:*",
"lambda:*",
"sqs:*"
],
"Resource": "*"
}
]
}

Done! Again, note that we use no Deny here, but if we attach this SCP to one of the managed accounts, the door is locked: even Admin and root user will have no power outside of SCP.

Scenario B: Restrict access to the root user

Some developer has gone wild and uses the root user to manage AWS. The security team is bumping their heads to find out who he is. We are tasked to lock the root user, so nobody can authenticate with it ever again.

{
"Version": "2012-10-17",
"Statement":
[
{
"Sid": "RestrictRoot",
"Effect": "Deny",
"Action": "*",
"Resource": "*",
"Condition":
{
"StringLike":
{
"aws:PrincipalArn":
[
"arn:aws:iam::*:root"
]
}
}
}
]
}

Done! We now disallow any API call for the root user. All we need to do is wait until our sneaky developer shows up complaining that he lost access to AWS.

Achtung! SCP is extremely powerful, so think twice before locking yourselves. When it comes to limiting root access you must be 100% sure its credentials are not used in your applications!

Again, there is a way more information about the usage of permission boundaries and SCPs, but you will find your way when you get to it. Just keep in mind these rules:

  • Deny overrides Allow
  • Permission Boundary overlaps Policies
  • SCP overlaps everything!
  • SCP can only be used on managed accounts

Identity Federation

We got to the final part of this blog series. Last but not least — identity federation.

You remember that the maximum limit for IAM users is 5000. That is fine if we access AWS only to work with EC2 and so on, but there is an issue if we use external identities (Google/Facebook/etc) hooked to Cognito and access data from services like DynamoDB.

In order to provide access to AWS’ managed services, we need to use IAM. If we want to support this functionality for external identities we need a combination of Identity Federation and IAM Roles.

When it comes to having more than 5000 employees we simply use SAML federation: that is done by configuring the Trust Relationship for the Role and SAML federation on Active Directory (in most of the cases when you work for a company with more than 5000 employees you likely have Active Directory).

Now here is another case — you have a mobile app which stores and reads the data from DynamoDB. Let’s say it’s a mobile game with leaderboard on Dynamo. For these cases, you need to use Web Identity Federation.

Whenever user will launch a mobile app and hit “Login”, his smartphone will authenticate using Web Identity Federation and assume IAM Role which allows access to specific resources and services.

Now here’s the main trick: we want to limit access for specific items for specific users. For that, we need to use conditions.

AWS has made a nice and explanatory document on how to configure it. Long story short: we create the partition key which contains the userId of the user, who registers/signs up with Web Identity Federation, then we allow access to a specific item, where userId in the attributes matches the one which is in the identity federation field when this identity assumes the Role. Sounds harsh on paper, but not so troublesome when you start developing.

To ease the development of your applications you can test how federation works using the playground.


That’s all folks!

Thank you for reading and I hope you’ve learned a lot and now know more about AWS IAM!

If you have any questions, concerns or think I could add more, feel free to leave a response!

xoxo

Karen Tovmasyan

Written by

aka Thomas Storm aka gsmg-thedarkness. Cloud Engineer specialized in AWS.

Welcome to a place where words matter. On Medium, smart voices and original ideas take center stage - with no ads in sight. Watch
Follow all the topics you care about, and we’ll deliver the best stories for you to your homepage and inbox. Explore
Get unlimited access to the best stories on Medium — and support writers while you’re at it. Just $5/month. Upgrade