Disabling permissions for temporary security credentials

Temporary security credentials are valid until they expire. These credentials are valid for the specified duration, from 900 seconds (15 minutes) up to a maximum of 129,600 seconds (36 hours). The default session duration is 43,200 seconds (12 hours). You can revoke these credentials, but you must also change permissions for the IAM user or role to stop the use of compromised credentials for malicious account activity. Permissions assigned to temporary security credentials are evaluated each time they are used to make an AWS request. Once you remove all permissions from the credentials, AWS requests that use them fail.

It might take a few minutes for policy updates to take effect. For IAM role sessions, you can revoke the role’s temporary security credentials to force all users assuming the role to reauthenticate and request new credentials. For more information, see Revoke the role’s temporary security credentials.

You cannot change the permissions for an AWS account root user. Likewise, you cannot change the permissions for the temporary security credentials that were created by calling GetFederationToken or GetSessionToken while signed in as the root user. For this reason, we recommend that you do not call GetFederationToken or GetSessionToken as a root user.

For procedures on how to change the permissions for an IAM user, see Change permissions for an IAM user.

For procedures on how to change the permissions for an IAM role, see Update permissions for a role.

Deny access to all IAM role sessions associated with a role

This procedure denies permissions to all IAM role sessions associated with a role. Use this approach when you are concerned about suspicious access by:

To change or remove the permissions assigned to the temporary security credentials obtained by calling AssumeRole, AssumeRoleWithSAML, or AssumeRoleWithWebIdentity, GetFederationToken, or GetSessionToken, you can edit or delete the identity-based policy that defines the permissions for the role.

When you update the policy, the changes affect the permissions of all temporary security credentials associated with the role, including credentials that were issued before you changed the role's permissions policy.

After you update the policy, you can revoke the role’s temporary security credentials to immediately revoke all permissions to the role's issued credentials.

Deny access to a specific IAM role session

When you update IAM roles with a deny-all policy or delete the role entirely, all users that have access to the role are disrupted. You can deny access without impacting the permissions of all other sessions associated with the role.

The Principal can be denied permissions using condition context keys or resource-based policies.

Deny access to temporary security credentials sessions with condition context keys

You can use condition context keys in identity-based policies in situations where you want to deny access to specific temporary security credential sessions without affecting the permissions of the IAM user or role that created the credentials. For IAM roles, after you update the policy, you can also revoke the role’s temporary security credentials sessions to immediately revoke all issued credentials.

For more information about condition context keys, see AWS global condition context keys.

aws:PrincipalArn

You can use condition context key aws:PrincipalArn in an identity-based policy to deny access to a specific principal by their Amazon Resource Name (ARN). You do this by specifying the ARN of the IAM user, role, or AWS STS federated user session the temporary security credentials are associated with in the Condition element of a policy.

aws:SourceIdentity

You can use condition context key aws:SourceIdentity in an identity-based policy to deny access to a specific source identity associated with an IAM role session. This applies as long as the role session was issued by setting the SourceIdentity request parameter when the principal assumed a role using any AWS STS assume-role* CLI commands, or AWS STS AssumeRole* API operations. You do this by specifying the source identity that the temporary security credentials are associated with in the Condition element of a policy.

Unlike context key sts:RoleSessionName, after the source identity is set, the value cannot be changed. The aws:SourceIdentity key is present in the request context for all actions taken by the role. The source identity persists into subsequent role sessions when you use the session credentials to assume another role. Assuming one role from another is called role chaining.

The following policy shows an example of how you can deny access to temporary security credential sessions using condition context key aws:SourceIdentity. If you specify the source identity associated with a role session, it will deny role sessions with the named source identity without affecting the permissions of the role that created the credentials. For this example, the source identity set by the principal when the role session was issued is nikki_wolf@example.com. Any request made by a role session with the source identity nikki_wolf@example.com will be denied because the source identity is included in the policy condition and the policy Effect is set to Deny.

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "Deny",
      "Action": "*",
      "Resource": "*",
      "Condition": {
        "StringLike": {
          "aws:SourceIdentity": [
            "nikki_wolf@example.com",
            "<source identity value>"
          ]
        }
      }
    }
  ]
}

aws:userid

You can use condition context key aws:userid in an identity-based policy to deny access to all or specific temporary security credential sessions associated with the IAM user or role. You do this by specifying the unique identifier (ID) of the IAM user, role, or AWS STS federated user session the temporary security credentials are associated with in the Condition element of a policy.

The following policy shows an example of how you can deny access to temporary security credential sessions using condition context key aws:userid.

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "Deny",
      "Action": "*",
      "Resource": "*",
      "Condition": {
        "StringLike": {
          "aws:userId": [
            "AIDAXUSER1",
            "AROAXROLE1:*",
            "AROAXROLE2:<caller-specified-role-session-name>",
            "account-id:<federated-user-caller-specified-name>"
          ]
        }
      }
    }
  ]
}

For specific examples of principal key values, see Principal key values. For information about IAM unique identifiers and how to get them, see Unique identifiers.

Deny access to a specific principal with resource-based policies

To restrict access to a specific principal with a resource-based policy, you can use condition context keys aws:PrincipalArn or aws:SourceIdentity in the Condition element. A resource-based policy is a permission policy attached to a resource and controls who can access the resource and what actions they can perform on it.

When you use the aws:PrincipalARN context key, specify the ARN of the IAM user, role, or AWS STS federated user session associated with the temporary security credentials in the Condition element of a policy. The following example policy demonstrates how to use the aws:PrincipalARN context key in a resource-based policy:

{
  "Version": "2012-10-17",
  "Statement": {
    "Principal": [
      "*"
    ],
    "Effect": "Deny",
    "Action": "s3:*",
    "Resource": "arn:aws:s3:::amzn-s3-demo-bucket",
    "Condition": {
      "ArnEquals": {
        "aws:PrincipalArn": [
          "arn:aws:iam::222222222222:role/ROLENAME",
          "arn:aws:iam::222222222222:user/USERNAME",
          "arn:aws:sts::222222222222:federated-user/USERNAME"
        ]
      }
    }
  }
}

When you use the aws:SourceIdentity context key, specify the source identity value associated with the role's temporary security credentials in the Condition element of a policy. This applies as long as the role session was issued by setting the SourceIdentity request parameter when the principal assumed a role using any AWS STS assume-role* CLI commands, or AWS STS AssumeRole* API operations. The following example demonstrates how to use the aws:SourceIdentity context key in a resource-based policy:

{
  "Version": "2012-10-17",
  "Statement": {
    "Principal": [
      "*"
    ],
    "Effect": "Deny",
    "Action": "s3:*",
    "Resource": "arn:aws:s3:::amzn-s3-demo-bucket",
    "Condition": {
      "StringLike": {
        "aws:SourceIdentity": [
          "nikki_wolf@example.com",
          "<source identity value>"
        ]
      }
    }
  }
}

If you only update the identity-based policy for a principal, they can still perform actions allowed in the resource-based policy, except when those actions are explicitly denied in the identity-based policy.