IAM (Identity and Access Management)

 

    • FAQ
    • Gives you centralized control of an AWS account
    • Is global – there is no concept of regional IAM at this time; all users, groups, policies, etc are available in all regions.

Users

  • Are the individual accounts.
  • By default, new users don’t have access to any AWS services.
  • Always set up MFA (Multifactor Authentication) on your root account.
  • IAM can be used to create and customize password rotation policies.
  • There are two ways to access AWS:
    • Username + Password
    • Access Key ID + Secret Access Key
  • Username and Password
    • Cannot be used to interact with the API
    • Can be used to sign in via a custom sign-in link which you can create via the IAM console i.e.
  • Access Key ID and Secret Access Key
    • Assigned on user creation
    • Can be used to interact via the AWS command line, SDKs, or APIs.
    • Not the same as Username and Password.
    • Can only be viewed once. If you lose them, they need to be regenerated. Save them in a secure location.

Groups

  • Are a collection of IAM users, simplifying the assigning of permissions. i.e. you can have groups for different departments such as Sales, Developers, HR, etc, which may all require different levels of AWS access.
    • A user can belong to multiple groups
    • Groups cannot belong to other groups

Roles

  • You can create roles, then assign them to AWS resources.
  • i.e. you might have an EC2 instance, and give it a role saying it can access S3. That way the EC2 instance can directly access S3 without having to manage usernames, passwords, etc.
  • Limited to 500 IAM roles under your AWS account. The acloud.guru course states up to 250.
  • Role types:
    • AWS Service
    • Another AWS Account (allows entities in other accounts to perform actions in the current account)
    • Web Identity (Amazon, Cognito, Facebook, Google)
    • SAML / OpenID Connect
  • API Actions for assuming roles:
    • AssumeRole
      • You cannot call AssumeRole by using AWS root account credentials; access is denied. You must use credentials for an IAM user or an IAM role to call AssumeRole.
    • AssumeRoleWithSAML – for when users have been authenticated via a SAML authentication response, i.e. an on-premises VPC
    • AssumeRoleWithWebIdentity (when users have been authenticated in a mobile app or web app with a web identity provider such as Facebook, Google, or OpenID connect)

– Including an IAM access policy with AssumeRole

  • When assuming a role, you can further restrict access via passing an IAM access policy on each request.
  • If you pass a policy to this operation, the temporary security credentials that are returned by the operation have:
    • the permissions that are allowed by both the access policy of the role that is being assumed
    • and the policy that you pass.

… this gives you a way to further restrict the permissions for the resulting temporary security credentials.

You cannot use the passed policy to grant permissions that are in excess of those allowed by the access policy of the role that is being assumed.

More info on STS API Operations

Policy Documents

  • An IAM policy is a document which formally defines permissions, and can be attached to users, groups, and roles.
  • The “ PowerUserAccess” policy provides full access to AWS services and resources, but does not allow management of users and groups.
  • For example, here’s one of the default AWS policy documents for assigning full access to S3:

STS (Secure Token Service)

  • STS is used for requesting temporary, limited-privilege credentials for AWS IAM users or for federated users which you authenticate.
  • The temporary security credentials are valid for the duration that you specified when calling AssumeRole, which can be from 900 seconds (15 minutes) to a maximum of 3600 seconds (1 hour). The default is 1 hour. More info
  • Supports the following sources:
    • Federation (typically Active Directory)
        • Uses SAML
        • Allows you to use credentials from another provider (i.e. Active Directory) – does not need to be IAM credentials
        • Does not need to be a user in IAM, or need any IAM credentials
    • Federation with mobile apps
      • Using Facebook/Amazon/Google or other OpenID provider to log in
  • Cross-account access – allowing users from AWS account to access resources in another

To use STS Federation, you must implement the following steps in the following order:

  1. Develop an Identity Broker to communicate with LDAP (Lightweight Directory Access Protocol, one of the protocols that you can use to talk to Active Directory) and ST
  2. Identity Broker always authenticates with LDAP first, THEN with AWS STS
  3. Application then gets temporary access to AWS resources

Web Identity Federation

  • Useful for mobile apps which need to access AWS resources, and allows the app to receive an auth token, and then use that token for temporary credentials.
  • It’s strongly recommended to not embed or distribute long-term AWS credentials with apps that are user downloads to a device.
  • Web Identity Federation supports the following providers:
          – Amazon
          – Facebook
          – Google
          – Any other OpenID Connect (OIDC) compatible id provider