Thread by @tpschmidt_

📚 AWS 1x1

ɪᴅᴇɴᴛɪᴛʏ- & ᴀᴄᴄᴇꜱꜱ ᴍᴀɴᴀɢᴇᴍᴇɴᴛ (ɪᴀᴍ) 🔑

The concepts are crucial & being confident in them is a necessity.

From basics to advanced concepts 🧵↓

For seriously working with AWS, there's no way around IAM.
Skipping to understand its core principles will bite you again and again in the future️ 🔥

Take the time to do a deep dive, so you won't be frustrated later.

{ 1/35 }

Thread Overview 🧵

• IAMs Capabilities
• Key Terms
• Identity- & Resource-based Policies
• Securing your AWS Account
• Basics: Credentials & AWS CLI
• Dealing with "Access Denied"
• Least Privilege
• Permission Boundaries
• Tooling

{ 2/35 }

IAMs Capabilities 🗒

• managing users for your AWS account, with individual rights and/or temporary access
• enforcing password policies or MFA
• setting rights boundaries for AWS services & your apps
• identity federation
• ... and much more 🔐

Take your time!

{ 3/35 }

Key Terms 📚

• User: end-user, accessing the console or AWS API
• Group: a group of users, sharing the same privileges
• Policy: a defined list of permissions
• Role: a set of policies, that can be assumed by a user or AWS Service to gain those permissions

{ 4/35 }

At AWS IAM, everything evolves around 𝙋𝙤𝙡𝙞𝙘𝙞𝙚𝙨

By default, all actions for all services are denied, so you have to explicitly grant rights by adding a policy with your targeted actions and resources to your service role, user, or group!

{ 5/35 }

You can attach one or multiple policies to a role and each policy can contain one or multiple 𝙎𝙩𝙖𝙩𝙚𝙢𝙚𝙣𝙩𝙨

Statements contain the permissions you want to grant and are structured in a specific way, defined as a JSON.

{ 6/35 }

An important detail about policies: they come in two different types!

• 𝘐𝘥𝘦𝘯𝘵𝘪𝘵𝘺-𝘣𝘢𝘴𝘦𝘥 - attached to a user, group, or role.
• 𝘙𝘦𝘴𝘰𝘶𝘳𝘤𝘦-𝘣𝘢𝘴𝘦𝘥 - attached to a resource, e.g. S3 bucket, SQS queue, or KMS key.

We'll pick on this later.

{ 7/35 }

Let's have a look at what a 𝙎𝙩𝙖𝙩𝙚𝙢𝙚𝙣𝙩 must contain

• Effect - the indication if it's 𝘿𝙚𝙣𝙮 or 𝘼𝙡𝙡𝙤𝙬
• Action - a list of actions
• Resource - a list of resources for which the actions are granted

For resource-based policies, Resouce is optional.

{ 8/35 }

Resource-based Policies also need to define a 𝙋𝙧𝙞𝙣𝙘𝙞𝙥𝙖𝙡

It indicates for which account, (federated) user, or role user you'd like to allow/deny access.

There are more specifics for this type of policy like they aren't being affected by permission boundaries

{ 9/35 }

Your IAM knowledge foundation is laid!

Let's continue with securing your own AWS account!

It's not recommended to work with your root credentials. Those should only be used to enable MFA, create your first IAM user, and should then be locked away securely.

{ 10/35 }

Go to your security page & select 𝙈𝙖𝙣𝙖𝙜𝙚 𝙈𝙁𝘼 𝙙𝙚𝙫𝙞𝙘𝙚

You can use an authentication app of your choice.

Note: if there's already an Access Key, you can delete it as you shouldn't work with your root credentials in any way.

console.aws.amazon.com/iam/home?#secu…

{ 11/35 }

Afterward, you can create your first user by clicking on 𝙐𝙨𝙚𝙧𝙨 > 𝘼𝙙𝙙 𝙐𝙨𝙚𝙧

You can make use of AWS' predefined policies in the first place.

If you're working on a serious project, make sure to use groups to manage rights across different roles easily.

{ 12/35 }

After creating your user with enabled console access, you can now log out with your root user and log back in with your IAM user.

Note down your AWS' account identifier on the top right before logging out, because it's needed for the IAM user login.

{ 13/35 }

Credentials 🔑

For accessing AWS' API to maintain your infrastructure via code, we'll need credentials

Go back to your security credentials page and click 𝘾𝙧𝙚𝙖𝙩𝙚 𝙖𝙘𝙘𝙚𝙨𝙨 𝙠𝙚𝙮 to get your 𝘼𝙘𝙘𝙚𝙨𝙨 𝙆𝙚𝙮 𝙄𝘿 & 𝙎𝙚𝙘𝙧𝙚𝙩 𝘼𝙘𝙘𝙚𝙨𝙨 𝙆𝙚𝙮

{ 14/35 }

There's no way to display the Secret Access Key again, but you can create a new one at any time.

You can also have multiple keys for different purposes, which is also
recommended.

{ 15/35 }

AWS' Command Line Interface 🛠

Now that we've got our credentials, we can install AWS' CLI.
After installation, you can run 𝙖𝙬𝙨 𝙘𝙤𝙣𝙛𝙞𝙜𝙪𝙧𝙚 for doing our initial setup.

You'll be prompted for credentials some default settings.

aws.amazon.com/cli/

{ 16/35 }

When working with different accounts and/or roles and enabled MFA, it's recommendable to get some tooling support.

I love working with AWSume in this case.
It's easy to set up and really intuitive to work with.

awsu.me

{ 17/35 }

Access Denied 🙅‍♂️

Working with AWS, especially in the beginning, you'll face this message regularly.

Mostly, AWS' API will point you to missing permissions so you can easily extend your policy.

Sometimes it's not that easy and you'll need to get back to the docs.

{ 18/35 }

What you should not do: just extending your policy with all permissions for your target service by adding e.g. ᴀᴄᴛɪᴏɴ: ["dynamodb:*"] and ʀᴇꜱᴏᴜʀᴄᴇ: ["*"]

You won't learn anything by that and you're not respecting the rule of 𝙇𝙚𝙖𝙨𝙩 𝙋𝙧𝙞𝙫𝙞𝙡𝙚𝙜𝙚

{ 19/35 }

𝙇𝙚𝙖𝙨𝙩 𝙋𝙧𝙞𝙫𝙞𝙡𝙚𝙜𝙚 states that you should always just assign the permissions that are actually needed for the service to fulfill its goals.

💡 𝙀𝙭𝙖𝙢𝙥𝙡𝙚:
An app that runs on Lambda and now needs access to a recently created DynamoDB table.

{ 20/35 }

The easiest way would be to just create a policy that grants full permissions to DynamoDB and attach the role to your Lambdas role.

But that's not a good solution, because our app just needs to have read & write permissions for a single table.

{ 21/35 }

How can we improve?

1) Restricting actions
We don't manage tables, so we shouldn't grant 𝘿𝙚𝙡𝙚𝙩𝙚𝙏𝙖𝙗𝙡𝙚

What we need:
• 𝙌𝙪𝙚𝙧𝙮
• 𝙂𝙚𝙩𝙄𝙩𝙚𝙢
• 𝙋𝙪𝙩𝙄𝙩𝙚𝙢
• 𝙐𝙥𝙙𝙖𝙩𝙚𝙄𝙩𝙚𝙢

You'll find all permissions in the docs!

docs.aws.amazon.com/service-author…

{ 22/35 }

2) Restricting resources
As we're only working with a specific table, we can really fix the permissions to be only valid for this single table by listing the ARN.

arn:aws:dynamodb:𝙍𝙀𝙂𝙄𝙊𝙉:𝘼𝘾𝘾𝙊𝙐𝙉𝙏_𝙄𝘿:table/𝙏𝘼𝘽𝙇𝙀_𝙉𝘼𝙈𝙀

Sounds complicated?

{ 23/35 }

For enforcing least privilege, you'll need to fiddle around with ARNs a lot.

Maybe this sounds tedious, but if you start working with 𝙄𝙣𝙛𝙧𝙖𝙨𝙩𝙧𝙪𝙘𝙩𝙪𝙧𝙚 𝙖𝙨 𝘾𝙤𝙙𝙚 (IaC) tools like Terraform, CloudFormation, or AWS CDK, this is really easy & comfortable!

{ 24/35 }

Regardless of what you're using, all tools will create output variables for your created resources that include all the references you need, like for example the ARN.

You can create other resources that depend on those.

{ 25/35 }

That's not the end of IAMs capabilities.

AWS' 𝙋𝙚𝙧𝙢𝙞𝙨𝙨𝙞𝙤𝙣 𝘽𝙤𝙪𝙣𝙙𝙖𝙧𝙞𝙚𝙨 help you to restricted effective permissions for a user or role.

They also contain policies that describe actions and resources, but they are acting as an outer boundary.

{ 26/35 }

What it means: the actually attached permissions can never exceed the boundary!

So if your boundaries only list 𝙙𝙮𝙣𝙖𝙢𝙤𝙙𝙗:𝙌𝙪𝙚𝙧𝙮 for all resources, a role with 𝙙𝙮𝙣𝙖𝙢𝙤𝙙𝙗:* can't update or delete items, but only query!

What is it good for?

{ 27/35 }

Boundaries can be defined in one place but re-used across all of your account's roles and users.

By that, you could for example strictly separate an app's permissions to only access resources with a given name prefix, but having multiple apps within your account.

{ 28/35 }

You can also use your boundary policy not only as a boundary but as actual permissions, for example for your CI/CD service/tool like CodeBuild.

By that, you'll automatically grant all necessary rights, but still with respect to the boundary.

{ 29/35 }

Important details about boundaries policies:

• if used as a boundary, they are not actually granting permissions, but only restricting them!
• there's 𝙣𝙤 𝙚𝙛𝙛𝙚𝙘𝙩 on resource-based policies, e.g. for your S3 bucket!

{ 30/35 }

There are a lot more features that IAM offers and this was just an introduction with some general recommendations, but it will be enough to get you started.

For following security best practices, there's also a lot of tooling you can fall back to!

{ 31/35 }

AWS offers its own service 𝙏𝙧𝙪𝙨𝙩𝙚𝙙 𝘼𝙫𝙞𝙨𝙤𝙧

It reviews your permissions for unnecessary rights or best practice violations and checks that you've enabled AWS security features for your services and resources.

{ 32/35 }

Another great feature by AWS: its own 𝙋𝙤𝙡𝙞𝙘𝙮 𝙎𝙞𝙢𝙪𝙡𝙖𝙩𝙤𝙧

It greatly helps to build, validate and troubleshoot your policies. It supports identity-based, resource-based and even Organizations service control policies.

policysim.aws.amazon.com

{ 33/35 }

There are a lot more third party services guiding you with security recommendations & well-architected tips like @thedashbird

𝘿𝙞𝙨𝙘𝙡𝙖𝙞𝙢𝙚𝙧 - I'm Dashbirds Developer Advocate 🥑 😊 so this is biased, but we're happy to listen to your feedback for improvements!

{ 34/35 }

Some final words 💫

Completely mastering IAM is more of a holy grail, as it's a complex topic and there will always be days where you're stuck on some permissions issue, regardless of your experience!

Don't be frustrated.
It gets easier with time.

{ 35/35 }

I hope you've enjoyed reading this thread and learned something new.

I'd be happy if you like or retweet the initial post! 🙌

If you have questions or need guidance on your cloud journey, follow me for regular content or send me a message 📨

Thanks for reading! 💛