AWS Solutions architect 2 - Identity and access control

In

IAM (Identity and Access Management)

IAM essentials

  • Identity an Access Management: primary servcies that handles authentication and authorization within AWs environments.
    • Systems architecture is incomplete without being able to control access in a granular way.
    • IAM controls access to AWS services via policies that can be attached to users, groups, and roles. Users are gien long term credentials to access AWS resources (username, pàssword, access keys).
    • Roles allow for short term access to resources when assumed using temporary access credentials.
  • Amazon Resource Name (ARN):
    • always begin with arm:partition:service:region:account-id
      • parition = aws or aws-cn (China)
    • depending on the service,finish with:
      • resource
      • resourcetype/resource
      • resourcetype/resource/qualifier
      • resourcetype/resource:qualifier
      • resourcetype:resource
      • resourcetype:resource:qualifier

5 different types of access

graph LR

A(1. External principal)
B[2. AWS service]
C{IAM role}
D{IAM policy}
E{IAM credentials}
F[Bucket]
G(3. Root user)
H{IAM policy}
I{4. IAM group}
J(5. IAM user)

A --> C;
B --> C;
C --> D;
D --> E;
E --> F;
G -- Full access --> F;
H --> I;
H --> J;
I -- AWS CLI --> E;
J -- Console UI --> F;

IAM policies

  • IAM policy (policy document) is known as identiy policy when attached or and identity or a resource policy when attached to a resource
  • Document
    1
    2
    3
    4
    {
      "Version": "2020-03-30"
      "Statement": [{...},{...}.,{...}]
    }
  • Each statement makes a request to AWS. Requests are matched based on their action (or actions), which the API calls or operations being attempted and the repurce (or resources) the request is against. A given statement results in Allow or Deny for the request
    1
    2
    3
    4
    5
    6
    7
    8
    9
    10
    {
      "Sid": "SpecificTable",
      "Effect: "Allow",
      "Action":
        [
          "dynamodb:BatchGet",
          "dynamodb:CreateTable"
        ],
      "Resource": "arn:ws:dynamodb:*:*:table/TestPictures"
    }
  • Tips
    • Managed policies allow the same policy to impact many identities
    • Inline policies allow exceptions to be applied to identities
    • AWs amnaged policies are low overhead but lack flexibility
    • Customer managed policies are flexible but require administration
    • Inline and managed policies can apply to users, groups and roles

IAM users

  • IAM users: a type of IAM identity for long-term access for a known entity (human, service, application)
  • Principal autehticate to IAM either with a username and a password, or using access keys
graph LR

A(User)
B((MFA))
C[IAM]
D[AWS SDK & CLI]
E(IAM user identity)
F(Resource)

A --> B
B --> C
A -- auth username & password --> C
D -- access keys --> C
C --> E
E --> F
  • Tips
    • Hard limit: 5000 IAM user per account
    • 10 group memeberships per IAM users
    • Default maximum of 10 management policies per user
    • No inline limit, but no more tahn 2048 chars for all inline policies on IAM users
    • 1 MFA per user
    • 2 access keys per user

IAM groups

  • IAM group: collection of IAM users. Groups allow easier administration over sets of IAM users. Inline and managed policies can be applied to groups that flow to members of that group
  • Groups are not a true identity - they can not be the principal in a policy, so they can not be used in resource policies
  • Tips
    • groups = admin feature
    • groups can contain many IAM users, and users can be in many groups
    • IAM inline policies can be aded to IAM groups - and these flow on to IAM users who are members
    • managed IAM policies can be attached and flow on to IAM users who are members
    • groups are not “true” identities (because it cannot be identified as a Principal in a permission policy), and they can be referenced from resource policies
    • groups have no credentials

IAM access keys

  • Access keys: a pair of values used by aplications, SDKs, or the AWS CLI to authenticate to AWS
  • Parts
    • access key id -> public, stored by AWS once generated
    • secret access key -> private, avaiabel only once the access key is fully generated. Stored by the owner
  • Only 2 sets allowed, that can be created, deleted and disabled
  • They can’t be used to log on console, and don’t expire

Securing your account — Creating an IAM user and setting up the CLI

  • Linux install
    1
    2
    3
    4
    5
    sudo yum install epel-release
    sudo yum install python-pip
    sudo pip install awscli
    aws configure
    # enter the access keys

IAM Roles

  • IAM roles: are assumed by another identity allowed in thetrust policy (IAM user AWS service, another AWS account, web identity or even an anonymous identity)
  • When arole is assumed, the security token (STS) generated a time limited set of access keys (temporary security credentials). These keys have permissios defined in the permissions policy
  • IAM roles have no long-term credentials

Multi-account management and organizations

AWS organizations

  • AWs organizations: service for managing multiple accounts within a single business

  • Allow consolidation

  • All accountswithing an AWS Organizain can consolidate bills into a single account (1 bill covering all business usage)

  • Organizations can share bulk discounts and even easily manage accounts and permisssions and limit account usage using service control policies

  • Tips

    • Service control policies (SCP) enables permission controls
    • Root user of an Organization Unit account can be restricted by creating and attaching a SCP
    • Benefits
      • Consolidated billing
      • Reduced admin overhead
      • Reserved purchases can be used by member accounts.
    • SCP FullAWSAccess: allows access to all AWS services within an attached member account
    • SCP affect any account and organizational unit under the master account
    • Attach SCP:
      • Log in to the master account and create the SCP
      • Attach the SCP to the member account within the Organizational Unit
      • Enable the SCP for the Organizational Unit
      • Select the Organizational Unit

Role switching between accounts

  • Role switching is a method of accessing one account from another inly using a set of credentials
  • Used both in organizations and between 2 unconnected accounts
  • Information needed for role switching
    • OrganizationAccountAccessRole as the role
    • Account ID of the member account
    • The display name of the role that will be seen in the linked account
graph LR

subgraph Account1
A(Account A identity)
end

subgraph Account2
B(Account B identity)
C[IAM role]
D[Trust policy]
end

A -- sts:AsumeRole --> C
C --> B
D --> A