This topic answers frequently asked questions about creating, managing, and securing AccessKey pairs.
What is an AccessKey pair?
An AccessKey pair is a long-term security credential used to authenticate programmatic requests to Alibaba Cloud APIs. It consists of an AccessKey ID and an AccessKey secret.
AccessKey ID: The unique public identifier for the AccessKey pair.
AccessKey secret: A secret key used to calculate the digital signature for an API request. This signature verifies the request's authenticity and integrity. You must keep your AccessKey secret strictly confidential.
To reduce the risk of leaks, an AccessKey secret is available for you to view or download only at the time of its creation. You cannot retrieve it later. Make sure to store it securely.
How to use an AccessKey pair
AccessKey pairs are intended only for programmatic access to Alibaba Cloud services through tools such as the command-line interface (CLI), software development kits (SDKs), or Terraform. You cannot use an AccessKey pair to log on to the Alibaba Cloud console.
As a best practice, you should not embed AccessKey pairs directly in your applications. Instead, we recommend using temporary security credentials (STS tokens) that are generated by assuming a RAM role. This approach reduces the risk associated with a compromised credential. For specific use cases, see When do I use RAM?
If your use case requires a AccessKey pair, see Best practices for identity and access management.
How an AccessKey pair works
RAM generates the AccessKey ID and AccessKey secret using a specific algorithm. These credentials are encrypted during both storage and transmission.
When an application makes a request, it uses the AccessKey secret to calculate a digital signature and includes the signature in the request. When Alibaba Cloud receives the request, it uses the AccessKey ID to look up the secret and validates the signature. This process verifies the sender's identity and the request's integrity. For more information about the specific signature mechanism that Alibaba Cloud uses, see Request syntax and signature method V3.
What types of AccessKey pairs does Alibaba Cloud provide?
Alibaba Cloud account AccessKey pair (Not recommended)
This type of AccessKey pair belongs to an Alibaba Cloud account. It has full permissions to all resources in the account. A compromised AccessKey pair poses an extremely high security risk. We strongly recommend that you do not create or use a Alibaba Cloud account AccessKey pair.
RAM user AccessKey pair (Recommended)
This type of AccessKey pair belongs to a RAM user. It has only the permissions that are granted to that user, which allows you to follow the principle of least privilege. As a best practice, create a unique RAM user and AccessKey pair for each application. This reduces the risk of exposure that can result from sharing credentials.
What information can I view about an AccessKey pair?
You can view an AccessKey pair's metadata, including its AccessKey ID, status, creation time, and last-used information.
Can I view an AccessKey ID after it is created?
Yes, you can.
Can I view an AccessKey secret after it is created?
No, you cannot. For security reasons, the AccessKey secret is available for you to view or download only at the time of its creation. If you lose an AccessKey secret, you cannot retrieve it. Instead, you must create a new AccessKey pair.
How do I check whether an AccessKey pair is in use?
You can check the last-used time for an AccessKey pair in the console or by calling the API.
When logged on by using an Alibaba Cloud account or a RAM user, you can view the last-used time for your own AccessKey pairs.
When logged on as a RAM administrator, you can view the last-used time for the AccessKey pairs of any RAM user in your account. For more information, see View the information about AccessKey pairs of a RAM user.
GetAccessKeyLastUsed API operation
You can call this operation to programmatically retrieve the last-used time for an AccessKey pair.
Can I change an AccessKey ID?
No. AccessKey IDs are immutable.
Can I restore an AccessKey pair after I delete it?
Yes, for RAM users. When you delete a RAM user's AccessKey pair, it is moved to a recycle bin.
AccessKey pairs in the recycle bin are retained for 30 days before they are permanently purged. During this period, you can restore them. Once a AccessKey pair is purged, it cannot be recovered.
For more information, see Delete an AccessKey pair for a RAM user.
If you delete an AccessKey pair that is in use, the associated application will lose access to Alibaba Cloud resources.
What do I do if an AccessKey pair is leaked?
For more information, see Solutions to AccessKey pair leaks.
How do I find the account that an AccessKey pair belongs to?
For security reasons, Alibaba Cloud does not provide a public service to identify the owner of an AccessKey ID.
If you need to identify the owner of an AccessKey ID within your organization, you can use one of the following methods:
In the RAM console, go to the Users page and search for the AccessKey ID. If you manage multiple Alibaba Cloud accounts, you must perform this search in each account.
If your organization uses Resource Directory, you can enable a multi-account trail in ActionTrail. You can then query the aggregated audit logs for the AccessKey ID to find the owner's account.
Why am I getting a "There is a risk of leakage of this AccessKey" error?
This error indicates that Alibaba Cloud has detected a potential leak of the AccessKey pair and has placed it under restrictive protection. For more information about how to resolve this, see Restrictive protection of AccessKey pairs.
Why is my API call being denied by a network ACL policy?
If an API call is made from an IP address that is not allowed by an active network ACL policy, the call is denied. You might receive one of the following error messages:
Message: The specified parameter "AccessKeyId.AccessPolicyDenied" is not valid.Message: code: 400, Specified access key denied due to access policy. Solution
To resolve the issue, you must identify the correct source IP address and add it to the appropriate policy.
Check whether an AccessKey pair-level policy is configured for the affected AccessKey pair.
If a policy is present, add the required source IP address to it.
If no AccessKey pair-level policies exist, proceed to the next step.
Add the source IP address to the account-level policy.
If API calls are still denied, verify that the IP address you added is correct and matches the actual source IP address of the client making the call.
To find the correct source IP address, you can use ActionTrail to review successful API calls that were made before the policy was enabled. For more information, see the "Review historical API call data in ActionTrail" section in this topic.