Planning templates for an isolated cloud tenant with Terraform

With the increasing adoption of public cloud services by enterprises, the demand for isolated cloud tenants has become more common, driven by the need to meet security, privacy, and legal requirements.

Recently, I embarked on a new project for a financial industry client that required isolated tenants in Microsoft Azure to comply with federal regulations. To manage infrastructure at the tenant level, developers and administrators often rely on Terraform, an infrastructure-as-code tool. However, they face a challenge in scenarios where Terraform state files lack portability. To address this issue for isolated tenants, we are implementing a more modular approach to organizing these files. Instead of creating seven separate Terraform configuration files, we encourage writing one file and encapsulating it within modules.

Our client, as well as its banking customers, must adhere to strict banking regulations, necessitating complete isolation between each customer to ensure security. However, it is crucial to maintain uniformity across tenants. This can be achieved by modularizing common parameters in the Terraform code. Under this approach, a shared VNet or network is consistently utilized, and the base infrastructure remains relatively unchanged across subscriptions. By encapsulating the VNet in a module, along with separate modules for Dev, Prod, and the main configuration Terraform files, one can simply call the required modules for the desired environment. Additionally, deploying different subscriptions can be facilitated by creating a back-end module. Employing a single main configuration file, such as "main.tf," streamlines the process, allowing for easy invocation of the required modules.

Curious about Microsoft's approach to creating isolated tenants, I initially sought answers to this question. Consulting the relevant documentation shed light on the back-end processes. In the public cloud version of Microsoft Azure, dedicated instances of Azure Active Directory are provisioned for organizations upon registration. These Azure AD instances are logically isolated from one another to prevent unintentional or malicious data exchange. Azure AD operates on "bare metal" servers situated in a segregated network segment with host-level packet filtering and Windows Firewall, effectively blocking unwanted connections and traffic.