IAM

Users

  • Each account has it's own root user. This user can do anything in that account and cannot be disabled.

  • SCP can be used to deny every call for the root account. While it doesn't disable it and people can still log in, it can't do anything.

  • Management account = a root user too

  • Best to limit the amount of IAM users because they are usually over permissioned.

  • Federated user/SSO: Can be federated with Okta or Entra ID.

CLI/Cloudshell:

aws iam list-users

IAM User Properties:

  • Groups

    A list of group names to which you want to add the user.

  • LoginProfile

    Creates a password for the specified IAM user. A password allows an IAM user to access AWS services through the AWS Management Console.

  • ManagedPolicyArns

    A list of Amazon Resource Names (ARNs) of the IAM managed policies that you want to attach to the user.

  • Path

    The path for the user name. For more information about paths, see IAM identifiers in the IAM User Guide.

  • PermissionsBoundary

    The ARN of the managed policy that is used to set the permissions boundary for the user.

    A permissions boundary policy defines the maximum permissions that identity-based policies can grant to an entity, but does not grant permissions.

  • Policies

    Adds or updates an inline policy document that is embedded in the specified IAM user. To view AWS::IAM::User snippets, see Declaring an IAM User Resource.

  • Tags

    A list of tags that you want to attach to the new user. Each tag consists of a key name and an associated value. For more information about tagging, see Tagging IAM resources in the IAM User Guide.

  • UserName

    The name of the user to create. Do not include the path in this value.

IAM User Groups

  • Users can be listed together in IAM User Groups and permissions can be assigned to the group.

CLI/Cloudshell:

aws iam list-groups

Roles

  • A role has two major components

    • What the role is allowed to do → (IAM permissions policy)

    • Who is allowed to take on the role → (trust policy)

  • Taking a role in AWS is called an AssumeRole action this allows us to temporarily take on a role without needing an IAM user and credentials in the target account

  • The service that makes this possible in AWS is Security Token Service (STS).

    • STS gives temporary credentials for a role.

  • Cross tenant access

    • Roles can be assumed from a different AWS tenant (attacker > victim).

      • IAM role trust policy allows external user to AssumeRole.

    • Won't detect this in IAM users or IAM policies, because it is defined in the IAM roles.

AssumeRole:

  • Provides temporary access key for user to use.

CLI/Cloudshell:

aws sts assume-role --role-arn EXAMPLE --role-session-name EXAMPLE
  • Provide credentials to .env variables in AWS CLI to assume role automatically.

Role Chaining

  • Roles can also assume other roles which is called role chaining which makes it even more complex to investigate who was ultimately responsible.

Security Token Service (STS)

  • Expiration time on tokens is definable.

    • Because sessions for access keys expire; if the TA has extended access, there will be multiple access keys for us to investigate.

  • Minimum access key lifetime: 15 mins

Access Analyzer

  • Paid service that helps find 'dangerous' roles as well as finding over permissioned roles and potentially roles you don’t need any more.

  • External access findings (FREE)

    • Review any IAM roles/policies for Public Access

    • Review any IAM roles/policies for Cross-Account Access

  • Unused access findings (PAID)

    • Finds unused roles, access keys, IAM user that are obsolete.

  • Takes hour or hours to run.

Policies

  • Big 3 policies (seen most often):

    • Identity based

      • Assigned to identities (IAM users, IAM groups)

    • Resource based

      • Assigned to resources (S3s, EC2s, etc).

      • Example: Allow a specific IP to talk to an S3 bucket only.

    • Service Control Policy (SCP)

      • Assigned to organization OUs. Used to set guardrails in AWS.

External Access Policies:

https://yehudacohen.substack.com/p/a-quick-overview-of-aws-principals

  • Identity-based policies cannot expose your resources in your AWS account to principals that exist outside of your AWS account.

  • If you want to grant a principal outside of your AWS account access to your AWS account, you must use a resource-based policy.

Policy Examples:

Identity Based

  • Effect:

    • Allow or deny (default is deny).

  • Action:

    • The specific API calls (Get, Put, Post, etc)

  • Resource:

    • Object the policy is applied to.

Resource Based:

  • Effect:

    • Allow or deny (default is deny).

  • Action:

    • The specific API calls (Get, Put, wildcard *)

  • Principal:

    • Allows external accounts to access resource.

  • Resource:

    • Resource the policy is applied to.

Service Control Policy:

  • Effect:

    • Allow or deny (default is deny).

  • Action:

    • The specific API calls (Get, Put, wildcard *)

  • Resource:

    • OU the policy is applied to.

    • Applied to all AWS accounts under OU.

  • Condition:

    • Boolean conditions that policy abides by.

IR Policies:

Policy Evaluation:

  • By default everything is denied, unless there is an allow somewhere along the evaluation.

    • If there is an explicit deny somewhere along the hierarchy, it will be denied.

    • If there is an allow in the hierarchy, it will be allowed. UNLESS there is an explicit deny lower in the chain.

  • Organization SCP:

    • If there is a deny at this stage, the evaluation will stop before looking at the lower level policies.

Last updated