IAM

References

Action, Resource, Condition Keys for AWS Services

https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_policies_actions-resources-contextkeys.html

AWS Services table work with IAM

https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_aws-services-that-work-with-iam.html

Policy JSON

https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_policies.html

Grammar: https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_policies_grammar.html

Elements: https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_policies_elements.html

Policy Simulator

https://policysim.aws.amazon.com/home/index.jsp?#

Basics

Root user - first user account with complete access, only recommended to use to create the first user.

Features: grant granular permissions, provide credentials for applications on EC2 instances, MFA, ID federation to allow temporary access to user identified by internet id provider (corporate network, cognito), log in CloudTrail, PCI DSS credit card data compliance, eventually consistency, free to use

Type of access:

• IAM users - use username / password (MFA) for console; use credential for CLI / API
• non-IAM users - use federation (get temporary credential, use AWS Security Token Service API)
• cross account: use role and trust

How it works

• Principal who makes a request for action (users, roles, federated users, applications)
• Resources object within a service
• Request, gathered into a request context, includes
  • Actions / operations
  • Resources (resource object)
  • Principal
  • Environment data (IP address, SSL status, user agent, date time, etc.)
  • Resource data (such as database table name)
• Authentication
  • Authentication required as a principal
    • console: username password MFA etc.
    • API, CLI: access key & secret key
  • Anonymous access an exception for some services: S3, STS
• Authorization with Policies (JSON document, editable with console visual editor)
  • Be several types of policies categorized as
    • Permission Policies - attach to object, include
      • ID based (most common), provide users access to resources in their own account
        • Permission Boundaries - advanced feature, allow limit maximum permissions a principal can have (does NOT grant permission, but LIMIT permission even granted in ID based policy) Permissions boundaries do not affect the permissions granted by a resource-based policy.
      • Resource based, best for cross-account access
      • ACLs
      • AWS Organizations service control policies (SCPs) – Organizations SCPs specify the maximum permissions for an organization or organizational unit (OU). The SCP maximum applies to entities in member accounts, including each AWS account root user. If an SCP is present, identity-based and resource-based policies grant permissions to entities only if those policies and the SCP allow the action
      • Session policies - when obtain temporary credential, can optionally pass session policy to further restrict the permissions of the session (cannot go beyond the role's permission)
  • Policy evaluation (order of override by) : default denied (except root)(lowest) => explicit allow => permissions boundary => explicit deny in any (highest)
    • Evaluation occur at Request time
    • So resources added after policy still counts (e.g. with "*")
  • Modes:
    • Role-based access control (RBAC): the common & traditional one, define user by job function, attach policy to user. difficulty is when add new resources, must add access to the principals
    • Attribute-based access control (ABAC): permission based on attributes & condition (equal, etc.) (tags, but also other attributes such as resource region, etc.), e.g. allow principal (with certain value of an attribute, e.g. tag) access resource (with certain value of some attribute, e.g. a tag). Advantage: can add new resource (with tag) without updating policy; requires fewer policies; granular permissions possible; federation (SAML etc.) can pass tags to principals

Principals

Principal who makes a request for action (users, roles, federated users, applications) (reference: https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_policies_elements_principal.html)

Specifying a principal in AWS policy document:

• AWS Account and individual IAM user (When you use an AWS account identifier as the principal in a policy, you delegate authority to the account. Within that account, the permissions in the policy statement can be granted to all identities)
  • (account) "Principal": { "AWS": "arn:aws:iam::123456789012:root" }
  • (account, another format) "Principal": { "AWS": "123456789012" }
  • (more than one accounts) {"AWS": [ "arn:aws:iam::123456789012:root", "999999999999" ]}
  • (specific user) "Principal": { "AWS": "arn:aws:iam::AWS-account-ID:user/user-name" }
• Federated user:
  • "Principal": { "Federated": "cognito-identity.amazonaws.com" }
  • (using a SAML identity provider) "Principal": { "Federated": "arn:aws:iam::AWS-account-ID:saml-provider/provider-name" }
• IAM Role
  • "Principal": { "AWS": "arn:aws:iam::AWS-account-ID:role/role-name" }
  • (Assumed role user, with Secure Token Service)"Principal": { "AWS": "arn:aws:sts::AWS-account-ID:assumed-role/role-name/role-session-name" }
• AWS Service
  • (service principal with long name) "Principal": { "Service": [ "elasticmapreduce.amazonaws.com", "datapipeline.amazonaws.com" ] },
  • (certain services like S3, Canonical User) "Principal": { "CanonicalUser": "79a59df900b949e55d96a1e698fbacedfd6e09d98eacf8f8d5218e7cd47ef2be" }
• Assumed-role sessions
• Everyone
  • "Principal": "*"
  • "Principal" : { "AWS" : "*" }
• NOT able to be specified as principle: IAM groups

Users & Groups

Account Root - don't use for everyday, has complete access to account

IAM users - within the account, can be created access key, can be application (in addition to person) but for application running on EC2 best to use role; can be attached policies (managed and inline)

Federated users - SAML2.0, ID broker, AWS Directory Service, Internet ID (Cognito, Amazon, Google, Facebook), has no permanent ID, can assume Role & Role be granted permission

IAM Roles - similar to user in that permission policies can be attached, but has no credentials, not for person/entity to identify, but for federated users or applications to ASSUME (after they have identified) and obtain temporary credential (is both Principal, i.e. ID based policies can be attached, and Resource, i.e. resource based policy - role trust policy - be attached, to specify who can assume this role)

IAM Groups - group of IAM users, but not a 'true ID' since it's not a Principal; cannot be nested; can be specified permission; can be attached policies (managed policies, i.e. can be attached to multiple principals & inline policies, i.e. just for the group; policy contain no principal - it's implied)

Temporary credentials - primarily used with roles, expire after period of time

AWS Organization - Makes cross-account easy

Permission & Policies

Permission Policies

Types (most->least frequently used):

ID based

Attach to principal (IAM user, group, role), specify what the principal can do

• Managed policies - standalone policies that can attach to multiple principals
  • AWS managed - AWS created & managed
  • Customer managed - user create and manage
• Inline policies - attach to single principle (or through group to multiple users but the single group) directly
• Cannot have "principal" as already implied (principal is the one the policy is attached to)

{

    "Version": "2012-10-17",

    "Statement": [ {

        "Effect": "Allow",

        "Action": [

            "iam:GenerateCredentialReport",

            "iam:Get*",

            "iam:List*"

        ],

        "Resource": "*"

    } ]

}

Resource based

(only some resources use resource based policies, most common: S3 bucket policies & IAM role trust policies; also SNS topic, SQS queue, etc.)

• All inline policies (no managed resource based policy)
• Attach to a resource (no "Resource", as it's implied)
  • IAM supported resource based policy: role trust policy - attach to a role, define which principals can assume the role
  • Other services support other resource based policies (such as S3 etc.)
• Include "Principal" - who
• Cross-account access
  • can specify an entire account or IAM entities in another account as the principal (without through a role)
    • Benefit: without assuming a role, principle (from trusted account) still have access to resources in own account, especially useful for copying resources between two accounts
  • only half way: (when cross account) also use an identity-based policy to grant the principal access to the resource (non-cross account does not require this)
    • if permission grant to another account, the root user of that account has the granted permission, a user in the trusted account by default does NOT has permission
    • then permission can be delegated to user, not beyond of the granted permission (with ID based policy)
• (grant access to resource CAN/often uses ID based policy, for example, lambda first assume role, then use policy attached to the role to access other resources)
• Organizations Service Control (SCP) Policy - for AWS Organizations, define maximum permission without granting
• Access control lists (ACLs) - similar to resource-based policies but the only policy type does not use JSON - supported services include S3, WAF, VPC...

Permission Boundaries

• Apply to AWS Organizations or IAM users or roles
• Set maximum allowable permission, not granting

AWS Security Token Service (AWS STS) for temporary credentials

Temporary, short term credential (no need to store, rotate), based on role or federation. The credential & token works globally by default (but can be optimized for & restricted to region). Can also access through VPC (avoid through public network)

Federation:

• Enterprise: SAME 2.0 based, needs a broker
• Web: OpenID (OIDC) based

Obtain:

• AssumeRole (call, from AWS identity with credential)
  • Can optionally attach session based policy to further limit permission from the role
  • Optionally use ExternalId - to prevent "confused deputy" (Service is given role A ARN from account A; account B guessed or obtained ARN, then give it to Service, ask Service to assume that role and serve B)
    • ExternalId is generated by the trusted party who is assuming the role
    • When to use:
      • The trusted party also serves others - to prevent the "confused deputy"
      • You are the trusted party - same scenario
    • Provided when assuming role
    • Can be tested in policy: "Condition": {"StringEquals": {"sts:ExternalId": "12345"}}
• AssumeRoleWithWebIdentity (cognito service call, for web federation, unsigned call without AWS credential)
• AssumeRoleWithSAML
• GetFederationToken - through a custom ID broker, IAM / root user can call
• GetSessionToken—Temporary Credentials
  • For use in untrusted Environments (for enhanced security)
  • For use with MFA (to submit MFA code & obtain session token)

Usage:

• When use temporary credentials (key ID + secret key), must with session token (signed, contains session duration etc.)
• Some properties (tags etc.) will pass to the temporary credential
• EC2 - launch with an associated role; tools, CLI, SDK etc. automatically obtain the credential
• SDK, CLI - use STS service calls

Control permission to use STS operations (AssumeRole etc.) to control who can obtain the credential, for how long etc.

Policy JSON Document Structure & Examples

See reference https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_policies.html

Overall

https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_policies_grammar.html

Note: variables from request context (such as ${aws:username}) can be used in the document, for example user id string used in resource path etc.

• Version?
• Id? - optional policy Id
• Statement: [statement array, each include]
  • Sid? - optional statement Id
  • principal?:
    • Principal
      • *
      • {principal map}
        • (principal map entry) ("AWS" | "Federated" | "Service" | "CanonicalUser") : [<principal_id_string>, <principal_id_string>, ...]
    • NotPrincipal (also * or principal map)
  • "Effect" : ("Allow" | "Deny")
  • ("Action" | "NotAction") : ("*" | [<action_string>, <action_string>, ...])
    • Can use, for example, Get* to match multiple actions
  • ("Resource" | "NotResource") : ("*" | [<resource_string>, <resource_string>, ...])
  • "Condition" : { <condition_map> }
    • <condition_type_string> : { <condition_key_string> : <condition_value_list> },

Action

Can use "*" to match more than one actions

"Action": [

"iam:GenerateCredentialReport",

"iam:Get*",

"iam:List*"

],

Condition (Attribute Based Access Control (ABAC) Examples)

The values that can be substituted for policy variables must come from the current request context.

Variables about principals (including tags): https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_policies_variables.html

Global condition keys https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_policies_condition-keys.html

IAM condition keys https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_policies_iam-condition-keys.html

Condition Operators: https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_policies_elements_condition_operators.html

          "Condition": {

             "StringEquals": {

                 "aws:ResourceTag/access-project": "${aws:PrincipalTag/access-project}",

                 "aws:ResourceTag/access-team": "${aws:PrincipalTag/access-team}",

                 "aws:ResourceTag/cost-center": "${aws:PrincipalTag/cost-center}"

             },

             "ForAllValues:StringEquals": {

                 "aws:TagKeys": [

                     "access-project",

                     "access-team",

                     "cost-center",

                     "Name",

                     "OwnedBy"

                 ]

             },

             "StringEqualsIfExists": {

                 "aws:RequestTag/access-project": "${aws:PrincipalTag/access-project}",

                 "aws:RequestTag/access-team": "${aws:PrincipalTag/access-team}",

                 "aws:RequestTag/cost-center": "${aws:PrincipalTag/cost-center}"

             }

         }

Session Tags: Session tags are key-value pair attributes that you pass when you assume an IAM role or federate a user in AWS STS;

When you use temporary credentials to make a request, your principal might include a set of tags. These tags come from: Session Tags, incoming transitive session tags, IAM tags.

Take home - many information can be looked up

See more https://docs.aws.amazon.com/IAM/latest/UserGuide/id_session-tags.html

Across Account Delegation with IAM Roles

Assumption scenario:

• Accounts:
  • Production (the trusting account),
  • Development (trusted account)
• User:
  • in Production (trusting) account, no user needed
  • in Development (trusted) account, "Developers" needs access in Production account, "Testers" should not

Step 1 - Create role in Production (trusting) account

• Role type " Another AWS account"
  • Input account ID of the Development (trusted) account
• Grant access to resources with policy

Step 2 - Grant / deny user in Development (trusted) account privilege to assume role

• Grant / deny user or group with inline policy such as below, where "Resource" is the Arn of the Role created in Production (trusting) account
• Sometimes user may have "Power User" privilege and should NOT have the privilege to assume a role, use Deny

{

  "Version": "2012-10-17",

  "Statement": {

    "Effect": "Allow",

    "Action": "sts:AssumeRole",

    "Resource": "arn:aws:iam::PRODUCTION-ACCOUNT-ID:role/UpdateApp"

  }

}

Step 3 - Switch roles

• Console
• CLI:
  • use profile (--profile)
  • use STS
    • aws sts assume-role --role-arn "arn:aws:iam::999999999999:role/UpdateApp" --role-session-name "David-ProdUpdate"
    • Set three environments from the output: AccessKeyId, SecretAccessKey, SessionToken
• API - uses AssumeRole operation