SECURELY MANAGE IDENTITIES AND ACCESS TO SERVICES AND RESOURCES
For seriously working with AWS, there's no way around AWS Identity and Access Management (IAM). It is the security fundamentals of the AWS Cloud. Skipping to understand its core principles will bite you again and again in the future.
It's worth to take the time to deep dive and avoid frustrations at a later stage of your journey.
From our perspective, IAM is the most complete service of AWS. It's thoughtfully built and integrated deeply with other services while abstracting away many burdens from us and like cumbersome credential management.
Its feature set contains, among others:
Resource-based policies also need to define a principal. It indicates for which account, (federated) user, or role user you want to allow or deny access.
There are more specifics for this type of policy - for example they aren't affected by permission boundaries.
Least Privilege states that you should always only assign the permissions that are actually needed for the service to fulfill its goals.
Looking at an example: your application runs on Lambda and needs access to a single DynamoDB table.
IAM comes with multiple core concepts:
It's explicitly recommended by AWS to not work with your root credentials, as it's permissions are too wide.
First usage recommendation for your root user:
At AWS IAM, everything revolves around policies. By default, all actions for all services are denied. So you have to explicitly grant permissions by adding a policy with your targeted actions and resources to your service role, user, or group.
You can attach one or multiple policies to a role and each policy can contain one or multiple statements.
Policies come in two different flavors:
Statements contain the permissions you want to grant and are defined as JSON.
A statement must contain:
Additionally, you can extend your policies with conditions to further drill down permissions.
Help you to restrict effective permissions for a user or role. They also contain policies that describe actions and resources, but they are used as an outer boundary.
If your boundaries only lists dynamodb:Query for all resources, a role with dynamodb:* can't update or delete items, but only query.
Boundaries can be defined in one place but re-used across all of your account's roles and users.
For accessing the AWS API to create, update or delete your infrastructure resources via code, you'll need credentials.
These can be created at your security credentials page by clicking Create Access Key to get a set of Access Key ID and Secret Access Key.
Keep in mind: There's no way to display the Secret Access Key again, but you can create a new pair at any time.
There's a lot of support for following security best practices:
When working with AWS, especially in the beginning, you will face this message at least from time to time.
Mostly, AWS API error responses will exactly point you the missing permission so you can easily extend your policy.
Sometimes it's not that easy and you'll need to get back to the documentation to find out about required permissions. A great resource is the Actions, resources, and condition keys for AWS services with can be found at the Service Authorization Reference and docs lists every IAM action, resource and conditions for every AWS service.
What you should never do: just blindly pretending your policy with all permissions for your target AWS service by adding wildcards for actions and resources, e.g. adding ["dynamodb:*"] and resource: ["*"].
You won't gain any learnings for IAM and you're distributing unnecessary permissions which can lead to critical incidents.
With your credentials in place, you should install the AWS CLI. Run aws configure at first for doing the initial setup.
Be asked for your Access Key ID, Secret Access Key, as well as your default AWS region (e.g. us-east-1) and default CLI output (e.g. json).
When you're working with different accounts, roles, and enabled MFA, it's a necessity to get some tooling support.
A great solution is Leapp. An app designed to manage and secure cloud access in multi-account environments. It's available for macOS, Windows, and Linux.
It's also open-source and supports other prominent cloud providers like Azure or GCP.