Rake on building a hybrid cloud with Azure

From the name of the hub, you can understand that I work in the company EPAM Systems. For more than 3 years, our company has been using its own Private Cloud (EPC). Here you can find more detailed information about it.

Recently, our cloud is actively moving towards a hybrid cloud solution.

Due to the large number of people and teams working in our company, the question arises about the management of project resources. I mean the creation of an isolated environment, consolidated auditing, consolidated billing, multi-level analytics.
')
Disclaimer. This article is not a working manual or advertising. In it, I will try to describe one of the problems that our team encountered during integration with Azure. Thank you in advance for feedbacks, if there are interesting offers, I will definitely systematize it and post it here or in a separate article.


Technical requirements for integration with Azure:

• Unified Azure resource management using existing EPC tools (CLI / UI), which are already used to manage internal cloud and AWS resources
• integration with corporate access control and quota control systems
• project billing
• monthly financial report on used resources
• provision of direct access to the Azure Management Console upon request
• ensuring the highest possible audit of all user actions (both through the EPC and the Azure Web UI)

Previously, we successfully integrated with AWS. At the same time, we use root and linked accounts to share resources (you can read more here ). After mastering integration with AWS, it was decided to take on Azure.

The first step is to develop principles for distributing access to project resources, which is complicated by the need to be able to provide access to the Azure Management Console.

Azure assumes the following access control scheme. An organization receives an account of type Enterprise (enrollment), within which it is possible to create multiple user accounts (accounts). Within the account, you can create multiple subscriptions. As part of the subscription, the account owner is a Service administrator. He can give another AD user access to this subscription by assigning him the Co-Administrator role.



Azure provides 2 authorization options: LiveID and SSO (Single Sign On). We immediately rejected LiveID due to corporate standards. Best Practice suggests using one account for a project, and using subscriptions as environments (DEV, QA, PRP, STAGE, etc). Since it was decided to use SSO authorization, it became clear that for each project will have to have a separate user in AD. A suggestion was made to use existing users for this (for example, a project manager user). But we immediately abandoned this option due to the fact that a person can go to another project or even stop cooperating with the company. The option to start a separate user for a project also turned out to be not very convenient, because somewhere this data should be stored and someone should monitor their relevance. In addition, after creating an account, you must manually create a subscription and import a certificate into it for authorization when working with Azure via the API.

Therefore, it was decided to use a separate subscription for each project. Thus, you can create a pool of subscriptions, import a certificate and, if necessary, take a ready-made subscription from the pool and use it for a new project or as a separate environment of an existing project. This will also allow you to use the API to assign users to the Co-Adminisctrator role, which gives direct access to the Azure Web UI.

The first question that arose after choosing this option is the limit on the number of subscriptions to one account. Since it was not possible to find an answer to this question on the official websites, besides the fact that there is no additional charge for creating subscriptions, it was decided to try to create a pool of 500 subscriptions.

In view of the fact that there is no possibility to add a subscription through the API, with the help of java + selenium we wrote a simple clicker to create these subscriptions.

Total

Initially created 1 subscription in 60-90 seconds. But after overcoming the barrier of 50 subscriptions, this time began to grow.
In the area of ​​90+, creating one subscription took about 5 minutes (±). At the moment, about 150 subscriptions have been created and the average time to create a new subscription is 8 minutes. Creating subscriptions continues. Accordingly, the question arises, what will happen next.
In general, this is exactly what I wanted to share. If someone has a similar experience - well in the comments.

UPD.

After talking with a specialist from Microsoft, it turned out that there were no restrictions on the number of subscriptions.
But in general, the question remains open.