IAM

Identity and Access Management

Essentials

  • IAM (Identity & Access Management) is where you manage your AWS users, groups and roles and their access to AWS accounts and services:

    • IAM provides access to AWS resources

    • IAM is global and applied to all regions synchronously

  • Default IAM users have NO access to AWS services. Implicit deny rule on all new IAM users

  • Permissions (except for root) must be given that grant access to AWS services through IAM policies

  • Best Practices:

    • Delete root access keys

    • Activate MFA on root account

    • Create and use an IAM user with Admin privileges instead of the Root Account

    • Create individual IAM users

    • Use groups to assign permissions

    • Follow the "Principal of least privilege"

    • Apply an IAM password policy

IAM Users

  • When first created have an implicit deny on all Services

  • IAM Users receive unique credentials that you should not share with others

  • User credentials should not be "stored" in EC2 instances

  • Users can have group and regular user policies applied, many policies at once!

  • Explicit denies always override explicit allows

  • MFA can be configured on a per user basis for login and resource access/actions

IAM Groups

  • Assign permissions to more than one user at a time

IAM API Keys

  • Sign programmatic requests to AWS, required for the:

    • CLI

    • Tools for Windows

    • AWS SDKs

    • Direct HTTP calls using the APIs for individual services

  • API keys are only available ONE time, when a user is created or reissuing new keys

  • AWS will not give you the same set of keys again

  • Roles do not have API credentials

  • IF you require new API credentials - you must deactivate the current set and make new ones

  • Never create or store API keys on an EC2 instance

  • Composed of:

    • Access Key ID

    • Secret Access Key

IAM Policies

  • Document that formally states one or more permissions

  • By default, all permissions are implicit deny

  • Explicit deny ALWAYS overrides explicit allows

  • IAM has some pre-built policies for Admins, Power Users, Read-Only

  • Can create from JSON or visual editor

  • Users/Groups can have many policies

  • Cannot be attached directly to resources

IAM Roles

  • Something another entity can "assume" and will acquire temporary permissions defined in the role

    • AWS Services (EC2, Lambda, etc.)

    • IAM Users, Groups and Roles in the same or a different AWS Account

    • Federated Users (Active Directory, LDAP, Web Identity)

  • Roles must be used because policies cannot be attached directly to AWS services

  • EC2 instances can only have ONE role attached at a time

  • Trust Policy - defines the entities that have permission to assume the role

Secure Token Service (STS)

  • Allows you to create temporary security credentials that grant trusted users access to your AWS resources

  • For short term use, 15 mins and 12 or 36 hours.

  • Once expired, can no longer be used

  • When requested through an STS API Call, a credential object is returned containing:

    • Session token

    • An Access Key ID

    • Secret Access Key

    • Expiration Timestamp

Benefits

  • Avoid distributing or embedding long-term AWS security credentials in an application

  • Grant access to AWS resources without having to create an IAM user

  • Credentials are temporary, no need for manual rotation or revocation

When to Use

  • Identity Federation

    • SAML

    • Web Identity Federation - Maybe through Amazon Cognito or 3rd party Identity: Facebook, Google, Amazon

  • Roles for Cross-Account Access

    • Used for organizations with more than one account

  • Roles for Amazon EC2

    • Grant access to an app on EC2 instance without embedding credentials

AWS Organization

Essentials

  • IAM Policy Management

    • Account Groups

    • Create Accounts programmatically

  • Consolidated Billing

    • Manage payment methods

PreviousCloudfrontNextMonitoring

Last updated

Was this helpful?