Use Terraform to build an Azure landing zone

Author: David Wright

This document provides an opinionated view on how to use a Terraform-driven blueprint for designing, deploying, and governing Azure landing zones for both the shared-services platform subscriptions and the application specific subscriptions, all aligned to Azure's Cloud Adoption Framework. It establishes clear roles, policies, and automation patterns (using HCP Terraform, Vault, Sentinel, Packer) so platform teams can build a secure, scalable foundation and application teams can consistently onboard workloads with guardrails and GitOps-style workflows.

Scope

This document provides a comprehensive guide to designing, deploying, and operationalising Azure Landing Zones using Terraform and the HashiCorp Cloud Platform (HCP). It serves as a structured, opinionated methodology for establishing secure, scalable, and compliant cloud environments.

Design

The document offers prescriptive guidance on architecting Azure Landing Zones, including recommendations for structuring subscriptions and management groups. It emphasises the importance of aligning with the Azure Cloud Adoption Framework to ensure best practices across all design areas. Key aspects covered include:

• Structuring subscriptions and management groups to support different environments and business units.
• Designing secure, scalable, and compliant environments using Terraform and HCP.

Deployment

The deployment process details how to use Terraform for setting up the necessary infrastructure. This includes:

• Configuring networking, security, and governance controls.
• Automating the deployment process through CI/CD pipelines to ensure consistency and efficiency.

Operational

Post-deployment, the document addresses how to manage and operate Azure Landing Zones effectively. This involves:

• Monitoring and logging using tools like Azure Monitor and SIEM integration.
• Ongoing maintenance tasks to ensure the environment remains secure and efficient.

Key Focus Areas:

• Account Structure: Guidance on organising and managing Azure subscriptions and management groups to support various environments and business units.
• Identity and Access Management (IAM): Best practices for configuring Azure Active Directory (Azure AD), role-based access control (RBAC), and federated identities to ensure secure access to resources.
• Networking: Recommendations for designing and implementing a hub-and-spoke network architecture, including the use of Azure Virtual Networks, Network Security Groups (NSGs), and Azure Firewall.
• Security: Strategies for implementing security controls such as Azure Policy, Azure Security Center, and centralised logging to protect the environment and ensure compliance with regulatory requirements.
• Monitoring: Guidance on setting up monitoring and logging solutions to provide visibility into the environment and support operational tasks.

Application enablement

Best practices for enabling application teams to deploy and manage their workloads within the Landing Zone framework, including self-service capabilities, automation, and governance controls.

Applicability

The guidance provided applies to both greenfield and brownfield environments:

• Greenfield Environments: Comprehensive guidance for organisations starting from scratch, covering all aspects of setting up Azure Landing Zones in a new environment.
• Brownfield Environments: Strategies for integrating and migrating to the Landing Zone framework for organisations with existing Azure environments, ensuring consistency and compliance across the entire environment.

Methodology

The methodologies and best practices outlined are modular, scalable, and adaptable, allowing organisations to tailor the Landing Zone framework to their specific needs and requirements. The document emphasises:

• Automation: Using tools like Terraform and CI/CD pipelines to streamline deployment and management.
• Policy Enforcement: Implementing policy-as-code using tools like HashiCorp Sentinel to enforce compliance and governance controls.
• Secure Operations: Best practices for ensuring the security and compliance of the environment, including centralised monitoring, logging, and security controls.

By consolidating these elements into a dedicated "Scope" section, this document provides readers with a clear understanding of its focus and boundaries, making it easier to navigate and apply the guidance effectively.

Audience

In this document, we focus on two primary consumers:

• The Platform Team: (central/shared-services teams) are Responsible for designing, building and operating the foundational subscriptions ("Platform landing zones") that host cross‑cutting services—identity (Entra ID), connectivity (hub networks, VPN/ExpressRoute, firewalls), management and governance (management groups, policies, RBAC). They consume and expose these shared services for application teams, ensure consistency, enforce compliance, and automate policy and security guardrails via Terraform, Vault, Sentinel, Packer.

• The Application Team: focused on provisioning and managing the subscriptions that host their applications (for example containerised microservices on AKS, databases, event hubs). They leverage the platform landing zone's shared services and integrate additional application‑specific resources, tagging, networking, secrets, and deployments through Terraform code, GitOps workflows, and service‑mesh tooling (Consul, Vault CSI, Flux/ArgoCD).

Definitions

An Azure landing zone comprises two complementary subscription types, both provisioned and managed through Terraform:

Platform landing zones provide shared, centrally managed services such as identity, connectivity, and governance, to all application workloads. Defined and deployed via Terraform modules, these subscriptions (for example Identity, Management, Connectivity) belong to central teams and enforce global policies to improve consistency and operational efficiency.

Application landing zones provide dedicated subscriptions for individual applications. You pre‑provision them through Terraform code and govern them via management‑group‑level policy assignments. In reference architectures, you'll often see multiple application zones (for example "A1" and "A2" subscriptions), each defined by its own Terraform configuration, with tailored resources and policies.

Design principles

Microsoft Cloud Adoption Framework for Azure alignment

To construct a landing zone via Terraform, critical focus areas must align with Microsoft Cloud Adoption Framework for Azure best practices across: Account Principles, Architecture Type, Resource Organisation, Management Group Hierarchy, Security and Compliance, and Automation and DevOps. To implement these principles effectively within the HashiCorp ecosystem, we'll examine a systematic approach through a platform landing zone deployment case study, followed by an application landing zone implementation using identical methodologies. Each core principle encompasses critical technical considerations where the HashiCorp product suite provides significant implementation value for platform landing zone development.

Security, compliance, automation, and governance principles

Policy-driven governance

HashiCorp's approach to policy management uses our policy as code tool (Sentinel), which ensures uniform policy application across environments, enhances security through version control, and scales efficiently with infrastructure growth. A platform landing zone should provide cloud governance, emphasising risk management and continuous improvement. Terraform allows organisations to automate and streamline the deployment of Azure-specific policies to meet those requirements using pre-configured examples. The Foundation Library contains such examples and reduces manual intervention and the complexity of creating Terraform Sentinel code with Center for Internet Security (CIS) backed code examples. This means best practice consistency across different environments, making it easier to manage policies at scale.

In our N-tier architecture example, organisations can apply policies from the library's networking folder to enforce security and compliance across the N-tier architecture:

• DMZ Tier: Enforce SSL/TLS policies for web applications, require WAF-enabled services like Azure Front Door or Azure Application Gateway.
• Web/Business Tier: Ensure all VMs and containers have proper tagging, logging, and monitoring enabled.
• Data Tier: Enforce encryption-at-rest policies, prevent public access to databases, and require backup policies for critical data.

Centralised resource management

Organisations should use Terraform to enhance resource management for platform landing zones with consistent, secure, and efficient infrastructure management, benefiting from using a private Module registry, version control integration, and robust compliance and security features.

Automation and governance principles

HCP Terraform drift detection feature continuously monitors infrastructure to identify any changes that deviate from the desired state, allowing for proactive remediation. This ensures that all environments remain compliant with organisational standards and prevents unauthorized changes from remaining undetected. Configure the drift detection capability to scan environments regularly and trigger notifications or automated remediation workflows when you identify discrepancies.

Modular and reusable code

Terraform modules allow for the creation of reusable code, making it easier to manage and deploy complex infrastructure setups. This modularity enhances the efficiency of managing large-scale environments. Organisations should develop a comprehensive library of modules for common Azure resources and patterns, ensuring these modules are thoroughly tested, versioned, and documented. These modules could build on the Azure Verified Modules mentioned in more detail in the resource section. Each module should adhere to organisational standards for naming, tagging, security configurations, and compliance requirements.

Version control integration

Using GitHub as the VCS with HCP Terraform means it registers webhooks with GitHub when creating a workspace, automatically queuing a Terraform run whenever new commits merge to the branch associated with the workspace. This integration provides a single source of truth for infrastructure code. Organisations should implement branch protection rules to enforce code reviews before applying changes to production environments, and use feature branches for testing changes before merging to main deployment branches.

Enhanced security and compliance

By integrating HCP Vault with GitHub Actions, organisations can inject secrets directly into Terraform workflows. This uses a GitHub Action, which allows authentication with Vault and retrieval of secrets dynamically during the workflow. Organisations should implement role-based access control for Vault, ensuring that only authorized personnel can access sensitive information, and rotate credentials regularly to maintain a secure posture.

State management

Storing Terraform state files on the HCP platform with state locking prevents concurrent modifications, ensuring the integrity of the infrastructure state. State files contain sensitive information and require storage in an encrypted format and classification as such, with access limited to authorized personnel. Organisations should implement state file backups and versioning to allow for recovery in case of corruption or accidental deletion, and consider state encryption for additional security.

Platform landing zone architecture

N-tier architecture

When building with the mindset of a Platform team, the consideration is to build an environment that serves as a shared service domain. This creates a repeatable and scalable architecture, whose primary focus supports other teams. In our first example, we build an N-Tier environment suitable for simple web applications, migrating an on-premises application to Azure with minimal refactoring, unified development of on-premises and cloud applications, and traditional on-premises applications, covering many principles.

Subscription and management group hierarchy

Create and manage separate Azure subscriptions using Terraform with an N-tier architecture to ensure isolation between DMZ, Web, Business, and Data tiers. Each tier exists in dedicated subscriptions or management groups, enabling clear separation of concerns and governance.

• Web Tier: Deployed in a separate subscription or resource group for frontend services (e.g., Azure App Service, Azure Front Door, or Virtual Machines running UI components).
• Business Tier: Includes backend processing logic (e.g., Azure Kubernetes Service (AKS), Azure Functions, or Azure App Service API) in a dedicated subscription.
• Data Tier: Ensures data governance and security by deploying Azure SQL, Cosmos DB, or other databases in an isolated subscription with strict access controls.

Configure Terraform with a provider alias to manage deployments across geolocation subscriptions. HashiCorp Vault securely stores Azure service principal credentials and other secrets required for provisioning. Use Packer to create hardened virtual machine images for services running in any tier, ensuring consistency and compliance.

Management groups for centralised control

Organizations should organize subscriptions into management groups (for example Development, Testing, Production) to organize governance and policy application. Link these subscription boundaries to HashiCorp Cloud Platform (HCP):

• Terraform Organisation/Project/Workspace: Manage these subscriptions in separate domains. Terraform infrastructure as code approach ensures consistency and automation in policy application across different environments. Consult the HashiCorp Validated Designs to determine which boundary suits the environment.
• Appropriate Separation: Customize the separation based on organisational needs, ensuring independent management of domains under a unified control plane.

Centralized control and easier management

Management groups allow for centralised control, making it easier to manage multiple subscriptions and enforce governance policies uniformly. Use HashiCorp Consul for service discovery and health monitoring for workloads across environments, ensuring a cohesive management experience.

For organizing management groups, subscriptions, and resource groups for the N-Tier architecture, map these to organisations, projects, and workspaces in HCP Terraform. For example, a management group structure might include a top-level Enterprise group with child groups for Production, Development, and Test. These correspond to separate Terraform workspaces with appropriate access controls and policy assignments as shown below.

Role-based access control (RBAC)

Organisations can use Terraform to assign roles to Azure Active Directory (Azure AD) users or groups within each subscription. This ensures secure access control and governance by defining who can access and manage resources. HashiCorp Vault stores sensitive information such as Azure service principal credentials, providing robust encryption and access control mechanisms to protect credentials and secrets. Configure Terraform to retrieve secrets from Vault, ensuring secure management of sensitive information during the provisioning process.

For our N-tier example, implement Role-Based Access Control (RBAC) across all tiers:

• Web Tier: Assign least-privilege roles for developers managing front-end services.
• Business Tier: Ensure API services and microservices have managed identities with specific permissions to backend services.
• Data Tier: Restrict database access to only required application services and database administrators.

Policy-driven governance: Sentinel and Azure Policy

Organisations can apply policies from the library's networking folder to enforce security and compliance across the N-tier architecture:

• DMZ Tier: Enforce SSL/TLS policies for web applications, require WAF-enabled services like Azure Front Door or Azure Application Gateway.
• Web/Business Tier: Ensure all VMs and containers have proper tagging, logging, and monitoring enabled.
• Data Tier: Enforce encryption-at-rest policies, prevent public access to databases, and require backup policies for critical data.

IAM hierarchy (management group, subscription, resource group)

When using Terraform to deploy an Azure Platform landing zone, organisations should configure Azure Active Directory (Entra ID) for identity and access management within HCP Terraform and leverage HashiCorp Vault for dynamic secrets management. Other considerations would be:

• Management Group IAM Configuration: Configure IAM at the management group level for top-level policy enforcement. This establishes baseline security controls that propagate downward through the management hierarchy, ensuring consistent security posture across all subscriptions. Organisations should create dedicated management groups for different environments or business units, each with appropriate IAM configurations.
• Subscription-Level RBAC Assignments: Assign RBAC roles based on the landing zone type (production, development, sandbox). Production environments should have stricter access controls than development environments, with explicit approval processes for any elevated access. Review role assignments regularly to ensure alignment with the current organisational structure and responsibilities.
• Resource-Group Level Permissions: Align permissions with workload classifications. Different workloads may have different sensitivity levels or compliance requirements, necessitating tailored access controls. Organisations should develop a classification system for workloads and apply consistent RBAC patterns based on these classifications.
• Custom Role Definitions: Create custom roles for landing zone administrators and operators. These roles should follow the principle of least privilege, granting only the permissions necessary for specific job functions. Organisations should document these custom roles thoroughly and review them periodically to ensure they remain appropriate.
• Azure AD Tenant Configuration: Set up Entra ID for enterprise-wide identity management. Integrate this with existing identity sources where possible to maintain consistency and reduce administrative overhead. Mandate multi-factor authentication for all administrative access to Azure resources.
• Conditional Access Policies: Configure policies to secure zone resources. These should include location-based restrictions, device compliance requirements, and risk-based access controls. Organisations should implement session controls for sensitive operations and regularly review sign-in logs for suspicious activity.
• Federation with Existing Identity Providers: Integrate Azure AD with existing identity providers. This reduces administrative overhead and improves user experience by enabling single sign-on across multiple systems. Configure federation with appropriate security controls, including certificate rotation schedules and monitoring for authentication anomalies.

Just-in-time access

Use Vault for Just-in-Time Secure Management, so your organisation can store and manage sensitive information related to management groups securely using HashiCorp Vault. Vault's robust security features protect management-related information and make it accessible only to authorized personnel.

This offers the following benefits:

• Vault Integration: Use HashiCorp Vault for on-demand credential issuance. This enables a zero-standing-privileges model where the system grants administrative access only when needed. Configure Vault policies to enforce appropriate access controls and credential lifetimes.
• Temporary Access Tokens: Implement temporary tokens for landing zone operations. These should have limited lifetimes and scopes, ensuring that the system revokes access automatically after the necessary operations are complete. Log and monitor token issuance for abuse.
• Automated Credential Revocation: Revoke credentials automatically after maintenance windows. This ensures that elevated access does not persist longer than necessary, reducing the risk of credential abuse. Log and verify revocation events to ensure access terminates properly.
• Just-in-Time Access: Use dynamic credentials for just-in-time administrative access to landing zone resources. This reduces the risk of credential theft and abuse by limiting the duration of elevated access. Organisations should implement approval workflows for just-in-time access requests and maintain comprehensive logs of all elevated access sessions.
• Separate Plan and Apply Access: Implement separate federations for plan and apply stages. This enforces segregation of duties, ensuring that those who can propose changes are not necessarily the same individuals who can implement them. This pattern is particularly important for production environments, where changes should undergo thorough review before implementation.

Federation and service principals

• Workload Identity Federation: Implement federated identities for platform services. This reduces the need for stored credentials by allowing services to authenticate using trusted identity providers. Configure appropriate trust relationships and monitor federation activity for signs of compromise.
• Dedicated Service Principals: Use dedicated service principals for deployment pipelines. Each pipeline needs its service principal with the minimum permissions necessary to perform its functions, leveraging federation to separate plan and apply with HCP Terraform. Audit and rotate these regularly to maintain security posture.
• Least-Privilege RBAC Assignments: Scope RBAC assignments to specific landing zone boundaries. Service principals should not have broader access than necessary to perform their functions. Review and adjust permissions regularly as service requirements evolve.

Networking and connectivity

Hub-and-spoke model

To design and implement a secure and efficient network architecture for platform landing zones using Terraform, organisations should adopt a structured approach that balances security, performance, and operational flexibility. The network architecture typically follows a hub-and-spoke model, where the hub network serves as the security and compliance layer, containing shared security services such as Azure Firewall, VPN Gateway, and Azure Bastion. Tailor the spoke networks to specific connectivity needs for different workload types.

The hub network forms the central connectivity point for the entire landing zone architecture and requires implementation as a dedicated Virtual Network with appropriate subnets for different security services. Use Terraform to provision the following components:

• Azure Firewall: Deployed in a dedicated subnet to provide centralised traffic filtering, threat intelligence-based filtering, and FQDN filtering for outbound traffic. Manage firewall policies as code through Terraform, with appropriate approval workflows for changes.
• Virtual Network Gateway: Implemented for site-to-site VPN or ExpressRoute connectivity to on-premises networks. Include redundancy options for high availability and appropriate bandwidth allocations based on anticipated traffic patterns in gateway configurations.
• Azure Bastion: Deployed to provide secure RDP and SSH access to virtual machines without exposing them directly to the internet. Log and monitor Bastion usage, with session recordings enabled for sensitive environments.
• Azure Firewall Manager: Configured to centrally manage multiple Azure Firewall instances across the organisation, ensuring consistent policy application and simplified management. Establish policy hierarchies to allow for both global and environment-specific rules.
• Network Virtual Appliances (NVAs): Where required, deployed with appropriate routing and high availability configurations to support specific security or networking requirements. Monitor NVA health, with automated failover mechanisms to prevent service disruptions.

Network security groups (NSGs), User-defined routes (UDRs), Private link

Design and implement the connectivity between hub and spoke networks, as well as external networks, based on the following criteria:

• Spoke networks connect to the hub and contain the workload resources. Tailor each spoke to the specific requirements of the workload it hosts:
• Workload-Specific Virtual Networks: Created for different application environments or departments, with appropriate address space allocation to prevent overlap and allow for future growth.
• Network Security Groups (NSGs): Apply these at both subnet and network interface levels to enforce granular access controls based on the principle of least privilege. Manage NSG rules through Terraform and regularly audit them for compliance.
• User-Defined Routes (UDRs): Configured to control traffic flow between spokes and to force traffic through security appliances when required. Routing tables should be version-controlled and tested thoroughly before deployment.

Private link and VPC endpoints

• Private Link and Private Endpoints: Implement these to provide secure access to PaaS services without traversing the public internet. Deploy private endpoints in dedicated subnets with appropriate network security controls.
• VNet Peering: Establish this between hub and spoke networks with appropriate settings for gateway transit and remote gateway use. Manage peering configurations through Terraform modules to ensure consistency.
• Hybrid Connectivity: Configure this through ExpressRoute or VPN, depending on bandwidth, reliability, and security requirements. Implement redundant connections for business-critical workloads.
• Internet Egress: Centralize this through the hub network to provide consistent security controls and monitoring for all outbound traffic. Harden and monitor egress points for suspicious activity.
• DNS Resolution: Implement this with Azure Private DNS zones for internal name resolution and conditional forwarding for hybrid scenarios. Manage DNS configurations through Terraform to ensure consistency and prevent drift.

Terraform modules and workspaces

Standardized Terraform modules from the private registry, as outlined above, should provide reusable code for common network components. These modules should encapsulate best practices for:

• Implement network architectures within dedicated Terraform workspaces to maintain clear boundaries and focused management. This approach offers several benefits:
• Separation of Concerns: Manage network components independently from application resources, reducing the risk of unintended changes during application deployments.
• Specialised Access Control: Grant network administrators access to network workspaces without requiring access to application workspaces, enhancing security through role separation.
• Targeted Change Management: Manage changes to network infrastructure with appropriate approvals and testing without impacting application deployment workflows.
• Consistent State Management: Keep network state files separate from application state, reducing contention and improving performance for large-scale deployments.

By implementing this comprehensive approach to network topology and connectivity, organisations can create secure, scalable, and manageable networking foundations for their platform landing zones that meet both current and future requirements while maintaining security and compliance standards

• Network Security: Including NSG configurations, Azure Firewall rules, and Private Link implementations.
• Connectivity: Covering VNet peering, gateway configurations, and hybrid connection setup.
• Monitoring and Diagnostics: Implementing appropriate logging and monitoring for all network components.
• Compliance: Ensuring that network designs meet regulatory and organisational requirements through built-in policy validations.

Centralized security controls

• Use Azure Monitor and Microsoft Defender for Cloud: Provide comprehensive observability and security monitoring across all tiers of the N-tier architecture. Configure Azure Monitor to collect metrics and logs from all resources, with appropriate alerting thresholds established for each tier.
• Microsoft Defender for Cloud: Enable this with advanced threat protection features, especially for critical workloads in the Data Tier. Organisations should develop dashboards that provide visibility into the health and security posture of each tier, with appropriate access controls for different stakeholders.

SIEM integration

• Integrate Terraform and Vault with SIEM systems: Allow security event monitoring, log aggregation, and anomaly detection. Send these logs to Microsoft Defender for Cloud for enhanced security monitoring. Include correlation rules in SIEM integration to identify patterns indicative of security threats, with automated response playbooks for common scenarios. Terraform deployments should automatically configure the necessary log collection agents and forwarding rules to ensure comprehensive coverage.
• Enable HCP Terraform audit log streaming to SIEM systems: Capture detailed logs of all deployment activities. This ensures comprehensive visibility and compliance. Include information in log streams about who initiated deployments, what changes occur, and whether the system detects any policy violations. Retain these logs according to organisational retention policies and protect them from unauthorized access or modification.
• Use the SIEM integration to monitor security events: Detect anomalies, and respond to potential threats in real-time. Develop playbooks for security teams to respond to common scenarios, such as unauthorized configuration changes or suspicious authentication patterns. Leverage automation where appropriate to accelerate response times and reduce the burden on security analysts.

Sentinel policies

Use HashiCorp Sentinel to enforce security standards at deployment time to prevent applying non-compliant configurations. Sentinel policies should cover all critical security controls, including encryption requirements, network security, identity management, and compliance with regulatory frameworks. Organisations should develop a comprehensive library of policies that align with their security and compliance requirements, with appropriate testing before deployment to production environments.

Packer for hardened images

• Leverage HCP Packer to create consistent and secure machine images: Monitor and manage these images effectively using HCP Packer lifecycle management. Include security hardening steps, vulnerability scanning, and compliance checks in Packer workflows before approving images for use. Image creation processes should be fully automated, with appropriate approval gates for production images.
• Use HCP Packer to automate the creation of golden images, ensuring that all deployed instances meet security and compliance standards. Regularly update golden images to incorporate security patches and improvements, with version control and testing to prevent regressions. Verify that deployment pipelines use only approved images in production environments.

Application landing zone architecture

Red Dog application example

When building with the mindset of an application/developer team, the focus shifts to constructing subscriptions specifically designed to host applications. Our example demonstrates this approach using Microsoft's Red Dog application – a collection of containerized microservices deployed on an Azure Kubernetes Service (AKS) cluster. This illustrates how Terraform can build and manage multiple, event-driven architectural designs, and common open source back end services such as RabbitMQ and MongoDB.

Our Example Application resource:

Use our application architecture to create a comprehensive framework which addresses the following key concerns.

• Infrastructure automation - Using HCP Terraform or Terraform Enterprise to manage the complete application stack.
• Security and compliance - Use Vault and Sentinel for secrets management and policy enforcement.
• Service networking - Implement Consul for service discovery and mesh networking.
• Image management - Utilising Packer for consistent container image creation.

Each section below provides detailed guidance on implementing these principles within the Red Dog application context, offering both foundational and advanced integration approaches to create a production-ready application landing zone in Azure.

CI/CD and deployment workflows

Integrate Terraform with a DevOps tool such as Azure DevOps for deployment automation. This enables consistent, repeatable deployments across environments while maintaining appropriate governance controls. Pipeline configurations should include security scanning of Terraform code using tools like GitHub security before deployment.

OIDC and dynamic credentials

• OIDC-Based Federated Credentials: Use OIDC for secure authentication. This eliminates the need for long-lived credentials in deployment pipelines, reducing the risk of credential theft. Organisations should configure appropriate audience restrictions and validate token claims to prevent unauthorized access.
• Dynamic Short-Lived Credentials: Implement dynamic credentials for CI/CD pipelines. Make these valid only for the duration of the deployment process, reducing the risk associated with credential theft. Log and monitor credential issuance for suspicious patterns.
• Eliminate Static Credentials: Remove static credentials from deployment configurations. Retrieve any necessary secrets dynamically from secure storage such as HashiCorp Vault at runtime. Scan code repositories regularly to detect accidental inclusion of credentials.

Multi-stage deployments

• Progressive RBAC Assignment: Assign RBAC roles progressively through landing zone layers. As resources deploy, grant appropriate permissions to manage them. This ensures that permissions align with the current state of the environment and prevent unnecessary access to partially-deployed resources.
• Automated IAM Testing: Validate IAM configurations between deployment stages. This ensures that access controls work correctly before proceeding to the next stage of deployment. Include both positive and negative tests to verify that permissions work as intended.
• Cross-Subscription Identity Configurations: Manage identities across hub-spoke relationships. Hub subscriptions typically contain shared services that spoke subscriptions need to access. Implement appropriate trust relationships and monitor cross-subscription access patterns for anomalies.

GitHub Actions and Vault integration

By integrating HCP Vault with GitHub Actions, organisations can inject secrets directly into Terraform workflows. This uses a GitHub Action, which allows authentication with Vault and retrieval of secrets dynamically during the workflow. Implement role-based access control for Vault, ensuring that only authorized personnel can access sensitive information, and rotate credentials regularly to maintain a secure posture.

Resource organisation and tagging

Resource organisation and tagging is a large topic but key considerations are:

• Organize application components into logical resource groups based on functionality
• Implement resource boundaries that reflect security requirements and lifecycle patterns
• Establish dedicated workspaces in HCP Terraform to maintain the separation of concerns
• Configure cross-workspace dependencies using Terraform remote state data sources to create a composable application architecture
• Implement workspace-specific concurrency settings to optimize CI/CD pipelines for complex application deployments
• Leverage HCP Terraform Teams feature to map application component ownership to organisational structure
• Leverage HCP Terraform workspace tags for automatic and consistent resource identification
• Develop a comprehensive tagging strategy covering business unit, environment, cost center, and application identifiers
• Enforce tagging standards through Terraform to improve resource governance and cost allocation
• Create custom Sentinel policies to validate tag compliance across all application resources
• Implement programmatic tag inheritance using Terraform local values and dynamic block patterns
• Configure mandatory tag sets through HCP Terraform variable sets with enforcement at the organisation level

Modular IaC for microservices

When considering the Red Dog example, we have applied the following to modularise the environment:

• Create reusable Terraform modules for application-specific patterns like microservices, API gateways, and data layers
• Parameterise modules to support various deployment scenarios and application configurations
• Store and version modules in the HCP Terraform private registry for organisation-wide consistency
• Implement semantic versioning constraints with module consumption policies to enforce standardisation
• Create module composition patterns using a hierarchy of modules with defined interfaces and contracts Develop custom module test frameworks using Terraform test or external testing tools integrated with CI/CD
• Maintain separate state files for application components to reduce risk during changes.
• Implement workspace-based state isolation for different environments (dev/test/prod).
• Use HCP Terraform state locking to prevent concurrent modification issues.
• Configure automated state backups with version-specific retention policies.
• Use HCP Terraform encryption at rest for sensitive application configuration protection.

Integration with Kubernetes and service mesh

Integrate HashiCorp Vault to centrally manage application secrets and certificates, enabling dynamic secret generation for database credentials, API keys, and service tokens. Implement secret rotation policies that avoid application downtime, and deploy using the Terraform Vault Agent Injector in AKS to automatically inject secrets into Kubernetes pods. Use Vault's AppRole authentication method with response wrapping to ensure secure access, and configure the PKI secrets engine to generate and manage TLS certificates for application services. Define fine-grained access control by creating Vault policies with templated paths based on application instance identity, and establish application-specific policy sets using HashiCorp Sentinel to enforce security and compliance at deployment time. Design layered policy sets with graduated enforcement levels—advisory, soft-mandatory, and hard-mandatory—and develop complex policy logic using custom functions and third-party integrations. Set up automated policy tests with mocked plan data to validate policy effectiveness, and implement exemption workflows that include proper documentation and approval processes. Use HCP Packer to build standardized, hardened container base images with consistent security configurations across all application containers. Automate vulnerability scanning during image creation and integrate image pipelines with Artifactory or Azure Container Registry for secure distribution. Implement image signing and verification using Vault’s PKI infrastructure, employ multi-stage Packer builds with scanning gates between stages, and develop container hardening scripts aligned with CIS Benchmarks tailored to each application.

Advanced AKS Management Considerations:

• Deploy and configure production-grade AKS clusters using Terraform
• Implement node pool auto-scaling based on application workload patterns
• Manage Kubernetes resources consistently across multiple environments
• Configure the Vault CSI Provider for Kubernetes for transparent secret injection
• Implement GitOps workflows using Terraform and Flux/ArgoCD for application deployment
• Create custom Terraform providers for specialised Kubernetes resource types
• Develop node pool selection logic based on workload characteristics and resource requirements

GitOps and service mesh

• Implement secure service-to-service communication with mutual TLS
• Create consistent networking policies across all application components
• Deploy HashiCorp Consul for advanced service discovery and mesh networking
• Configure Consul Connect for zero-trust network security between application services
• Implement Consul intention graphs to visualise and manage service communication patterns
• Create service-level traffic splitting and circuit breaking for resilient application architectures
• Leverage Consul's L7 traffic management for advanced routing and observability

Private network access

Configure private endpoints for all PaaS services the application uses to ensure secure, internal access and eliminate exposure to the public internet. Establish secure network boundaries between application tiers, and implement fine-grained access controls at the network layer to minimize lateral movement. Deploy Consul gateways to manage secure ingress and egress traffic into the service mesh, and use network micro-segmentation through a combination of Consul intentions and Azure Network Security Groups (NSGs) to enforce strict communication policies. For globally distributed applications, configure cross-region service mesh federation to maintain consistent service discovery and communication across geographies. Additionally, create custom network authorization workflows that leverage Vault-issued certificates to provide strong identity-based access and encrypted communications within the environment.

Operational readiness

Zero downtime deployments

• Implement blue-green deployment patterns using Terraform workspaces.
• Manage traffic splitting and gradual rollout strategies.
• Automate rollback procedures for failed deployments.
• Configure Terraform run triggers to orchestrate multi-component application deployments
• Create custom deployment coordination using Terraform's external provider and webhook.
• Develop health-based promotion workflows with automated verification steps

Monitoring and observability

• Configure comprehensive monitoring using Azure Monitor and Application Insights
• Implement custom dashboards and alerting based on application-specific metrics
• Deploy centralised logging with correlation identifications for end-to-end request tracking
• Configure Vault telemetry integration with Azure Monitor for security operations visibility

Audit and compliance

• RBAC Assignment Tracking: Track RBAC assignments across all landing zone components. This enables comprehensive visibility into who has access to which resources and when the system granted that access. Changes to RBAC assignments should trigger notifications to security teams for review.
• Identity Change History: Maintain change history in Terraform state. This provides an audit trail of identity-related changes, including who made them and when. Preserve this history for compliance purposes and regularly review it for unauthorized changes.
• Comprehensive Audit Logs: Generate audit logs for access patterns. These should capture all authentication and authorization events, enabling detection of suspicious activities. Centrally collect logs, protect them from tampering, and retain them according to organisational retention policies.

With this approach to identity and access management in landing zones, platform teams can efficiently manage IAM at scale without requiring direct subscription access, enhancing both security and operational efficiency. As landing zones mature from initial deployment to full production, IAM configurations adapt seamlessly through code-based evolution rather than manual reconfiguration. The approach automatically generates comprehensive evidence of segregation of duties and least-privilege implementation, significantly streamlining compliance documentation and audit readiness. Additionally, the creation of just-in-time access patterns for application teams enables secure workload onboarding within clearly defined landing zone boundaries, balancing developer agility with security requirements.

Getting started

This guidance provides a structured approach to setting up a Landing Zone using Terraform. The high-level steps apply generally to CSP environments and the cloud-specific steps provide unique Azure details in a dedicated section.

High-level steps

1. Set Up Your HashiCorp Cloud Platform (HCP) Account
   • Register and configure your organisation in HCP.
   • Set up projects and workspaces for managing your infrastructure.
2. Configure Cloud Provider Credentials
   • Create service principals or IAM roles with appropriate permissions.
   • Securely store credentials in HCP Terraform variable sets.
3. Initialise Core Infrastructure Deployment
   • Select and configure foundational Terraform modules from the Terraform Registry.
   • Define core configuration parameters in your main Terraform files.
4. Establish Management Group/Organisational Unit Hierarchy
   • Define the root structure for your cloud environment.
   • Configure subscriptions or accounts aligned to your landing zone architecture.
5. Implement Baseline Security Controls
   • Configure cloud-specific policy assignments or Service Control Policies (SCPs).
   • Set up the RBAC model for platform access.
6. Create Core Networking Resources
   • Deploy a hub-spoke or virtual network topology.
   • Configure network security groups, routing, and connectivity options.
7. Set Up CI/CD Pipeline Integration
   • Connect HCP Terraform to your version control system (VCS).
   • Configure run triggers, approval workflows, and integration with CI/CD pipelines.
8. Validate Deployment
   • Execute the Terraform plan to verify the configuration.
   • Review resource changes before applying.
   • Apply the infrastructure and verify successful resource provisioning.
9. Implement Monitoring and Logging
   • Configure centralised logging and monitoring solutions.
   • Set up alert rules, dashboards, and SIEM integration.

Cloud specific details: Azure

1. Set Up Your HCP Account
   • Configure your HCP Terraform organisation and projects for Azure deployments.
   • Set up workspaces for platform and application deployments.
2. Configure Azure Credentials
   • Create a service principal in Azure Active Directory with appropriate permissions.
   • Store the service principal credentials securely in HCP Terraform variable sets.
3. Initialise Azure Virtual Machine (AVM) Deployment
   • Select the appropriate AVM module from the Terraform Registry.
   • Define core configuration parameters in main.tf.
4. Establish Management Group Hierarchy
   • Define the root management group structure in Azure.
   • Configure subscriptions and align them with the landing zone architecture.
5. Implement Baseline Security Controls
   • Configure Azure Policy assignments for governance and compliance.
   • Set up RBAC roles and permissions for platform access.
6. Create Core Networking Resources
   • Deploy a hub-spoke network topology using Azure Virtual Networks.
   • Configure Network Security Groups (NSGs), User-Defined Routes (UDRs), and Azure Firewall.
7. Set Up CI/CD Pipeline Integration
   • Connect HCP Terraform to your VCS (e.g., GitHub, Azure DevOps).
   • Configure run triggers and approval workflows for Azure deployments.
8. Validate Deployment
   • Execute terraform plan and terraform apply from HCP Terraform Cloud.
   • Verify successful resource provisioning in the Azure portal.
9. Implement Monitoring and Logging
   • Configure Azure Monitor and Azure Security Center for centralised logging and monitoring.
   • Set up alert rules, dashboards, and integrate with SIEM solutions.

By following these high-level steps and referring to the cloud-specific details, you can effectively set up and manage Cloud Landing Zones for both Azure and AWS using Terraform and HCP.

Appendices

Glossary of terms

Links and references

Below is a table of useful links and resources related to the technologies and concepts discussed in this document.

This table provides a convenient reference for readers to explore further details on the tools and services mentioned in the document. It enhances the document's usability by offering direct links to official documentation and resources.