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 Amazon request. Once you remove all permissions from the credentials, Amazon 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 Amazon Web Services 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 Amazon 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.
Topics
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 Amazon 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.
-
Sign in to the Amazon Web Services Management Console and open the IAM console.
-
In the navigation pane, choose the name of the role to edit. You can use the search box to filter the list.
-
Select the relevant policy.
-
Choose the Permissions tab.
-
Choose the JSON tab and update the policy to deny all resources and actions.
{ "Version": "2012-10-17", "Statement": [ { "Effect": "Deny", "Action": "*", "Resource": "*" } ] }
-
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 Amazon CloudTrail logs. For more information, see
How to
Easily Identify Your Federated Users by Using Amazon 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 Amazon 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.
-
In the IAM console navigation pane, choose the name of the role to edit. You can use the search box to filter the list.
-
Select the relevant policy.
-
Choose the Permissions tab.
-
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
" ] } } } ] } -
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 keyaws: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 keyaws: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.
-
Refer to Amazon services that work with IAM to see if the service supports resource-based policies.
-
Sign in to the Amazon Web Services Management Console and open the console for the service. Each service has a different location in the console for attaching policies.
-
Edit the policy statement to specify the identifying information of the credential:
-
In
Principal
, enter the ARN of the credential to deny. -
In
Effect
, enter “Deny.” -
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:*.” -
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
" } } -
-
Save your work.