Identity & Access Management (IAM):

IAM 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 and access permissions to AWS resources (such as EC2, S3 and DynamoDB).
    • IAM is global to all AWS regions, creating a user account will apply to all the regions.
  • The common use of IAM is to manage:
    • Users
    • Groups
    • Roles
    • IAM Access Policies
    • API keys
    • Specify a password policy as well as manage MFA requirement on a per user basis
  • By default, any new IAM user you create in an AWS account is created with NO access to any AWS service. This is a non-explicit deny rule set on all new IAM users.
  • For all users (besides root user), permissions must be given that grant access to AWS services (this is done through IAM Policies).
  • When a new AWS root account is created, it is "best practice" to complete the tasks listed in IAM under "Security Status" - which includes:
    • Delete your root access keys
    • Activate MFA on your root account
    • Create individual IAM users
    • Use groups to assign permissions
    • Apply an IAM password policy
  • Best practice is to login in and do daily work as an IAM user - NOT as root user.
  • It is also best to always best to practice the "Principle of Least Privilege" when administering AWS accounts, users, groups and roles.

IAM Policies:

  • A policy is a document that formally states one or more permissions.
  • By default, an explicit deny always overrides an explicit allow.
    • This allows for the use of a "deny all" policy to quickly restrict ALL access that a user may have through multiple attached policies.
  • IAM provides pre-built policy templates to assign to users and groups, examples include:
    • Administrator access: Full access to ALL AWS resources.
    • Power user access: Admin access except it does not allow user/group management.
    • Read only access: Only view AWS resources (i.e. user can only view what is in an S3 bucket).

  • You can also create custom IAM permission policies using the policy generator or written from scratch.

  • More than one policy can be attached to a user or group at the same time.

  • Policies cannot be directly attached to AWS resources (such as an EC2 instance).

IAM Users

  • When first created, by default an IAM User has a non-explicit "deny" for all AWS services - and does NOT have access to use them until a policy granting allow access has been applied to the user or to the group the user belongs to.
  • IAM Users receive unique access credentials so you do not (and should not) share with others.
  • User credentials should NEVER be stored or "passed" to an EC2 instance.
  • Users can have group and regular user policies apply to them - meaning a user can have multiple IAM policies applied to them at any given time.
  • By default, an explicit deny always overrides an explicit allow from attached IAM policies.
  • MFA can be configured on a per user bases for login and resource access/actions.

IAM Groups:

  • Allow you to assign IAM permission policies to more than one user at a time.

  • This ability allows for easier access management to AWS resources.

IAM Roles:

  • A role is something that another entity can "assume", and in doing so requires the specific permissions defined by the role.
  • In the context of this course, "entities" that can assume a role include AWS resources (such as an EC2 instance) OR a non-AWS account holder who may need temporary access to as AWS resource (through a service like Active Directory).
  • Roles must be used because policies CANNOT be directly attached to AWS services.

For example, if you are using an EC2 instance and it needs to access to an S3 bucket:

  • Instance should assume a role from IAM with the proper required permissions (S3 read only).

  • Instance can then perform actions based on the role it assumes (read from S3).

  • You "can" but should never pass or store credentials in or to an EC2 instance - so roles are.

  • Until recently, you could only assign a role to an EC2 instance during the EC2 instance's creation process. However, you can now assign/change a role that is assigned to an EC2 instance after the creation process via the CLI or the EC2 management console.

  • An EC2 instance can only have ONE role attached at one time.

Other use of roles:

  • Other users can assume a "role" for temporary access to AWS accounts and resources through having something like Active Directory or Single Sign On service (i.e. Facebook, Google) assume an "Identity Provider Access" role.
  • Create "cross account" access where a user from one account can assume a role with permission in another account.

IAM Security Token Service (STS):

  • STS allows you to create temporary credentials that grant trusted users access to your AWS resources.

  • These temporary credentials are for short-term use, and can be active for a few minutes to several hours.

  • Once expired, they can no longer be used to access your AWS resources.

  • When requested through an STS API call, credentials are returned with three components:

    • Security Token

    • An Access Key ID

    • A Secret Access Key

STS API Calls
  • AssumeRole: Cross-Account Delegation and Federation Through a Custom Identity Broker.
  • AssumeRoleWithWebIdentity: Federation Through a Web-based Identity Provider.
  • AssumeWithSAML: Federation Through an Enterprise Identity Provider Compatible with SAML 2.0.

  • GetFederationToken: Federation Through a Custom Identity Provider.

  • GetSessionToken: Temporary credentials for Users in Untrusted Environmenst.

STS Benefits:
  • No distributing or embedding long-term AWS security credentials in an application.
  • Grant access to AWS resources without having to create an IAM identity for them.
    • The basis for IAM roles and identity federation.
  • Since the credentials are temporary, you don't have to rotate or revoke them.
    • You decide how long they are active for.
When to Use STS:
  • Identity Federation:
    • Enterprise identity federation (authenticate through your company's network).
      • STS supports Security Assertion Markup Language (SAML), which allows for use of Microsoft Active Directory (or your own solutions).
    • Web identity federation (3rd party identity providers, i.e. Facebook, Google, Amazon).
  • Roles for Cross-Account Access
    • Used for organizations that have more than one AWS account.
  • Roles for Amazon EC2 (and other AWS services)
    • Grant access to an application running on an EC2 instance to access other AWS services without having to imbed credentials.

IAM API Keys:

  • API Access Keys are required to make programmatic calls to AWS from the:
    • AWS Command Line Interface (CLI).
    • Tools for Windows PowerShell.
    • AWS SDKs.
    • Direct HTTP calls using the APIs for individual AWS service.
  • For example:
    • API credentials are used by developers, working from an on-premise network, for CLI access.
  • Important API Access Key Facts:
    • API Keys are only available ONE time, when a new user is created OR when you reissue a new set of keys.
    • AWS will NOT generate the same set of access keys.
    • In order for API credentials to work, they must be associated with a USER.
    • Roles do NOT have API credentials.
    • In the AWS console, you can only see the Access Key ID - NEVER see the Secret Key ID.
    • If you require new API credentials - you must deactivate the current set and generate the new one.
    • NEVER create or store API keys on an EC2 instance.

results matching ""

    No results matching ""