Terraform:Automation scenario - Create secure and compliant new accounts efficiently

You can refer to the following transcript:

Hello, welcome to Auto Talk, the Alibaba Cloud Open Platform Automation Series. I'm Yao Fang, a solutions architect from the Alibaba Cloud Open Platform team. In this episode, I'll share with you how to efficiently create a new cloud account using automated methods.

First, let's discuss why we need to create a new account. Here, I've summarized three typical scenarios. The first scenario involves setting up a disaster recovery site. For example, some of our customers have their businesses deployed in China (Hangzhou). However, they may worry about potential instability in the China (Hangzhou) region. To mitigate this risk, they might choose to deploy their business in another region, such as China (Shanghai) or China (Beijing). In this case, they often opt to use a new account to manage the business in China (Shanghai) or China (Beijing).

The second scenario is one we see frequently among domestic enterprises.

Due to regulatory constraints, many domestic companies are expanding their businesses overseas. When entering international markets like Europe or the U.S., they must comply with stringent security and compliance requirements. Typically, these companies will deploy their overseas business in a new account to meet local security and compliance standards.

The third scenario involves launching a new business. For instance, imagine your company is a gaming company, and you're developing a new game. When the game goes live, it's best to deploy it in a new account. This approach simplifies permission management for personnel and facilitates better financial accounting and cost allocation. These are the scenarios we observe from a customer perspective. Next, let's look at why, as a cloud provider, we recommend that customers adopt a multi-account deployment strategy. Here are four key benefits of using multiple accounts:

The first benefit is strong isolation. When using a single cloud account, all risks are concentrated in that account. If you choose to use a new account, there is physical isolation between the two accounts. Issues in the new account will not affect your existing business because of this physical separation. This ensures clearer security boundaries. Each account manages its own security, and risks are better distributed. For example, if the testing environment is compromised, it won't impact your production environment.

From a financial perspective, using multiple accounts allows for clearer visibility into the billing details of different businesses and departments. Recently, Alibaba Cloud released a white paper on multi-account strategies. This document explains why enterprises should adopt multi-account setups and why we recommend this approach to our customers. If you're interested in this white paper, we've provided a link for you to download it.

We've just discussed the benefits of multi-account setups. Now, the question is: do we have an efficient, automated way to improve the process of creating and activating accounts? That's what I'll share with you today: the account factory. Using automation, we can efficiently create new accounts.

So, what is an account factory? Here's how I describe it: before delivering an account, our operations administrator needs to handle basic configurations within the account. For example, access settings, account contacts, message notifications, and network configurations all require setup in the console. However, the biggest issue with manual console operations is that they are not reusable and are prone to errors. The account factory addresses this issue effectively.

How does it solve the issue? Essentially, it establishes a baseline for account configurations. By maintaining this baseline, once we create a new account, we can directly apply the baseline to the account. This ensures consistency across all accounts. Without this approach, configurations might be inconsistent. For example, certain settings might exist in Account A but are missing in Account B.

To summarize, the account factory helps us accomplish two key tasks: Using a service like Resource Directory, we can quickly create a new verified account. Without Resource Directory, the traditional process would involve registering a new account and completing enterprise verification manually. This process could take as short as a week or as long as two to three weeks, or even longer. For enterprises looking to deploy their business quickly, this timeline is unacceptable.

After creating an account, you still need to configure access settings, configure the IdP, create users, and create roles. If these configurations are done manually in the console, the process can be time-consuming and error-prone. Therefore, in the account factory, we transform these tasks into best practices and create a template so that they can be quickly mapped to the new account.

Now that we've covered the concept of the account factory, let's think about how we can utilize its capabilities. I'll share two approaches with you today.

The first approach is through the Cloud Governance Center, which can be directly accessed via the Alibaba Cloud console. However, there's a prerequisite: you must have an enterprise-verified account. We recommend using a blank account, one that doesn't run any existing business. This account should primarily serve as a management account.

The account factory provides several key capabilities. The first is the baseline. As I mentioned earlier, the baseline includes configurations such as protection rules for the account, access settings, password strength requirements for RAM users, and contact information. We collectively refer to these as the account baseline. Managing this baseline is crucial.

The second capability is that you can quickly create a new account and apply the baseline to it. Enterprises that already have existing accounts on Alibaba Cloud can also apply the baseline to those existing accounts. This ensures consistency across all accounts. For example, if you manage 10 or 20 accounts, all of them will have the same baseline.

The second approach is for enterprises with stronger automation capabilities. They can use tools like APIs or Terraform to implement the account factory solution. In the diagram I'm introducing here, we're using open-source Jenkins, though enterprises can also use other pipeline tools like GitLab. You simply write your Terraform code, commit it to the pipeline, and run it. Once the process is complete, you can refer to the bottom-left image, which shows the results of the Jenkins run. You'll see the process is broken down into steps. First, Jenkins creates a new account, and during execution, you can view log outputs to understand what actions are being performed.

Next, Jenkins proceeds to create the IdP, roles, and networks. You can adjust the code based on the specific needs of your enterprise. For instance, if you're not just creating a VPC but also need to provision compute resources like ECS instances or databases, you can expand and customize the Terraform code to include additional modules. This flexibility allows you to meet your specific requirements.

Of course, today I'm not just going to talk about slides. I'll also show you some code. We're going to use Terraform to implement the account factory. Before running this code, let me briefly explain what it does. First, it creates a new account. Second, it configures the IdP within that account. Next, it creates a user and a role, grants permissions to the role, and creates a VPC and a vSwitch. However, if you want to try out this program, you'll need to prepare an enterprise-verified account because only such accounts can execute this script. That's the gist of my presentation. Now, let's dive into the code and see how it executes.

First, let's look at the structure of the code. There are two main folders in the code: one is the module folder. Inside the module folder, we define some common Terraform modules. The first is the IdP module, which encapsulates the creation of the IdP within the account. The second is the network module, where we create resources like VPCs and vSwitches, grouping them into a single module to improve code reusability. There's also a role module, which handles operations related to RAM roles.

Next, we have the account factory, which I demonstrated earlier. It works in several steps. For example, the first step is to create an account. You can see the corresponding Terraform code here. It contains multiple resource blocks, and these will execute the necessary logic to create the account.

After creating the account, we proceed to configure the IdP? Similarly, we have the corresponding code for creating roles and assigning permissions to those roles.

Now, let's take a look at the results after the execution. Here's my account. This account has already completed enterprise verification. After completing the verification, we can create a resource directory. This is our resource directory. Inside it, there's a folder called Account Factory. I'll create a new account under this folder. Then, we'll enter the account and check whether its configurations are complete. Right now, no account exists, correct? Let's run the program.

I've already written a script. If we are using a pipeline tool like Jenkins, it will schedule and execute tasks node by node. But since we're executing tasks locally, we need to write a script to chain everything together. The program is now executing. First, it creates the account, then the IdP, followed by creating users and roles, assigning permissions, and creating the VPC and vSwitch.

It's done. Now, let's check the console.

This account didn't exist before, right? Let's check the timestamp. It was created just now, correct? So this is the new account we just created. Now, let's go inside and check the baseline configurations.

First, let's look at the RAM user. We've set up the IdP, and in SSO, you can see the IdP we just created. Check the timestamp. It was created just moments ago. Then, we have the user and the role. Next, on the VPC page, we can find the VPC and vSwitch. This VPC was just created. You can see the timestamp: August 7th, 11:39:37 AM. It matches the time when we ran the script.

And under this VPC, the vSwitch has also been created, right? From this example, you can see that if there's a new business going live, we can simply run the script I just demonstrated to create a new cloud account. Within this cloud account, we can configure things like RAM users, roles, networking, and even more. My demonstration was relatively simple. In reality, we can configure much more. For instance, we could set up message contacts and activate certain cloud services. There's a lot we can do. With such a script, we can significantly improve the efficiency of automated operations.

That concludes the content for today's session. If you have any questions about what I discussed or ideas about cloud automation, feel free to scan the QR code at the bottom of the screen to join our DingTalk group and connect with us. We look forward to your feedback and hope to see you in the next episode.