2

chap4

Jason Zhu edited this page 2022-10-06 23:52:37 +11:00

Table of Contents

• Chapter 4: Identity and Access Management
• Introduction to the AWS IAM service
• The AWS IAM console
• The AWS IAM services
• The root user account and implementing Multi-Factor Authentication (MFA)
• The importance of defining IAM password policies
• Key differences between IAM users and IAM groups
• Defining permissions with IAM policies
• Types of identity-based policies
• IAM policy simulator
• Assigning temporary credentials with IAM roles
• Temporary credentials
• Reviewing credential reports

Chapter 4: Identity and Access Management

AWS Identity and Access Management (IAM) service.

• Function: authentication & authorization service that enable dev to decide:
  • authentication: who or what can access the AWS service in the account
  • authorization: what these entities (user, other service, or app) are permitted to do in the account

Introduction to the AWS IAM service

root user = user who create the account and has all level of access.

• It need to be guarded
• Best practice: create additional user accounts (i.e. IAM users) to perform daily tasks

The AWS IAM console

AWS IAM console is within AWS Management Console (webui), it falls under Security, Identity & Compliance category

The AWS IAM services

Login IAM console, shown below:

sign-in URL & Customization:

• sign-in URL is a special URL that IAM users (all) can browse to directly access the account resource.
• sign-in URL can be customized for custom name (e.g. PacktDevAccount.test)
  • Custom name must be unique within AWS domain

The root user account and implementing Multi-Factor Authentication (MFA)

First Thing after creating root user account: configure MFA

MFA uses 2 separate secrets to verify identity

• 1st secrete: something you know (i.e. password)
• 2nd secrete: something you have (i.e. one-time password pin that's geneated on a device, like U2F device or authentication app)

The importance of defining IAM password policies

Second Thing after creating root user account: create additional accounts for user in org to handle daily soperations.

• Every team member who need access to AWS service should be provided with IAM user account.
• Root user can define AWS password policies to force IAM user to create complex password
  • Through Account Settings

Key differences between IAM users and IAM groups

• IAM Users
  • can represent people/human in org, who need access AWS services
  • can also represent app or services that need authenticate themselves to access AWS services. i.e. service account
    • It's not best practice, as credentials/secretes for access are usually stored as config file, which can be hacked.
    • Better practice, use IAM roles
  • set up different authorization methods in different interface
    • web-based management console: username + password
    • CLI for programmatic access: access key, which consists of access key ID (like a username) + a secret access key (like a password)
• IAM groups
  • IAM Users can be configured individually (i.e. one by one) with a set permissions for accessing AWS resource using IAM policies; But IAM group is a better way
  • e.g. of IAM group: create an IAM group for developer, and then assign a single permission to the group. Then all member of the group will be given permission

Defining permissions with IAM policies

IAM policies = objects attached to a given IAM identity.

• e.g. of IAM identity
  • IAM user
  • IAM group
  • IAM role
• Policies written in JSON

AWS offer 6 types of policies:

• Identity-based policies: attached to IAM identities, specify those identities can or cannot do sth in AWS.
• Resource-based policies: attached to resource in AWS account.
  • e.g.
    • S3 bucket policies
• Permission boundaries: a permission boundary for an IAM entity (user or role), which defines maximum set of permissions that can be granted by an identity-based policy.
• Organization Service Control Policies (SCPs): org SCPs enable root user to define maximum permissions for account members of an org.
• Access Control Lists (ACLs): Permissions dev use to manage access to certain resources.
• Session policies

Types of identity-based policies

identity-based policies are written in JSON format, which can be categorized:

• Managed AWS policies:
  • standard policies pre-configured with specific permissions
  • Provided by AWS
  • Independent of any IAM identity and can be attached to many identities.
  • Cannot be edited by customer, but only updated by AWS
  • e.g. read-only access to S3
• Customer-managed policies:
  • Created/managed by customers, then attach to their AWS identity.
  • Customer can use IAM to creates up to 5 versions of policies, so can be easily reverted.
• Inline policies:
  • Policies that created & attached directly to IAM identity.
  • one-to-one relationship btw a given policy and an identity.

As e.g. AmazonS3ReadOnlyAccess shown above

Components in identity-based policy:

• Version: JSON document version supported by AWS
• Statement: Beginning of policy statement.
• Effect: Specify whether statement block is allowing or denying
• Action: Actual permission that's effected by effect; e.g. Get, GetBucketVersion
• Resource: Resource that policy permit/deny access against.
  • FGor specifi resource, use Amazon Resource Name (ARN) (a unique identifier of the resource in AWS account)

ARN composed of segments and each segment is delimited with a colon :.

• Formats can be constructed:
  • arn:partition:service:region:account-id:resource-id
  • arn:partition:service:region:account-id:resource-type/resource-id
  • arn:partition:service:region:account-id:resource-type:resource-id
• Individual segment components:
  • partition: partion of AWS that the resource resides.
  • service: service namespace that can identities the AWS product. e.g. s3
  • region: Region that resource located
  • accountID: ID that owns that resource
    • some resources do not need accountID for ARN. e.g. s3 -> arn:aws:s3:::packt-marketing-docs, where region & accountID is omitted
  • resource or resourcetype

IAM policy simulator

To test policies or troubleshoot any access issues, IAM policy simulator can be used.

It only simulate policy but do not actually visit resource via API.

Assigning temporary credentials with IAM roles

IAM roles are not attached to a specific user. Its general use cases to grant access to:

• An AWS service that needs access to a service in your account
• An IAM user in another account need access service in your account via cross-account access
• A federated user from web Identity Provider (Idp) (e.g. Google)
• A federated corporate user using an identity service such as Microsoft Active Directoy.

Temporary credentials

• Key benefit of using IAM roles: IAM roles use tomporary credentials that are rotated on regular basis by AWS
  • e.g. 3rd-party mobile app been granted with access without storing long-term credentials on mobile phone
• IAM roles use service Security Token Service (STS), which assgins temporary credentials to identities.
  • temporary credentials consists of an access key ID, a secret access key, security token.
    • security token is valid for short term, and becomes useless after expiration

IAM roles instead of a IAM user account is preferred for entity external to your org

Reviewing credential reports

Credential Report (in CSV) can be downloaded every 4 hours:

• useful for auditing/monitoring