The subject of my talk was "IAM Secure, Are You?". I showed some nice "Did you knows". Like did you know that when AWS started in 2006, there was no IAM service and you needed to login with your amazon.com account. And that in 2010 IAM was only programmatically accessible (preview version). And that in 2011 console access was announced and you could login with IAM users into the console instead of your root account.
I explained the basics of IAM, but also things like:
- Identity-based policies vs. Resource-based policies
- Session policies
- Policy conditions
- Policy variables
- RBAC (role-based access control) vs. ABAC (attribute-based access control)
With ABAC you can do things like: if your role tag "job-title" does not equal to Product-Manager you are denied to the production S3 bucket.
I ended with a demo and some best practices. With the demo I explained the IAM decision tree. In the demo I created a IAM read-only identity-based policy and attached this policy to a demo role. I also created a SQS queue with a send-only resource-based policy for this role. I then sent a message onto the SQS queue as an admin user and assumed the demo role. With this demo role I tried polling the message. I asked the audience wether the polling (read) request would succeed while the role uses read permission, but the queue only has send permissions. The result was that the polling succeeded, which led to some confusion :-D, but I did this on purpose. You can check the image below to see how this works.
Thank Martijn & Sohan
And the rest
Today talking about AWS IAM
You might wonder who this is,
This is vishnu
Considered the protector of the universe
Stands for
Is one of AWS web services that helps you control access to AWS resources.
With IAM you control who can access what and when.
Developing a new cool feature
Hit the button to deploy to AWS
Realize you need IAM access
Also realize the IAM user guide has 381 pages of documentation
While doing this you will ofcourse fall asleep
Spent the next day on configuring very strict / granulair policies
Unsuccessful and then
Be like nevermind and add too broad permissions
But then you have regret when the audit comes
Enri Peters
30 years old
Work for Schuberg Philis
Gratefull
Linux and Cloud technologies
I have 2 daughters and a wife and we are living in Zutphen
Which is somewhere in the far east of the Netherlands
I would like to start with a few did you knows
When AWS launches 2006 with S3
Login with your amazon.com account
AWS announced SQS, their second service.
Then EC2.
In 2009 / 2010 still login with your root account.
But you was able to create a dedicated AWS account.
And able to login in the management console.
S3 -> only ACL’s
not recommended anymore
But then on the second of September in 2010
Programmatically add Users, groups and permission to your AWS Account
Console access
Ability to create users, groups of users and to attach policies to either one
Support 15 AWS services
Can login with IAM users
What you see here is An IAM user
Resource with creds and permissions associated
An IAM user can represent a person or an application
Access keys (MAX 2)
MAX 5000.
An IAM user group is a collection of IAM users.
With them you can take care of easier permission management.
Groups can contain many users.
An IAM role is similar to an IAM user
But, assumable by anyone who needs it.
No long-term credentials such as a password or access keys
Instead, when you assume a role, it provides you with temporary security credentials for your session
When IAM did not exist
Back in the days it all started with ACL’s
For S3
Decide what a principal can do
but very limited
Then later when IAM was introduced
It came with Policies for users groups and roles
Its called identity-based policies
JSON documents which specify the who can access what and when
AWS Managed
Auto update
Easy to implement
Example could be CloudTrailReadOnly
Customer managed
More control
No auto update
Includes versioning
Embedded to the IAM identity
Not reuseable
No versioning
What we look at
Is an example of a policy
In this case a permission boundary policy
Lets you set the maximum permissions that an identity-based policy can grant to an IAM entity.
Session policies are advanced policies that you pass as a parameter when you programmatically create a temporary session for a role or federated user.
Scope
Prevent coding mistakes
You can apply to your AWS organizations account
They set the maximum permissions
I work in a environment where we are only allow to use serverless and no EC2 etc.
Attached to a resource instead of a user, group or role…
Example on a queue you could specify who can access the qeueu.
IAM is who can access what
And this is about the when part
It’s called conditions
To run an instance
And for ease you want to specify resource *
Some context does not have the ec2:InstanceType available
For example the ec2:AvailabilityZone
You can use policy variables in the Resource element and in string comparisons in the Condition element.
but only in the resource portion of the ARN
Attribute based access control
If your tag job-title does not equal to Product-Manager you are denied to the prod bucket
We talked about Users Groups and Roles
And all kind of policies
Nowadays users and Groups are not preferred
So I would like to dive in a bit deeper on Roles
When you create a role you can choose a so called Trusted entity type.
For example
Another very common one is the AWS Account one
This type of role can be assumed via the console
Or programaticcaly
INSERT DEMO QUIZ HERE
Video with create policy + role (read only) and create queue with write only for that role arn
Lets take a few seconds to recap the demo
We had a role with SQS READ permissions
We had a Queue with a resource policy with Send permissions for that same role
As admin we have send a message on the queue
Then we switched roles to the MyDemoRole which has the SQS READ policy attached
I would like to ask you to raise your hand if you think polling with the assumed role will FAIL
Lock away your AWS account root user access keys
Use roles (temp creds)
Grant least privilege
Use customer managed policies instead of inline policies
Use roles for applications that run on Amazon EC2 instances
Use policy conditions for extra security
Monitor activity
Image a scenario where it did not work
To learn whether principals in accounts outside of your zone of trust (trusted organization or account) have access to assume your roles, see What is IAM Access Analyzer?.
