Setting up the Stage for Enterprise-Grade Deployment on Alibaba Cloud

This article shows you how you can set up an enterprise grade deployment for managing thousands of users while maintaining a centralized governance on the cloud.

By Fabien Locquet, Solutions Architect

Introduction

Big enterprises typically have dozens, sometimes hundreds of users. They typically manage their users using some centralized – and often on-premise – Identity Provider like Active Directory, which is managing Single Sign-On across multiple platforms like emails, internal services, etc.

With the rise of cloud computing, and with each cloud provider proposing a different platform with a different identity management system (RAM for Alibaba Cloud, IAM for AWS, etc.), there is a need to be able to be able to interface to an external Identity Provider in order to keep user management centralized and integrated in the existing enterprise platform.

Additionally, the users are typically grouped in teams, each team working on one or more projects. Cloud being based on pay-as-you-go, there is a strong requirement to be able to monitor and track the different team's cloud consumption, and set boundaries when needed.

From a deployment perspective, each project should be able to manage its own project in a flexible manner, providing resource isolation if needed, and ad-hoc cross-project communication.

This blog's article deals with an approach to tackle those requirements in Alibaba Cloud's platform, using core products like Resource Access Management (RAM) and Cloud Enterprise Network (CEN).

This article covers three parts:

The first part of the article describes the methods to defer the Alibaba Cloud user management to an external Identity Provider.
The second part presents an approach for managing users permissions between different teams and different projects.
The last part presents a network topology to allow IDC connection and centralized infrastructure management across multiple teams and projects.

Interfacing RAM with an External Identity Provider using Single Sign-On (SSO)

This first part is to be able to interface Alibaba Cloud Platform with an external Identity Provider, and how it affects the User management.

Alibaba Cloud supports multiple approaches when it comes to interfacing with an external Identity Provider. The detailed documentation can be found here:
https://www.alibabacloud.com/help/doc-detail/93684.htm

The following sections describe the 2 main approaches.

User-Based Mapping

The first method consists to map a user in the Identity Provider to a user in RAM. This is the simplest method, but which also has a very big drawback: for each user in the IdP, a user with the same exact same identifier must be created in RAM. This is how the Alibaba Cloud platform will look-up the user in the external IdP when he logs in.

RAM needs to be configured to support AD user mapping and SSO. The procedure is described here:
https://www.alibabacloud.com/blog/saml-integration-between-windows-active-directory-and-alibaba-cloud_594516

This method is not the recommended one, but it exists and may suit companies with a small number of users.

More information on User-Based Mapping can be found here:
https://www.alibabacloud.com/help/doc-detail/110499.htm

Group to Role Mapping

In this method, the assumption is that the Identity Provider supports User Groups (for ex. Active Directory).

It consists of mapping a group of users in the Identity Provider to a RAM Role in Alibaba Cloud. This method requires more initial configuration, with the need to create one RAM Role per IdP Group. However, once this initial configuration is done, every new user added to a group will be mapped to the RAM Role associated with the IdP Group he belongs to. This allows to supports hundreds or even thousands of users, groups in a manageable number of groups.

In the rest of this article, we assume a Group-to-Role mapping, the more common approach adopted by big companies.

More information on Role-Based Mapping can be found here:
https://www.alibabacloud.com/help/doc-detail/109791.htm

Account Management in Alibaba Cloud

The second part of this article deals with the necessity to manage the permissions of all of those users coming from the external IdP, while still:

Allowing each Team to administrate their own projects, in isolation from other Teams
Provide overarching and centralized billing management

Aggregated Billing

In order to meet the criteria of centralized billing management, the proposed option is to use aggregated billing. The idea is to have a ‘Master’ account that can create and managed sub-accounts.

The Master Account should be able to see the consumption from all of its Sub-Accounts. It should also be able to set some credit limits on specific Sub-Accounts if needed.

Using this approach, each Sub-Account can then be associated to a specific Team in the company.

This allows to manage with fine-grained the cloud consumption of all the different sub-accounts/Team, and still have Teams to be isolated from each other and have full controls over their resources.

In Alibaba Cloud, there are 2 types of Accounts that enables the above feature, the Enterprise Account and the Channel Partner Account. They both allow to define a master account and sub-accounts with aggregated billing. The difference lies in how specific tiered priced are applied:

For Enterprise Account, a tiered price negotiated at the master Account level will automatically be applied to Sub-Accounts.
For Channel Partner Account however, tiered prices applicable for the Master Account will not be automatically applied to the Sub-Account, thus being more appropriate to resellers partners, having different customers.

It seems more appropriate and logical to use the former approach than the latter. That’s why in the rest of this document, only Enterprise Account will be used for the Account type.

Important Note: Channel Partner Account can't be activated from the Console. You will have to contact your local Alibaba Office in order to change the type of your Alibaba Cloud Account to a Channel Partner Account.

Alibaba Cloud Accounts Layout

Meeting the centralized Users management requirement requires to go a bit deeper. The mechanism is to define an Account, which we will name the 'User Management Account', where all users will be defined and managed.

Each Team Account (Reseller Account) will in turn create RAM roles with sets of permissions to manage internal resources. It then sets policies to allow users in the User Management Account to assume those roles. This means that a user in User Management Account will have the right to log in a Team Account and manage resources if the Team Account allowed him to do so.

Each Project will then be associated with a VPCs. This enables resources isolation across projects through the use of VPCs. VPCs can also be used to further isolate environments inside projects, for example one VPC for the development environment, and one VPC for the production environment.

The following diagram illustrates the mechanism described above:

User Access Workflow

At this point of the discussion, there are enough elements to draw a global picture of the user access workflow, as well as the mapping of the different entities between the Enterprise space and the Alibaba Cloud space.

The next section focuses more on where to manage the user's permissions in Alibaba Cloud's space.

Cross-Account Access

Cross-Account access using switch-role allows a Role (or User) in an Account to get access to another Account by assuming a Role in the latter.

There are at least 2 methods to enable this Cross-Account access, each method pertaining to a different philosophy with respect to permissions management. Whether the permissions shall be managed by a centralized governance team or by the different project Teams themselves will condition which method is better apt for the scenario.

1st Method: Users Account manages Roles access to Team Account

In this method, the Team Account grants access to any identity in Users Account with sufficient permissions. It is the responsibility of Users Account administrator to correctly grant access to its Users/Roles to access the Team Account resources.

The following diagram illustrates the approach:

In the above diagram, a role is defined in Users Account with a Custom Policy allowing to:

Switch role to Role 1 in Team 1 Account
Switch role to Role 2 in Team 2 Account

It will not be able to switch role to any other Role in an external Account, even though the target Role has defined a Trust Policy allowing switch role from any role in the Users Account.

In the Team Account, the Role must define a Trust Policy to allow Cross-Account access (switch role). The default Trust Policy for external Account will allow all Users with permissions described previously to switch role:

{
    "Statement": [
        {
            "Action": "sts:AssumeRole",
            "Effect": "Allow",
            "Principal": {
                "RAM": [
                    "acs:ram::12345678:root"
                ]
            }
        }
    ],
    "Version": "1"
}

Additional Policies are required to be associated with the Roles in Team Accounts in order to allow those identities to interact with the resources in the Accounts, depending on the role's responsibilities.

For more information on Policies, please refer to:
https://www.alibabacloud.com/help/doc-detail/93732.htm

For more information on Cross-Account Access/Switch Role, please refer to the page:
https://www.alibabacloud.com/help/doc-detail/93745.htm

The pros:

Centralized rights management in Users Account
The cons:
Team can't manage fine-grained access to their resources, it is deferred to the Users Account administration team, which may not be the governance process for the company

2nd Method: Team Account manage access for Roles in Users Account

The 2nd method puts the responsibility of granting access to the Team Account to the Team Account administrators.

With this approach, some generic Roles can be defined in the Users Account, for ex. An Administrator Role, a Developer Role or an Operator Role. The Team Account administrator can then pick and choose which ones of the Roles defined in the Users Account will be allowed to switch role and manage resources in the Team Account.

The following diagram illustrates the approach:

In the above diagram, 2 roles are defined in the Users Account, Administrator and Developer.

In the Team Accounts, similar roles are defined as needed.

For example, if an administrator role is needed in Team Account 1, it will require a Trust Policy allowing Administrator users from the Users Account to be able to assume the Administrator Role in the Team Account. This is done by defining the following Trust Policy:

{
   "Statement": [
      {
         "Action": "sts:AssumeRole",
         "Effect": "Allow",
         "Principal": {
            "RAM": [
               "arn of the Administrator role in the Users Account"
            ]
         }
      }
   ],
   "Version": "1"
}

The Administrator in Team Account 1 also needs additional permissions in order to be able to interact with the Team Account's resources. For an Administrator user, a System Policy like "AdministratorAccess" can be appropriate. Any System or Custom policy can be applied to the Role in the Team Account as required.

For more information on Policies, please refer to:
https://www.alibabacloud.com/help/doc-detail/93732.htm

Pros:

Team administrator are empowered to manage access to their resources inside their projects
Generic Roles enables better maintenance and automation
Can be more easily mapped to groups in external Identity Provider with same responsibilities

Cons:

Permissions management is spread across multiple stakeholders (Users Account and Team Accounts administrators)

Network Topology

Now, let's see how the network topology can support this Account Management approach.

Earlier, we have seen that each team is assigned a Team Account. Each team being responsible for one or more projects, we also mentioned that a project is mapped to VPC.

In big companies, there is most probably a team being responsible for managing core infrastructure components like DNS, log aggregator, etc. This means that there is a need for multiple VPCs to be able to talk to each other.

On top of that, controlled Internet connection is also mandatory in most cases.

Optionally, the company will want to connect its on-premise datacenter to the cloud infrastructure, while being able to secure its local network.

In order to address all of the above requirements, the proposed Network Topology is the following:

To simplify, this article assumes the firewall is deployed on-premise, which is a perfectly valid assumption. However, if needed, a 3rd party firewall can be deployed in Alibaba Cloud using a Hub-and-Spoke architecture. This is out of scope of this article, as the topology design will be heavily impacted by the selected firewall solution.

This solution relies on multiple products:

Cloud Enterprise Network at its core
NAT Gateway for Outbound/Inbound Internet communication
Security Groups for securing outbound/inbound VPC communication

Cloud Enterprise Network (CEN)

CEN allows to create a meshed interconnection of VPC and network devices like VBR (Virtual Border Routers) for IDC connectivity. The documentation can be found here:
https://www.alibabacloud.com/product/cen

The Cloud Enterprise Network needs to belong to a specific Account. Let's call this account the Infrastructure Account. This Infrastructure Account can also be used to host all the core components like private DNS, log aggregation systems, etc.

In order to connect VPCs from other Accounts, they have to first 'trust' the CEN instance, and also the CEN instance must add them explicitly in the meshed network.

For more information on how to set up a CEN instance and allow cross-account authorization, please refer to the page:
https://www.alibabacloud.com/help/doc-detail/65901.htm

CEN can also connect VPCs in different regions. This requires to purchase a cross-region bandwidth package, as described in the page:
https://www.alibabacloud.com/help/doc-detail/65936.htm

The leased line that connects to the company IDC is logically connected to the CEN using a network device called a VBR (Virtual Border Router). The procedure to connect a leased line to Alibaba Cloud is described here:
https://www.alibabacloud.com/help/doc-detail/44844.htm

A redundant leased line can also be created, as described here:
https://www.alibabacloud.com/help/doc-detail/92683.htm

Note: Instead of a leased line, a VPN can also be used to connect the CEN to the Company IDC. For detailed steps to deploy a VPN Gateway inside a cross-account CEN, please refer to the blog article: https://www.alibabacloud.com/blog/594326

NAT Gateway

NAT Gateway is a managed service allowing highly-available, scalable and secured access to the Internet from inside a VPC.

It allows to set up SNAT routes for outbound Internet connection, and DNAT routes for inbound Internet connections.

The documentation can be found here:
https://www.alibabacloud.com/product/nat

Security Groups

Security Groups is a mechanism to group VPC resources inside a security 'barrier'. The user can specify rules to allow or deny a specific traffic to exit from/enter in the Security Group.

The documentation for Security Group can be found here:
https://www.alibabacloud.com/help/doc-detail/65408.htm

In the near future (April), ACL will also be supported on VPCs as well, allowing to define more fine-grained security rules for inbound/outbound traffic.

Conclusion

We hope that this article gave you clear insights Alibaba Cloud helps set up an enterprise grade deployment for managing hundreds to thousands of users split in different teams with different projects, while still abiding to the centralized governance process all big enterprises are looking for.

Community