Reasonable distribution of keys #

• **Do not create a new master account key: **The master account key has all the permissions of the account. Once leaked, it may affect the security of cloud resources in the entire account. Therefore, it is strongly recommended not to use the master account key for program development.

• **Use child user keys with minimal permissions: **It is recommended to create a separate IAM user (also known as a "workload user" or "service account") for the application, assign the minimum permissions required to that IAM user, and use this user's key for program development.

• **Strict division of program users and personnel users: **Strict division of personnel users and program users (workload users) is recommended. Avoid people users who can create keys or program users who can be logged in. This can avoid key leakage or misoperation caused by improper management of operation and maintenance personnel, and also avoid the user key being cleared with the user when personnel transfer or leave.

periodic key rotation #

Using a fixed key for a long time increases the risk of key leakage. It is recommended to rotate the key regularly, and the maximum rotation time is recommended to be no more than 90 days.

• It is recommended to use the Volcano Engine key management service to manage long-term AK/SK and implement automatic rotation. Refer to KMS IAM credential management instructions .
• If you need to rotate keys manually, it is recommended to create a new key on the console and replace the old key in the configuration, and then disable the old key. When disabling a key, you can check the last access time of the key to ensure that the old key has been completely discontinued. It is recommended that the key be left for a certain period of time before being deleted to reduce the risk.

When the key has not been rotated for more than 90 days, the system will give a prompt, suggesting that you process the key in time. It is recommended to disable and delete keys that have not been used for a long time.

Keep the key safe #

• Never write an API key into code or store it in a code repository to prevent the key from being shared with the code.

• Avoid placing API keys in a public environment (e.g. uploading to GitHub).

• Avoid placing the API key in a client side environment or cloud computing resource. For such scenarios, please refer to the Temporary Security Certificate (STS) scheme at the end of this article.

When you need to initiate access from Volcano Engine compute resources or other untrusted environments, the following scenarios are recommended: