Abstract:

In the article “How to store Your configuration securely on Alicloud”, we introduced how to store and encrypt your sensitive configuration through ACM. The purpose of this is twofold:

  • There is no need to persist any sensitive data information (such as database connection strings, etc.) in the application or in the corresponding production environment container or system to prevent sensitive information from being leaked in the production environment or during development.
  • Configuration data is stored in the configuration center and encrypted throughout the process to further ensure data security.

However, in the previous article, one of the remaining problems is how to store sensitive information for accessing ACM configuration itself. For example, how to store the AccessKey ID(AK) or Secret AccessKey(SK) required for accessing ACM itself, which is the so-called “last kilometer” problem of sensitive configuration. The recent ACM release of version 4.4 includes an important feature “ACM SDK support for ECS instance RAM roles “, which makes the above problems completely solved. So let’s see what ACM does.

To illustrate ACM’s approach, this paper will be divided into two parts:

  • The first part introduces the principle of “ECS instance RAM role “, so that readers can understand how to call the SDK of Ali Cloud without entering AK/SK.
  • The second part, through the introduction of ACM support “ECS instance RAM role “method and usage scenarios, let the reader further understand how to use ACM completely in the code to remove sensitive configuration and AK/SK.

“ECS instance RAM role “principle

First, let’s look at the principle behind the so-called “ECS instance RAM role.” ECS instance RAM role is one of ali Cloud RAM roles, which allows ECS instances to play roles with certain permissions, thus granting certain access rights to the instances. Instance RAM roles allow users to access the apis of other cloud products within an ECS instance based on STS (Security Token Service) tokens that will be updated periodically through a RAM role associated with the instance. In this way, on the one hand, Access Key security can be guaranteed, on the other hand, Access can be achieved with the help of RAM fine control and management.

The introduction of ECS instance RAM role is mainly to solve the AK/SK storage problem of sensitive information, which is consistent with the “last road” problem of ACM sensitive configuration information storage. Let’s take a look at how this works by using the ECS instance RAM role, as shown below:



As shown in the figure above, ECS instance roles are used in five steps.

1. Cloud account (root) creates an ECS instance ram-role in RAM and grants appropriate Policy permissions to the Role. When starting an ECS instance, you can configure the RAM-role created in the previous step to use it

(Note: Please refer to Using instance RAM Role through console or Using Instance RAM Role through API for details of the above two steps.)

After the above two steps, the ECS service creates an instance:

  • Sumerole is called to access STS to request STS Token for the configured RAM role.
  • The STS service verifies the ECS service identity and the authorization type of the role. After the authentication succeeds, the STS Token is issued. Otherwise, the request is rejected.
  • After the STS Token is obtained, the ECS provides access to the application in the instance through the Metadata service (HTTP access address: 100.100.100.200).
  • The STS Token expiration time is usually 6 hours. The ECS service automatically maintains STS Token refresh before expiration.

3. The application obtains the STS Token

An application in an ECS instance needs to access the ECS Metadata service to obtain the corresponding STS Token. For example, running a command in Linux:

$curl http://100.100.100.200/latest/meta-data/ram/security-credentials/ < roleName >

You can obtain metadata information such as STS Token and expiration time.

4. Invoke the cloud service API using the STS Token

This is a crucial step. If the user’s application uses the Ali Cloud SDK and the SDK already supports the STS Token of instance RAM role from the ECS Metadata service, then the developer does not need to configure any AK sensitive information in the SDK. Detailed use method, please refer to the ali cloud InstanceProfileCredentialsProvider SDK support.

5. The STS Token can normally access the cloud service API within the validity period and permission scope

If the STS Token expires, you need to retrieve the STS Token from the ECS Metadata service. If STS Token permissions are insufficient, then you need to ask the administrator to add sufficient permissions to the instance RAM role. When the privileges of the instance RAM role are updated, the STS Token permission takes effect immediately and the user does not need to restart the ECS instance.

ACM supports methods and usage scenarios of ECS instance RAM roles

ACM supports the “ECS instance RAM role “in the same way as the appeal architecture. To use this solution, users need to perform “Step 1- Create an ECS instance ram-role in RAM” and “Step 2- Start the ECS instance and configure to use the RAM-role created in the previous step”. As part of the SDK of Alicloud, the ACM SDK itself helps users complete steps 3, 4, and 5 by default. Users only need to invoke the ACM SDK to focus on service-sensitive configuration.

To further understand how this works, imagine a scenario where a user needs to access a database through a database connection string (containing a password). In a normal scenario, users would set this sensitive information in a configuration file and publish the configuration to the production environment. After ACM is used, users no longer need to store any sensitive information in applications. Instead, the programmer only needs to do two things when connecting related services,

  1. Obtain sensitive service configuration information, such as database connection strings, based on the ACM SDK.

  2. Invoke the corresponding service based on the obtained sensitive configuration information.

    • Note: The above two steps do not require the application to set any AK/SK information.

The following figure shows how to obtain the configuration using the ACM SDK based on the “ECS Instance RAM Role “.



As shown in the figure, in the second key step of ACM SDK to obtain configuration from ACM service, ACM SDK will authenticate ACM service based on STS Token temporary authentication information of “ECS instance RAM role “in ECS MetaService by default, without any external AK or SK input. Thus bypassing the user manual input AK, SK requirements.

As shown in the figure, the application scenario of this method includes any data service connection string carrying sensitive information, temporary login information of the server, license information of third-party software, etc.

conclusion

The above article Outlines how ACM is used to access sensitive program information. By doing so, applications in security will have the following advantages:

  • Sensitive configuration information is removed from the program and saved in ACM, ensuring that sensitive information is not leaked in development and production environments to the greatest extent.
  • In addition, applications use the temporary authentication information of the ECS instance RAM role to access ACM, and do not persist any permanent AK/SK information in the production environment, eliminating security problems caused by permanent AK/SK leakage.

In the following sections, we will provide a code example to further explain how to use ACM to store sensitive configurations.

The original link