Disabling Permissions for Temporary Security Credentials
Temporary security credentials are valid until they expire. You can specify the duration_seconds parameter to set the validity period of temporary security credentials. The value range is from 900 seconds (15 minutes) up to the maximum session duration of a trust agency. If this parameter is not specified, the default value is 3600 seconds (1 hour). You can adjust the trust policy of a trust agency to disable temporary security credentials, but you also need to change the identity permissions for the trust agency to prevent the use of compromised security credentials for malicious account activity. Each time temporary security credentials are used to send Huawei Cloud requests, the system evaluates the permissions assigned to them. Once you remove all permissions from the trust agency, Huawei Cloud requests using these temporary security credentials will fail. Policy updates may take several minutes to be applied. For details about the cloud services whose trust agencies support permission revocation, see Cloud Services for Using Identity Policies and Trust Agencies.
Denying Access to All Temporary Security Credentials
This method blocks all requests signed with temporary security credentials. Temporary security credentials are generated by the AssumeAgency API for trust agency assuming. Edit or delete the identity policy attached to the trust agency. If you choose to update the policy, update it as follows. The changes affect the permissions of all temporary security credentials associated with the trust agency prior to the change, including the temporary security credentials that have been issued, are being generated, or to be generated.
- If there is a resource policy that allows the principal access, you must adjust the resource policy by adding an explicit deny for that resource.
- Only the permissions of temporary security credentials for some cloud services can be revoked. For details, see Cloud Services for Using Identity Policies and Trust Agencies.
{
"Version": "5.0",
"Statement": [{
"Effect": "Deny",
"Action": [
"*"
],
"Resource": [
"*"
]
}]
}
Denying Access to Specific Temporary Security Credentials
If you want to deny access to specific temporary security credentials without affecting access to other temporary security credentials, you can use condition keys.
- If there is a resource policy that allows the principal access, you must adjust the resource policy by adding an explicit deny for that resource.
- Only the permissions of temporary security credentials for some cloud services can be revoked. For details, see Cloud Services for Using Identity Policies and Trust Agencies.
Denying Access to Temporary Security Credentials Generated Before a Specific Time
You can also specify the value of the g:TokenIssueTime key in the "Condition" element of a policy to deny the access of temporary security credentials generated before a specific time. When the value of g:TokenIssueTime key is earlier than the specified date and time, the policy denies all permissions. The g:TokenIssueTime value refers to the time when the temporary security credentials are issued. The g:TokenIssueTime value only exists in requests signed using the temporary security credentials, so the Deny statement in this identity policy does not affect requests signed using the permanent access keys.
By attaching this identity policy to a trust agency, you can deny requests signed by temporary security credentials generated before a specific time. Temporary security credentials are generated by the AssumeAgency API for trust agency assuming.
{
"Version": "5.0",
"Statement": [{
"Effect": "Deny",
"Action": [
"*"
],
"Resource": [
"*"
],
"Condition": {
"DateLessThan": {
"g:TokenIssueTime": "2024-03-01T12:00:00Z"
}
}
}]
}
Denying Access to Temporary Security Credentials Created by a Specific Principal
You can also specify the value of the g:PrincipalUrn key in the "Condition" element of a policy to deny the access of temporary security credentials generated by a specific principal. Currently, temporary security credentials can be obtained only by assuming an agency or trust agency. The temporary security credentials obtained in this way are also called assumed-agency/trust agency sessions. The URN of an assumed-agency/trust agency session is in the format of sts::<account-id>:assumed-agency:<agency-name>/<session-name>. If you assume an agency or trust agency through the IAM console, the session-name of the session's URN is fixed at null. If you assume an agency or trust agency via the AssumeAgency API, session-name can be specified by you.
{
"Version": "5.0",
"Statement": [{
"Effect": "Deny",
"Action": [
"*"
],
"Condition": {
"StringEquals": {
"g:PrincipalUrn": [
"sts::account-id:assumed-agency:agency-name/null"
]
}
}
}]
}
{
"Version": "5.0",
"Statement": [{
"Effect": "Deny",
"Action": [
"*"
],
"Condition": {
"StringEquals": {
"g:PrincipalUrn": [
"sts::account-id:assumed-agency:agency-name/session-name"
]
}
}
}]
}
Denying Access to Temporary Security Credentials Created for a Specific Source Identity
You can also specify the value of the g:SourceIdentity key in the "Condition" element of a policy to deny the access of temporary security credentials of a specific source identity. You can use this method to revoke the access permission of temporary security credentials created for a specific source identity. Once the source identity information is set, the value of the g:SourceIdentity key is used in all requests of the assumed-trust agency session and persists. You cannot change the value even if you use the agency chain to switch to other trust agencies. You cannot set the source identity information if trust agencies are assumed on the IAM console. Therefore, you cannot reject requests from the console after a trust agency is assumed.
{
"Version": "5.0",
"Statement": [{
"Effect": "Deny",
"Action": [
"*"
],
"Condition": {
"StringEquals": {
"g:SourceIdentity": [
"123"
]
}
}
}]
}
Feedback
Was this page helpful?
Provide feedbackThank you very much for your feedback. We will continue working to improve the documentation.See the reply and handling status in My Cloud VOC.
For any further questions, feel free to contact us through the chatbot.
Chatbot