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.
โข 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.
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.
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:
โข ๐๐ช๐๐ง๐ฎ
โข ๐๐๐ฉ๐๐ฉ๐๐ข
โข ๐๐ช๐ฉ๐๐ฉ๐๐ข
โข ๐๐ฅ๐๐๐ฉ๐๐๐ฉ๐๐ข
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.
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.
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! ๐
โข โข โข
Missing some Tweet in this thread? You can try to
force a refresh
My most received questions:
"How do I start my cloud engineering journey & what's the right path?"
There's not a single or correct path.
There are only recommendations.
A small recap of mine to get yourself going ๐งตโ
(1/7) Pick a cloud provider you're interested in:
ยท Amazon Web Service
ยท Microsoft Azure
ยท Google Cloud Platform
It doesn't matter which one you start with.
Even though they are completely different in some ways, a lot of your learnings will be transferable.
(2/7) Register yourself an account
Yes, you need a credit card, but you don't need to be scared of unexpected or exploding costs.
All of the providers are having a generous free tier, allowing you to test and explore their services.
But they are only useful if you're able to make sense out of them.
Most important for that: using log levels consistently!
ยท โน๏ธ Trace
ยท ๐ก Debug
ยท โช๏ธ Info
ยท ๐ Warn
ยท ๐ด๏ธ Error
ยท โก๏ธ Fatal
A small thread about when to use what ๐งตโ
(1/7) โน๏ธ Trace
Your most verbose logs containing the most fine-grained information.
It gives you detailed insights into what's happening - not only in your code but also in third-party libraries.
Can go as far as documenting every step in a single algorithm.
(2/7) ๐ก Debug
Less information than 'trace' level, but still extended to a way that's needed to troubleshoot problems in detail.
Majorly used for pre-production/testing environments and often logs out sensitive information that can't be logged on production.
AWS is growing its number of services at a fast pace.
If we're counting namespaces, the statistics over the past decade are mind-boggling:
ยท 2013: 25
ยท 2015: 46
ยท 2017: 78
ยท 2019: 182
How to keep up with what's new?
A small thread about sources to keep you up-to-date ๐งต๐
(1/4) The AWS News Blog
Guarantees to not miss out on new features or services, but also contains interesting statistics and other insights from AWS itself.
Gets updated very regularly, sometimes several times a day.
If you're only focusing on keeping up with the new capabilities AWS provides, that's your major source.
You'll learn about small or big improvements to existing services, introductions of new ones as well as region expansions.
Scared of getting your hands on at AWS because you're in fear of unexpected costs for the cloud?
You don't have to be!
A small thread about steps you can take to sleep better on your journey to becoming an AWS expert ๐งต๐
(1/6) AWS Free Tier #1
AWS grants you a lot of room for experiments for different services each month:
- 1m Lambda Requests
- 25 GB of DynamoDB storage
- 100 build minutes on CodeBuild
... and much more!
Even better: if you've recently created your account, you also have additional free limits for the next 12 months, including for example running a EC2 t2 or t3 micro instance without any costs.