AWS IAMIcon-Architecture/64/Arch_AWS-Identity-and-Access-Management_64Created with Sketch.

SECURELY MANAGE IDENTITIES AND ACCESS TO SERVICES AND RESOURCES

INTRODUCTION👋

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.

CAPABILITIES💎

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:

  • managing users for your AWS account, with individual permissions that can even be temporary
  • enforcement of password policies or MFA
  • permission boundaries for services and applications
  • federation with other identity providers

PRINCIPALS

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🔒

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.

  • Bad: assign permissions to DynamoDB via wildcards.
  • Good: fine-grained permissions, explicitly specifying the actions and resources.

KEY TERMS🔑

IAM comes with multiple core concepts:

  • User: an identity representing a user accessing AWS.
  • 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 all the permissions of the policy.

ROOT USER⚠️

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:

  • Go to your security page, select Manage MFA Device and assign a security-token device, e.g. Google Authenticator.
  • If there's already an Access Key, you should delete it as you also shouldn't work with the CLI.
  • Create your first dedicated user as User + Add User. You can make use of AWS predefined policies at first.
  • Lock away your root credentials securely.

POLICIES📜

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:

  • Identity-based: attachable to users, groups, or roles.
  • Resource-based: attachable to resources, e.g. S3 buckets, SQS queues, or KMS keys.

STATEMENTS📝

Statements contain the permissions you want to grant and are defined as JSON.

A statement must contain:

  • Effect - the indication if it's a Deny or Allow.
  • Action - a list of actions.
  • Resource - a list of resources for which the actions are granted (can be omitted for resource-based policies).

Additionally, you can extend your policies with conditions to further drill down permissions.

PERMISSION BOUNDARIES🔒

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.

CREDENTIALS🔐

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.

TOOLING🛠️

There's a lot of support for following security best practices:

  • AWS Trusted Advisor: reviews your permissions for unnecessary rights, best practice violations and includes checks that you've enabled AWS security features for your services and resources.
  • AWS Policy Simulator: helps to build, validate and troubleshoot your policies. It supports identity-based, resource-based and even Organizations service control policies.
  • 3rd party tools like Dashbird.io guiding you with security recommendations & well-architected tips.

ACCESS DENIED🛑

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.

AWS CLI💻

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.