AWS IAM policies in plain english presentation given by Bogdan Naydenov on AWSBulgaria meetup user group on May 16 2017

1. AWS IAM Policies
in plain English
Bogdan Naydenov
Part of AWS All Stars Certified Elite,
16 May 2017
#AWSBulgaria User Group

2. Who am I
Bogdan Naydenov
AWS All 5 AWS Certificates holder currently Architect at Progress Software - Platform DevOps team
Mostly Operational background with more than 19 years of IT experience
https://www.linkedin.com/in/bnaydenov @BobbyNaydenov

3. Overview
In the beginning... there is the natural, general flow of working with IAM policies
● develop app feature
● deploy to AWS
● realize you need IAM
● get overwhelmed by docs
● begin copy and pasting example policies to fit your app
● bashing your head and fingers against the keyboard until it works

4. Simple Policy
{
"Version": "2012-10-17",
"Id": "some-unique-id",
"Statement": {
"Sid": "1",
"Effect": "Allow",
"Principal": {"AWS": "arn:aws:iam::111222333444:user/naydenov"},
"Action": [
"s3:PutObject",
"s3:Get*"
],
"Resource": "arn:aws:s3:::s3-bucket_name/*",
"Condition": {
"DateGreaterThan": {
"aws:CurrentTime": "2017-05-17T00:00:00Z"
}
}
}
}

5. What is an AWS IAM Policy?
“A set of rules that, under the correct conditions,
define what actions the policy principal or holder
can take to specified AWS resources.”

6. How about this in plain English?
Who can do what to which resources. When do we care?

7. The "Who"?
"Who" is trying to do stuff? This can be a User, Groups of users and "roles."
The first two are self-explanatory. The last one “roles” is just allows us to let other things, like EC2
servers, become the "Who”.
(We can also allow for federated users to be the "who" but we won't dive into that.)
"Principal": {"AWS": "arn:aws:iam::111222333444:user/naydenov"}

8. The "Who" aka Principal?
For IAM Users and Roles, we just grab its ARN
(found in the IAM console or returned in the CLI)
and follow the format of:
"Principal": {"AWS": "<ARN OF YOUR IAM USER OR ROLE BUT NOT GROUPS>"}
"Principal": { "AWS" : "arn:aws:iam::111222333444:user/naydenov" }
"Principal": { "Service": "ec2.amazonaws.com" }

9. NOW. HUGE Gotcha?
If we're making and attaching policies to IAM users, groups and roles,
the principal (or Who) isn't needed.
That's because when you attach a policy to an IAM user for example,
the policy assumes that the user who we've attached the policy to is the principal.

10. The "Who" Users vs The "Who"Resources?
What's the difference between attaching a policy to an IAM user vs a resource like an S3 bucket?
If the policy is attached to the user, group or role it's like a permission slip.
If it's attached to the resource, it's like a VIP list.

11. AWS Roles and Principals?
Even though IAM users and groups imply a "who" on their permission policy,
IAM roles do so only after we've specified the who via a "Trust Policy."
Therefore, when creating a role we have to pass it these two separate policy documents:
1) The "Trust Policy" is a policy that does nothing more than state "who" can assume this role. Yes,
they look exactly like normal policies.
2) The Permissions Policy is just what we've shown so far. "What" actions can the owner of this role
take to "which" resources?

12. AWS Roles and Principals?
IF we're creating IAM roles in the console, guess what?
We don't really worry about the first policy.
Instead, when creating a role we select a service that will serve as the who:
This sets up that first "trust policy" document for us.
Then we attach a policy to the role like we would a user or group.

13. AWS Roles and Principals?
For the CLI (or CloudFormation, Terraform) however, we have to do both steps.
Let's say we want to create a role for AWS CodePipeline.
To do so we first need to create the role with the following "trust policy":
{
"Version":"2012-10-17",
"Statement": {
"Effect":"Allow",
"Principal": {
"Service": "codepipeline.amazonaws.com"
},
"Action":"sts:AssumeRole"
}
}

14. AWS Roles and Principals?
aws iam create-role --role-name CodePipelineExampleRole
--assume-role-policy-document
'{"Version":"2012-10-17","Statement":{"Effect":"Allow","Principal":{"Service":"codepipeline.amazonaws.com"
},"Action":"sts:AssumeRole"}}'
aws iam put-role-policy --role-name CodePipelineExampleRole
--policy-name CodePipelineExamplePolicy
--policy-document file://some-policy.json

15. The "What"?
"What" actions can the "Who" take?
Run EC2 instances?
Put objects to S3?
Put logs to cloud watch?
"Action": [
"s3:PutObject",
"s3:Get*"
]

16. The "What"?
The format of action is a string or array of actions that take the format of:
<service>:<action in service>
If unsure of what the needs are and have a safe AWS development environment, keep the actions general (via the
wildcard * operator) and then cherry pick the ones you need when the service is fully built.
"s3:Get*"
List of all actions by services

17. The "Which"?
"What" actions can the "Who" take on "Which" resources?
So the "Who" can put and get objects to S3?
But to which S3 buckets?
All of them?
Only ones in us-east-1?
"Resource": "arn:aws:s3:::s3-bucket_name/*"

18. The "Which"?
Quick aside - the anatomy of an ARN, Amazon Resource Name, is as follows
arn:aws:[service]:[region]:[account]:resourceType/resourcePath
{
"Version": "2012-10-17",
"Statement": [
{
"Action": [
"s3:GetObject",
"s3:PutObject"
],
"Effect": "Allow",
"Resource": "arn:aws:s3:::s3-bucket/${aws:username}/*"
}
]
}

19. The "Which"?
The ${aws:username}, and all policy variables, are data that are sent up with requests. There's a variety
of them like aws:CurrentTime or aws:SourceIp. A full list is here:
Policy Variables List
A note on resource in context of S3. IAM policies can imply the "who" or the prinicpal when we attach a
policy to them. One might think that a bucket would imply the resource be itself. However, it doesn't.
When attaching a policy to an S3 bucket (aka bucket policy), we must still specify the resource, which is
always the S3 bucket optionally followed by nested folders/objects within.

20. The "When"?
"When do we care?
If the IP matches a certain range of IPs?
If the date-time is before a particular day?
If the AWS user's username includes the given string?
"Condition": {
"DateGreaterThan": {
"aws:CurrentTime": "2017-05-17T00:00:00Z"
}
}

21. The "When"?
"When" can our Prinicpal take actions on a resource? When conditions permit.
In plain english:
"Condition": {
"<What's the comparison we're making?>": {
"<Value being passed in the request>": "<Value to compare against>"
}
}

22. The When?
"Resource": "arn:aws:s3:::s3-bucket/*",
"Condition": {
"IpAddress": {
"aws:SourceIp": "123.123.123.123/32"
},
"DateGreaterThan": {
"aws:CurrentTime": "2017-05-15T00:00:00Z"
}
}

23. The When?
Condition Operators
What comparison are we making? A string comparison? An IP comparison? A username comparison?
Each of these have a special operator.
The condition operators in previous example are IpAddress and DateGreaterThan.
A list of condition operators to be used can be found here.

24. The When?
Condition Keys
These are the AWS ready values about the current request trying to pass the policy. When a request
comes through, AWS makes a variety of these "keys" available for use within our policies.
We saw two above aws:SourceIp and aws:CurrentTime - and as mentioned in the Resource section,
these are also known as Policy Variables
Link to AWS Global Condition Keys

25. The When?
Condition Values
This is simply the value that we're looking to compare against. So in this example:
The only real note here is that within these values we can also use Policy Variables, the wildcard
character (*) to denote any string and the question mark (?) to denote any one character.
{
"Condition": {
"ArnEquals": {
"ec2:Vpc": "arn:aws:ec2:us-east-?::vpc/*"
},
"StringLike": {
"ec2:ResourceTag/name": "*-${aws:username}"
}
}
}

26. The When?
Or this one
{
"Version":"2012-10-17",
"Statement":[
{
"Effect": "Allow",
"Action": "ec2:*",
"Resource": "*",
"Condition": {
"StringEquals": {
"ec2:Region": "us-east-1"
},
"ArnEquals": {
"ec2:Vpc": "ARN of VPC"
}
}
}
]
}

27. `Not` Versions of Policies
Resource, Action and Principal have a reverse:
NotResource
NotAction
NotPrincipal
As you might suspect, they just specify what it does NOT apply to
!!! just stick with positives if possible.

28. Explained - Simple Policy
{
"Version": "2012-10-17",
"Id": "some-unique-id",
"Statement": {
"Sid": "1",
"Effect": "Allow",
Who "Principal": {"AWS": "arn:aws:iam::111222333444:user/naydenov"},
What "Action": [
"s3:PutObject",
"s3:Get*"
],
Which "Resource": "arn:aws:s3:::s3-bucket_name/*",
When "Condition": {
"DateGreaterThan": {
"aws:CurrentTime": "2017-05-17T00:00:00Z"
}
}
}
}

29. ReCap
An IAM policy:
A set of rules that, under the correct conditions, define what actions the policy principal or
holder can take to specified AWS resources.
Or more simply put:
Who can do what to which resources. When do we care?

30. Using Policies
● create the policy
● attach it to a user, group, role or resource.
For IAM Users, Groups and Roles, you'll create your policy and then simply attach it to one of the three. The
CLI experience obviously requires some different steps, but the concept is still same.
For Resources like S3 Buckets, you'll directly attach policies generally in that service's API or console
interface.

31. Final Thoughts
“begin with the end in mind”
Literally ask yourself and team:
Who can do what to which resources. When do we care?

32. List of all actions by services
Policy Variables List
A list of condition operators to be used can be found here
Link to AWS Global Condition Keys
Resources used