Setting up the Stage for Enterprise-Grade Deployment on Alibaba Cloud
By Fabien Locquet, Solutions Architect
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 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.
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:
This method is not the recommended one, but it exists and may suit companies with a small number of users.
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.
This feature is not yet available and will be soon (mid-April).
In the rest of this article, we assume a Group-to-Role mapping, the more common approach adopted by big companies.
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
In order to meet the criteria of centralized billing management, the proposed option is to use aggregated billing. This consists of a top account, called a Channel Partner Account in Alibaba Cloud. This Channel Partner Account can create and managed sub-accounts, called Reseller Accounts.
The Channel Partner Account can see all the consumption from all of its Reseller Accounts. It can also set some credit limits on specific Reseller Accounts if needed.
Each Reseller 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.
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 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:
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:
For more information on Cross-Account Access/Switch Role, please refer to the page:
- Centralized rights management in Users Account
- 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:
"arn of the Administrator role in the Users Account"
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:
- 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
- Permissions management is spread across multiple stakeholders (Users Account and Team Accounts administrators)
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:
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:
CEN can also connect VPCs in different regions. This requires to purchase a cross-region bandwidth package, as described in the page:
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:
A redundant leased line can also be created, as described here:
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 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:
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:
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.
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.