Terraform:Automation scenarios - AccessKey pair management solution in multi-account automation scenarios

You can refer to the following transcript:

Welcome back to Auto Talk, the Alibaba Cloud Open Platform Automation Series. I am Yaofang, a solutions architect from the Open Platform team. In this episode, I will share with you an identity management solution for multi-account automation scenarios.

Have you ever tried using code to manage Alibaba Cloud resources? If we write an application or use tools like Terraform for automation, we perform three steps. First, your application needs an identity, meaning you must have an AccessKey pair to interact with Alibaba Cloud APIs. Second, you need an account because all resources reside within an account. Third, you call Alibaba Cloud APIs to create resources such as ECS instances or OSS buckets.

When we talk about the identity of an application, we are referring to the authentication mechanism used by our application to call APIs. Alibaba Cloud provides two methods for authentication. The first method uses fixed credentials called AccessKey pairs, and the other method uses temporary credentials, known as STS tokens. Whether the application uses AccessKey pairs or STS tokens, there are some common risks. For example, some customers may use their Alibaba Cloud accounts to call APIs, which carries a very high risk.

If the AccessKey pair of an Alibaba Cloud account is leaked, the cost of mitigating the damage can be extremely high. Alternatively, some users might hardcode the AccessKey pair directly into their code. If the AccessKey pair is leaked, it could pose a significant risk to the account.

Given these risks, we have established some best practices, which can be summarized into two key points. The first is to minimize the duration of exposure. What does this mean? For instance, if we use a fixed credential like an AccessKey pair, the credential may have a long validity period unless rotated regularly. A developer might use the same AccessKey pair for one year, two years, or even ten years, right? This extended duration increases the risk. However, if we implement policies such as regular rotation — say every six months — we can limit the validity period of an AccessKey pair. Alternatively, we can use temporary tokens, which inherently have shorter lifespans.

The second point is to minimize the scope of exposure. For example, in testing and production environments, we can use different credentials instead of a single credential across all environments. Some users might even use one AccessKey pair to manage all their applications. Imagine the impact if that AccessKey pair were leaked. All systems would be affected. As mentioned earlier, temporary tokens also have best practices in the cloud. For instance, if we use ECS and deploy our application on an ECS instance, ECS offers a feature called instance roles. You can think of it as assigning a role to the ECS instance, allowing it to operate certain cloud resources. This way, the application does not need to be aware of the AccessKey pair. By simply deploying the code on this ECS instance, the application gains the necessary permissions. There is no risk of AccessKey pair leakage since the application is not exposed to the AccessKey pair. All credentials are managed within the ECS instance. This is one approach. Many of our customers operate in multi-account environments. I'm not sure if you're familiar with or have used our multi-account management service, but Resource Directory functions as an account tree. For example, we might have multiple businesses, such as Business A, Business B, and Business C, each with its own account, such as A1, B1, and C1. If we want to perform some automated operations, we might create a new cloud account, such as Operations Account C. In this account, we run scripts or pipelines. For instance, we might set up Jenkins or use Alibaba Cloud DevOps. When running pipelines, we need to operate resources in Accounts A1 and B1, meaning we need the identities and permissions of these accounts. If A1 has an AccessKey pair and B1 has an AccessKey pair you can imagine the high risk of AccessKey pair leakage. Moreover, managing the AccessKey pair for each account increases operational complexity and costs.

If you see a diagram like this and your enterprise operates in a multi-account scenario, I strongly recommend using this solution. I strongly recommend using this solution. Let me introduce this solution. We can create an ECS instance in the operations account and assign it a role. This role has the ability to assume roles in other accounts, such as the management account (the so-called root account). The assumed role has the permissions to manage resources across all accounts. Importantly, throughout this entire process, there are no plaintext AccessKey pairs involved, which is a critical aspect of this solution.

This solution leverages two key capabilities. The first is the resource management tree, which organizes member accounts under a resource directory. The second capability is that the operations account must assume roles.

Next, we will demonstrate this process. Let me briefly introduce this diagram. It represents a typical multi-account architecture. An enterprise may have many accounts, and as mentioned earlier, the operations account runs automation applications. There are also production accounts A, B, and others. All automation applications run within the operations account C. Now let's go over the steps.

First, we create an ECS role called ecs-role in the operations account. This role has the AssumeRole permission of STS. Then, the ECS instance can be associated with this instance role. In the second step, we create a role in the management account, such as automation-assume. This role has permissions related to Resource Directory and the STS AssumeRole permission. Next, we configure roles for the ECS instance in the operations account and install Alibaba Cloud CLI tools on the ECS instance, allowing us to obtain temporary AccessKey pairs.

Now I'll demonstrate. This is our demo environment. This is the multi-account tree. I am currently using an Alibaba Cloud account. We select an operations account, which will be used to run automation applications. I've outlined a few operational steps here, so let's quickly review them. First, we create a role in the operations account whose trusted entity type is Alibaba Cloud service and whose name is ecs-role, and grant this role the necessary permissions to call STS.

In the second step, we create a role in the management account whose trusted entity type is Alibaba Cloud account. Its trust policy allows it to be assumed by the operations account.

In the third step, we purchase an ECS instance within the operations account. On this ECS instance, we perform some basic operations to check if we can obtain the temporary AccessKey pair of the Alibaba Cloud account. Once we acquire the temporary AccessKey pair, we can call Alibaba Cloud SDKs and APIs or run Terraform scripts. If we perform these steps in the console, this is how it would look. We have already scripted these operations using Terraform.

Let's take a quick look at the Terraform script. First, create a role in the operations account and grant it the appropriate permissions. In this step, the script creates the role and assigns the required permissions.

Step two involves creating an automation role in the management account and configuring its permissions and trust policies. Now, let's execute the script.

Let's wait a moment. Alright, the execution is complete. Now, let's verify if the resources have been created in the account. Currently, we're in the management account. According to the documentation, a role should have been created. Let's check if the role exists.

You can see the timestamp here: 12:28 PM. This indicates that this role was just created. This role has been granted two permissions: STS permissions and Resource Directory management permissions. Its trust policy allows it to be assumed by account 463, which is the operations account. Both permissions and trust policies are correctly configured. The script is executed.

Now, let's move into the operations account. In step one, a role should have been created in the operations account. Let's check if the role ecs-role has been created. You can see the timestamp matches when we created it. The role has the necessary permissions, and its trust policy is linked to ECS.

This confirms that after executing the Terraform script, we completed steps one and two, creating the required resources. In the operations account, we have an ECS instance. One important thing to note is that this ECS instance must be bound to the role we created. This binding is crucial because without it,

the ECS instance will not have the necessary permissions. Once the binding is complete, we can run Alibaba Cloud CLI commands on the ECS instance. For the CLI, you can refer to the official documentation and install it on the ECS instance. We'll paste these lines of code into the ECS instance.

Let's echo the output. You can see that the value retrieved is an STS token, a temporary key. This temporary key belongs to the management account. With this temporary key, you can operate resources within this account, and the permissions are quite broad. This demonstrates that in a multi-account setup, we can purchase an ECS instance on the operations account, and run all scripts from the ECS instance. Throughout this process, no plaintext AccessKey pairs are exposed. Everything is done through temporary keys, significantly enhancing security. That concludes the hands-on demonstration.

That wraps up the content for this episode. If you have any questions or ideas about cloud automation, feel free to scan the QR code below to join our DingTalk group for further discussion or to contact us. Thank you, and see you in the next episode.