Disabling permissions for temporary security credentials - AWS Identity and Access Management

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 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. Revoke the role’s temporary security credentials to force all users assuming the role to reauthenticate and request new 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.

Important

For users in IAM Identity Center, see Disable user access in the AWS IAM Identity Center User Guide. You can also Remove user access to cloud applications or custom SAML 2.0 applications in the IAM Identity Center console.

Deny access to all sessions associated with a role

Use this approach when you are concerned about suspicious access by:

  • Principals from another account using cross-account access

  • External user identities with permissions to access AWS resources in your account

  • Users who have been authenticated in a mobile or web application with a web identity provider

This procedure denies permissions to all users that have permissions to assume a role.

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 permissions policy that defines the permissions for the role.

Important

If there's a resource-based policy that allows the principal access, you must also add an explicit deny for that resource. See Deny a session user with resource-based policies for details.

  1. Sign in to the AWS Management Console and open the IAM console.

  2. In the navigation pane, choose the name of the role to edit. You can use the search box to filter the list.

  3. Select the relevant policy.

  4. Choose the Permissions tab.

  5. Choose the JSON tab and update the policy to deny all resources and actions.

    { "Version": "2012-10-17", "Statement": [ { "Effect": "Deny", "Action": "*", "Resource": "*" } ] }
  6. On the Review page, review the policy Summary and then choose Save changes to save your work.

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 session

When you update the roles that are assumable from an IdP with a deny-all policy or delete the role entirely, all users that have access to the role are disrupted. You can deny access based on the Principal element 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.

Tip

You can find the ARNs of federated users using AWS CloudTrail logs. For more information, see How to Easily Identify Your Federated Users by Using AWS CloudTrail.

Deny a user session with condition context keys

You can use condition context keys 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 more information about condition context keys, see AWS global condition context keys.

Note

If there's a resource-based policy that allows the principal access, you must also add an explicit deny statement on the resource-based policy after you complete these steps.

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

aws:PrincipalArn

You can use condition context key aws:PrincipalArn to deny access to a specific principal ARN. You do this by specifying the unique identifier (ID) of the IAM user, role, or federated user the temporary security credentials are associated with in the Condition element of a policy.

  1. In the IAM console navigation pane, choose the name of the role to edit. You can use the search box to filter the list.

  2. Select the relevant policy.

  3. Choose the Permissions tab.

  4. Choose the JSON tab and add a deny statement for the principal ARN as shown in the following example.

    { "Version": "2012-10-17", "Statement": [ { "Effect": "Deny", "Action": "*", "Resource": "*", "Condition": { "ArnEquals": { "aws:PrincipalArn": [ "arn:aws:iam::222222222222:role/ROLENAME", "arn:aws:iam::222222222222:user/USERNAME", "arn:aws:sts::222222222222:federated-user/USERNAME" ] } } } ] }
  5. On the Review page, review the policy Summary and then choose Save changes to save your work.

aws:userid

You can use condition context key aws:userid 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 federated user 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.

  • AIDAXUSER1 represents the unique identifier for an IAM user. Specifying the unique identifier of an IAM user as a value for context key aws:userid will deny all sessions associated with the IAM user.

  • AROAXROLE1 represents the unique identifier for an IAM role. Specifying the unique identifier of an IAM role as a value for context key aws:userid will deny all sessions associated with the role.

  • AROAXROLE2 represents the unique identifier for an assumed-role session. In the caller-specified-role-session-name portion of the assumed-role unique identifier you can specify a role session name or a wildcard character if the StringLike condition operator is used. If you specify the role session name, it will deny the named role session without affecting the permissions of the role that created the credentials. If you specify a wildcard for the role session name, it will deny all sessions associated with the role.

  • account-id:<federated-user-caller-specified-name> represents the unique identifier for a federated user session. A federated user is created by an IAM user calling the GetFederationToken API. If you specify the unique identifier for a federated user, it will deny the named federated user session without affecting the permissions of the role that created the credentials.

{ "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, see Unique identifiers.

Deny a session user with resource-based policies

If the principal ARN is also included in any resource-based policies, you must also revoke access based on the specific user’s principalId or sourceIdentity values in the Principal element of a resource-based policy. If you only update the permissions policy for the role, the user can still perform actions allowed in the resource-based policy.

  1. Refer to AWS services that work with IAM to see if the service supports resource-based policies.

  2. Sign in to the AWS Management Console and open the console for the service. Each service has a different location in the console for attaching policies.

  3. Edit the policy statement to specify the identifying information of the credential:

    1. In Principal, enter the ARN of the credential to deny.

    2. In Effect, enter “Deny.”

    3. In Action, enter the service namespace and the name of the action to deny. To deny all actions, use the wildcard (*) character. For example: “s3:*.”

    4. In Resource, enter the ARN of the target resource. For example: "arn:aws:s3:::EXAMPLE-BUCKET."

    { "Version": "2012-10-17", "Statement": { "Principal": [ "arn:aws:iam::222222222222:role/ROLENAME", "arn:aws:iam::222222222222:user/USERNAME", "arn:aws:sts::222222222222:federated-user/USERNAME" ], "Effect": "Deny", "Action": "s3:*", "Resource": "arn:aws:s3:::EXAMPLE-BUCKET" } }
  4. Save your work.