What should I do if the Alibaba Cloud AccessKey leaks? I'll teach you how to configure RAM role permissions.

Many technical teams have encountered such "midnight alarm": suddenly they received a fatal serial call or SMS notification from ariyun, "your account has detected the risk of AccessKey leakage, and some resources are being called abnormally at high frequency......"

Log in to the console and see that the bill has exploded, and the server has even been created by hackers to mine in batches.

The root cause of all this is often because the diagram is easy, hard-coded directly in code, configuration files, or GitHub public repositories with the highest permissions.

Primary account AccessKey(AK/SK)

. The AK of the main account is like the master key of your home. Once leaked, the entire cloud assets are completely open to hackers.

Today, we will not talk about empty theories or nonsense. Direct hand to hand take you to establish two lines of defense:

First, emergency hemostasis 5 minutes after AK leak; Second, how to use RAM role (Role) to completely eradicate the hidden danger of hard-coded AK.

The first stage: emergency hemostasis! AccessKey leaked 5-minute emergency stream

If you find or suspect that AK has been leaked, don't hesitate to perform the following operations immediately. One more minute of delay is a real loss of money.

Step 1: Disable or delete the AK involved in the whole network

Log in to the Alibaba Cloud console immediately, click the avatar $\rightarrow $in the upper right corner, and select AccessKey Management ".

Find the AccessKey prompted to leak (whether it is the main account or the sub-account).

Click "Disable" first ". At this time, all external network requests using the AK will report an error 403 instantly.

After confirming that the core production business is not affected, click "Delete" decisively ".

Step 2: Check the "back door" left by hackers"

After hackers get AK, the first thing is often to use automated scripts to create resources in batches.

Go to the ECS instance list and lightweight application server list, switch between regions (Beijing, Shanghai, Shenzhen, Hong Kong, the United States, etc.) to see if there are any inexplicable servers. If so, release them immediately.

To operate the audit (ActionTrail) console, query which API the AK has called in the past 24 hours, and find out the resources that the hacker has manipulated.

Phase II: A permanent solution-standardize the configuration of RAM roles and minimum permissions.

After AK is deleted, the old project code is directly collapsed because they need permission to read and write OSS or call other cloud services.

We can't build a new main account AK into it. The correct approach is:

Use the RAM role to allow programs running on Alibaba Cloud to obtain temporary permissions automatically and without keys.

In the following, we take "Enable programs on the cloud server ECS to securely read and write OSS buckets" as an example for actual combat configuration.

Step 1: Create a RAM role (create an "identity" out of thin air"

)

Search for RAM Access Control in the console ".

On the left menu, click Roles $\rightarrow $Create Role ".

Select Alibaba Cloud Service as the trusted entity type and click Next.

Role Type: Select Normal Service Role ".

Role Name: An easy-to-understand name, such as ECS-OSS-Reader-Role.

Select trusted service: Because we want to attach this role to the cloud server, we select "cloud server" (ECS) here.

Click OK.

Step 2: Exact Authorization (No Extra Permissions)

The role you just created is a blank sheet of paper with no permissions. We need to license it according to the "principle of least privilege.

Find the role you just created in the ECS-OSS-Reader-Role list and click Add Permissions on the right ".

Authorization Scope: Select the entire Alibaba Cloud account (default).

Select policy: If you only need to read OSS: search and check AliyunOSSReadOnlyAccess (read-only access OSS). If you need to read and write OSS: Search and select AliyunOSSFullAccess (Manage OSS).

Click OK.

Step 3: Bind the role to the ECS cloud server

This step is very critical, it is equivalent to the "license" posted to a specific server's forehead.

Go to the "Cloud Server ECS" console and find the instance running your code.

On the right, click More $\rightarrow $Instance Settings $\rightarrow $Grant/Retract RAM Roles ".

In the drop-down menu, select the ECS-OSS-Reader-Role you just created.

Click OK.

The third stage: code transformation-a complete farewell to hard-coded AK

Now, your server has a legal identity. We're going to modify the code of the project, put the damn lines

accessKeyId

and

accessKeySecret

Completely deleted.

The Alibaba Cloud SDK has

Automatic Voucher Rotation Injection

Function. When the code is run on an ECS instance bound with a RAM role, the SDK accesses a special local metadata address inside the server

http

://100.100.100.200/latest/meta-data/

Fully automatic acquisition of a

Temporary Token that automatically expires every few hours

.

Even if a hacker sneaks into the server and steals the Token, it will automatically expire after a few hours and cannot be used as a persistent backdoor.

Take Java SDK access to OSS as an example:

Old Code (Extremely Dangerous❌):

Java

// It is forbidden to write like this! Once the code is on

To the public code hosting platform, the whole family bucket instantly ascended to heaven.

String accessKeyId = "LTAI5tXXXXXX ";

String accessKeySecret = "Pn7yXXXXXX ";

OSS ossClient = new OSSClientBuilder().build(endpoint, accessKeyId, accessKeySecret);

New code (cloud native security strategy recommended):

Java

import com.aliyun.oss.OSS;

import com.aliyun.oss.OSSClientBuilder;

import com.aliyun.credentials.Client;

import com.aliyun.credentials.models.Config;

// No plaintext key is required at all!

Config credentialConfig = new Config();

credentialConfig.setType("ecs_ram_role"); // Specify the credential type of the RAM role bound to ECS

// If left blank, the SDK will automatically search for the role name bound to the current server.

// credentialConfig.setRoleName("ECS-OSS-Reader-Role");

Client credentialClient = new Client(credentialConfig);

// Use the temporary credential to build the OSS client.

OSS ossClient = new OSSClientBuilder().build(endpoint, credentialClient);

The ultimate line of defense: how to prevent the next leak?

Absolutely, absolutely, absolutely do not submit configuration files containing clear AK in any public code repository (such as GitHub, Gitee). Even if it is a private warehouse, many leaks are due to employees mistakenly changing the private warehouse to public.

Make good use of. gitignore. When the project is initialized, immediately add application-prod.yml, config.json and other configuration files that contain sensitive information to the ignore list.

What happened to local development? If the local computer really needs AK debugging, configure AK into the environment variable of your computer system (via export ALIBABA_CLOUD_ACCESS_KEY_ID = "xxx"), in the code

Read through System.getenv(). The code is always clean.

There are no small matters when it comes to safety. Tonight, check the projects you maintain and kill all the hard-coded main accounts AK!