Tobias Schmidt
Tobias Schmidt

@tpschmidt_

11 Tweets Jan 15, 2023
"๐˜ž๐˜ฉ๐˜ช๐˜ค๐˜ฉ ๐˜ˆ๐˜ž๐˜š ๐˜š๐˜ฆ๐˜ณ๐˜ท๐˜ช๐˜ค๐˜ฆ๐˜ด ๐˜ฅ๐˜ฐ๐˜ฆ๐˜ด ๐˜บ๐˜ฐ๐˜ถ๐˜ณ ๐˜ข๐˜ฑ๐˜ฑ๐˜ญ๐˜ช๐˜ค๐˜ข๐˜ต๐˜ช๐˜ฐ๐˜ฏ ๐˜ถ๐˜ด๐˜ฆ?"
Nobody ever includes ๐—”๐—ช๐—ฆ ๐—œ๐—”๐—  in their answer, even though it's ๐—ผ๐—ป๐—ฒ ๐—ฐ๐—ฟ๐—ถ๐˜๐—ถ๐—ฐ๐—ฎ๐—น ๐˜€๐—ฒ๐—ฟ๐˜ƒ๐—ถ๐—ฐ๐—ฒ for ๐—ฎ๐—น๐—น ๐—ฎ๐—ฝ๐—ฝ๐˜€ ๐Ÿ”
A collection of ๐—ฏ๐—ฒ๐˜€๐˜ ๐—ฝ๐—ฟ๐—ฎ๐—ฐ๐˜๐—ถ๐—ฐ๐—ฒ๐˜€ ๐Ÿงต โ†“
๐—Ÿ๐—ผ๐—ฐ๐—ธ ๐—ฎ๐˜„๐—ฎ๐˜† ๐˜†๐—ผ๐˜‚๐—ฟ ๐—ฟ๐—ผ๐—ผ๐˜ ๐˜‚๐˜€๐—ฒ๐—ฟ
Your root user has full access to your account (and organization) & controls billing.
Don't use it for daily tasks.
This means. your first tasks are:
โ€ข create a dedicated IAM user
โ€ข delete any credential pairs of the root user
๐—˜๐—ป๐—ฎ๐—ฏ๐—น๐—ฒ & ๐—˜๐—ป๐—ณ๐—ผ๐—ฟ๐—ฐ๐—ฒ ๐— ๐˜‚๐—น๐˜๐—ถ-๐—™๐—ฎ๐—ฐ๐˜๐—ผ๐—ฟ ๐—”๐˜‚๐˜๐—ต๐—ฒ๐—ป๐˜๐—ถ๐—ฐ๐—ฎ๐˜๐—ถ๐—ผ๐—ป
AWS offers MFA for IAM users and your root user as well.
It supports virtual & hardware tokens.
Bonus: create a policy that restricts access to all resources if MFA authentication is missing.
๐— ๐—ฎ๐—ธ๐—ฒ ๐˜‚๐˜€๐—ฒ ๐—ผ๐—ณ ๐—œ๐—”๐—  ๐—š๐—ฟ๐—ผ๐˜‚๐—ฝ๐˜€ ๐Ÿ‘ฅ
Don't directly assign permissions to IAM users, but create groups with dedicated permissions.
The management will be easier as everything is streamlined and you can move users between & or remove them from groups.
๐—ฅ๐—ผ๐—น๐—ฒ๐˜€ ๐—ฎ๐—ฟ๐—ฒ ๐˜†๐—ผ๐˜‚๐—ฟ ๐—ฏ๐—ฒ๐˜€๐˜ ๐—ณ๐—ฟ๐—ถ๐—ฒ๐—ป๐—ฑ ๐Ÿงก
Roles are very similar to users but can be assumed by multiple entities at the same time.
It enables you to grant permissions without further credentials.
e.g. a user can assume a role to grant temporary access to a resource.
๐—ฅ๐—ฒ๐˜€๐—ผ๐˜‚๐—ฟ๐—ฐ๐—ฒ-๐—ฏ๐—ฎ๐˜€๐—ฒ๐—ฑ ๐—ฃ๐—ผ๐—น๐—ถ๐—ฐ๐—ถ๐—ฒ๐˜€ ๐Ÿค–
Certain AWS services like S3 or SQS offer resource-based policies which give you another (additional) tool to identity-based policies to restrict access even better.
๐—ก๐—ผ ๐—ถ๐—ป๐—น๐—ถ๐—ป๐—ฒ ๐—ฝ๐—ผ๐—น๐—ถ๐—ฐ๐—ถ๐—ฒ๐˜€ ๐Ÿ“
Inline policies allow you to embed permissions into an IAM identity, so a user, group, or role.
This can be useful for some use-cases but increase your management efforts.
Stick to simple managed policies when possible.
๐—จ๐˜€๐—ฒ ๐—–๐—ผ๐—ป๐—ฑ๐—ถ๐˜๐—ถ๐—ผ๐—ป๐˜€ ๐Ÿšง
You can extend your policies with one or more conditions that determine under which circumstances the policy should apply.
e.g. you can create a condition that lets an IAM user manage their home directory in an Amazon S3 bucket
Aim for ๐—Ÿ๐—ฒ๐—ฎ๐˜€๐˜ ๐—ฃ๐—ฟ๐—ถ๐˜ƒ๐—ถ๐—น๐—ฒ๐—ด๐—ฒ ๐Ÿ”
It's easy to spike things by using a wildcard for actions & resources.
But spikes often end up in production quickly - with a missed refactoring for IAM.
Always try to aim for policies that are on-point, only granting needed permissions
Bookmark ๐—”๐—ช๐—ฆ ๐—ฆ๐—ฒ๐—ฟ๐˜ƒ๐—ถ๐—ฐ๐—ฒ ๐—”๐˜‚๐˜๐—ต๐—ผ๐—ฟ๐—ถ๐˜‡๐—ฎ๐˜๐—ถ๐—ผ๐—ป ๐—ฅ๐—ฒ๐—ณ๐—ฒ๐—ฟ๐—ฒ๐—ป๐—ฐ๐—ฒ ๐Ÿ”–
You'll unavoidably fight with ๐—”๐—ฐ๐—ฐ๐—ฒ๐˜€๐˜€ ๐——๐—ฒ๐—ป๐—ถ๐—ฒ๐—ฑ messages from time to time
The docs for Actions, resources, and condition keys for all AWS services are here to help
docs.aws.amazon.com
The obvious: use ๐—œ๐—ป๐—ณ๐—ฟ๐—ฎ๐˜€๐˜๐—ฟ๐˜‚๐—ฐ๐˜๐˜‚๐—ฟ๐—ฒ ๐—ฎ๐˜€ ๐—–๐—ผ๐—ฑ๐—ฒ ๐Ÿ—
The AWS console is fine for testing out things.
For everything else: use an IaC tool of your choice to avoid typos & make your configuration reliable and reproducible.
My favorites: CDK, Serverless & Terraform

Loading suggestions...