AWS IAM Policies
in plain English
Bogdan Naydenov
Part of AWS All Stars Certified Elite,
16 May 2017
#AWSBulgaria User Group
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
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
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"
}
}
}
}
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.”
How about this in plain English?
Who can do what to which resources. When do we care?
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"}
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" }
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.
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.
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?
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.
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"
}
}
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
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*"
]
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
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/*"
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}/*"
}
]
}
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.
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"
}
}
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>"
}
}
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"
}
}
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.
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
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}"
}
}
}
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"
}
}
}
]
}
`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.
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"
}
}
}
}
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?
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.
Final Thoughts
“begin with the end in mind”
Literally ask yourself and team:
Who can do what to which resources. When do we care?
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

More Related Content

PPTX
IAM Deep Dive - Custom IAM Policies with Conditions
PDF
AWS Control Tower를 통한 클라우드 보안 및 거버넌스 설계 - 김학민 :: AWS 클라우드 마이그레이션 온라인
PDF
워크로드 특성에 따른 안전하고 효율적인 Data Lake 운영 방안
PDF
AWS IAM Tutorial | Identity And Access Management (IAM) | AWS Training Videos...
PDF
Amazon EMR과 SageMaker를 이용하여 데이터를 준비하고 머신러닝 모델 개발 하기
PDF
AWS Summit Seoul 2023 | 데이터, 분석 및 AI를 통합하는 단 하나의 레이크하우스, Databricks on AWS 로 ...
PDF
OWASP Top 10 Web Application Vulnerabilities
PPTX
AWS Training For Beginners | AWS Certified Solutions Architect Tutorial | AWS...
IAM Deep Dive - Custom IAM Policies with Conditions
AWS Control Tower를 통한 클라우드 보안 및 거버넌스 설계 - 김학민 :: AWS 클라우드 마이그레이션 온라인
워크로드 특성에 따른 안전하고 효율적인 Data Lake 운영 방안
AWS IAM Tutorial | Identity And Access Management (IAM) | AWS Training Videos...
Amazon EMR과 SageMaker를 이용하여 데이터를 준비하고 머신러닝 모델 개발 하기
AWS Summit Seoul 2023 | 데이터, 분석 및 AI를 통합하는 단 하나의 레이크하우스, Databricks on AWS 로 ...
OWASP Top 10 Web Application Vulnerabilities
AWS Training For Beginners | AWS Certified Solutions Architect Tutorial | AWS...

What's hot (20)

PDF
[Retail & CPG Day 2019] AWS기반의 Data 분석 플랫폼 구축, 고객사례 (GS SHOP) -김형일, AWS 솔루션즈 ...
PDF
Aws Elastic Block Storage
PDF
AWS Summit Seoul 2023 | AWS 마이그레이션을 통한 엔카닷컴의 DT 전략
PDF
AWS Backup을 이용한 데이터베이스의 백업 자동화와 편리한 복구방법
PDF
AWS EC2
PDF
PDF
[보험사를 위한 AWS Data Analytics Day] 4_신한금융그룹의 데이터 댐_Do...
PPTX
Azure Governance
PDF
Web Application Security and Awareness
PDF
Azure Security Overview
PPTX
Cloud Computing Security
PDF
Multi-tenancy in the cloud
PPTX
Data Encryption - Azure Storage Service
DOCX
AWS | VPC Peering
PDF
[보험사를 위한 AWS Data Analytics Day] 1_데이터 경영으로 보험 산업의 ...
PPTX
An Introduction to Confluent Cloud: Apache Kafka as a Service
PDF
AWS Summit Seoul 2023 | 12가지 디자인 패턴으로 알아보는 클라우드 네이티브 마이크로서비스 아키텍처
PDF
AWS Summit Seoul 2023 | KB의 통합 음성 AI서비스의 현재와 미래 - 하이브리드 클라우드 기반의 똑똑한 AI상담원 콜봇
PDF
AWS Systems manager 2019
PPTX
Amazon_SNS.pptx
[Retail & CPG Day 2019] AWS기반의 Data 분석 플랫폼 구축, 고객사례 (GS SHOP) -김형일, AWS 솔루션즈 ...
Aws Elastic Block Storage
AWS Summit Seoul 2023 | AWS 마이그레이션을 통한 엔카닷컴의 DT 전략
AWS Backup을 이용한 데이터베이스의 백업 자동화와 편리한 복구방법
AWS EC2
[보험사를 위한 AWS Data Analytics Day] 4_신한금융그룹의 데이터 댐_Do...
Azure Governance
Web Application Security and Awareness
Azure Security Overview
Cloud Computing Security
Multi-tenancy in the cloud
Data Encryption - Azure Storage Service
AWS | VPC Peering
[보험사를 위한 AWS Data Analytics Day] 1_데이터 경영으로 보험 산업의 ...
An Introduction to Confluent Cloud: Apache Kafka as a Service
AWS Summit Seoul 2023 | 12가지 디자인 패턴으로 알아보는 클라우드 네이티브 마이크로서비스 아키텍처
AWS Summit Seoul 2023 | KB의 통합 음성 AI서비스의 현재와 미래 - 하이브리드 클라우드 기반의 똑똑한 AI상담원 콜봇
AWS Systems manager 2019
Amazon_SNS.pptx
Ad

Similar to AWS IAM policies in plain english (20)

PPTX
Windsor AWS UG Deep dive IAM 2 - no json101
PPTX
Identity and access management
PPTX
AWS deployment and management Services
PPTX
AWS core services
PPTX
Amazon services iam
PPTX
Null Bangalore | Pentesters Approach to AWS IAM
PPTX
Aws education interest to enhance career IAM.pptx
ODP
Introduction to AWS IAM
PDF
Peter Sankauskas Access Denied: Understanding & Debugging AWS IAM
PDF
Amazon Web Services Security
PPTX
AWS Twin Cities Meetup - IAM Deep Dive
PDF
AWS Community Day - Joel Schuweiler - Become an IAM Guru
PPTX
cLASE 3 DE 40 Es por esoque debes teber 40 c.pptx
PPTX
AWS Windsor User Group - June 7th 2018 - Amazon Web Services IAM
PDF
AWS Technical Day Riyadh Nov 2019 - The art of mastering data protection on aws
PPTX
AWS IAM and security
PDF
AWS IAM -- Notes of 20130403 Doc Version
PPTX
AWS Community Day - Joel Schuweiler - Become an IAM guru
PDF
Aws security Fundamentals
PDF
Avoiding Friendly Fire in AWS
Windsor AWS UG Deep dive IAM 2 - no json101
Identity and access management
AWS deployment and management Services
AWS core services
Amazon services iam
Null Bangalore | Pentesters Approach to AWS IAM
Aws education interest to enhance career IAM.pptx
Introduction to AWS IAM
Peter Sankauskas Access Denied: Understanding & Debugging AWS IAM
Amazon Web Services Security
AWS Twin Cities Meetup - IAM Deep Dive
AWS Community Day - Joel Schuweiler - Become an IAM Guru
cLASE 3 DE 40 Es por esoque debes teber 40 c.pptx
AWS Windsor User Group - June 7th 2018 - Amazon Web Services IAM
AWS Technical Day Riyadh Nov 2019 - The art of mastering data protection on aws
AWS IAM and security
AWS IAM -- Notes of 20130403 Doc Version
AWS Community Day - Joel Schuweiler - Become an IAM guru
Aws security Fundamentals
Avoiding Friendly Fire in AWS
Ad

Recently uploaded (20)

PPTX
Fundamentals of safety and accident prevention -final (1).pptx
PDF
August -2025_Top10 Read_Articles_ijait.pdf
PPTX
AUTOMOTIVE ENGINE MANAGEMENT (MECHATRONICS).pptx
PDF
BIO-INSPIRED ARCHITECTURE FOR PARSIMONIOUS CONVERSATIONAL INTELLIGENCE : THE ...
PPTX
CyberSecurity Mobile and Wireless Devices
PDF
Soil Improvement Techniques Note - Rabbi
PDF
ChapteR012372321DFGDSFGDFGDFSGDFGDFGDFGSDFGDFGFD
PDF
BIO-INSPIRED HORMONAL MODULATION AND ADAPTIVE ORCHESTRATION IN S-AI-GPT
PDF
22EC502-MICROCONTROLLER AND INTERFACING-8051 MICROCONTROLLER.pdf
PDF
A SYSTEMATIC REVIEW OF APPLICATIONS IN FRAUD DETECTION
PDF
Influence of Green Infrastructure on Residents’ Endorsement of the New Ecolog...
PDF
distributed database system" (DDBS) is often used to refer to both the distri...
PPTX
Management Information system : MIS-e-Business Systems.pptx
PPTX
introduction to high performance computing
PPTX
communication and presentation skills 01
PDF
Level 2 – IBM Data and AI Fundamentals (1)_v1.1.PDF
PPTX
Module 8- Technological and Communication Skills.pptx
PDF
Visual Aids for Exploratory Data Analysis.pdf
PDF
Accra-Kumasi Expressway - Prefeasibility Report Volume 1 of 7.11.2018.pdf
PPTX
Chemical Technological Processes, Feasibility Study and Chemical Process Indu...
Fundamentals of safety and accident prevention -final (1).pptx
August -2025_Top10 Read_Articles_ijait.pdf
AUTOMOTIVE ENGINE MANAGEMENT (MECHATRONICS).pptx
BIO-INSPIRED ARCHITECTURE FOR PARSIMONIOUS CONVERSATIONAL INTELLIGENCE : THE ...
CyberSecurity Mobile and Wireless Devices
Soil Improvement Techniques Note - Rabbi
ChapteR012372321DFGDSFGDFGDFSGDFGDFGDFGSDFGDFGFD
BIO-INSPIRED HORMONAL MODULATION AND ADAPTIVE ORCHESTRATION IN S-AI-GPT
22EC502-MICROCONTROLLER AND INTERFACING-8051 MICROCONTROLLER.pdf
A SYSTEMATIC REVIEW OF APPLICATIONS IN FRAUD DETECTION
Influence of Green Infrastructure on Residents’ Endorsement of the New Ecolog...
distributed database system" (DDBS) is often used to refer to both the distri...
Management Information system : MIS-e-Business Systems.pptx
introduction to high performance computing
communication and presentation skills 01
Level 2 – IBM Data and AI Fundamentals (1)_v1.1.PDF
Module 8- Technological and Communication Skills.pptx
Visual Aids for Exploratory Data Analysis.pdf
Accra-Kumasi Expressway - Prefeasibility Report Volume 1 of 7.11.2018.pdf
Chemical Technological Processes, Feasibility Study and Chemical Process Indu...

AWS IAM policies in plain english

  • 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