Cloud Anywhere — Azure Setup Guide

Step-by-step instructions for your Azure infrastructure team to set up Cloud Anywhere using Azure Lighthouse.

---

Prerequisites Before starting, ensure you've read the Cloud Anywhere Quickstart Guide (the general guide) for an overview of the operating model and principles. This document covers Azure-specific implementation steps.

Target Architecture#

---

The following diagram shows the target state for a Cloud Anywhere deployment on Azure. All resources live inside a dedicated Azure subscription within your tenant.

Required Azure Resources#

---

dotCMS will provision these resources via Terraform within the dedicated subscription. If your organization already uses some of these (e.g., PostgreSQL, AKS), the dotCMS instances will be separate within the dedicated subscription.

Setup Steps#

---

Step 1: Create a Dedicated Azure Subscription (Customer)#

Create a new Azure subscription under your Enrollment Account or Management Group, dedicated to the dotCMS workload. This provides clean isolation from your other workloads.

# Azure CLI example
az account create \
  --offer-type "MS-AZR-0017P" \
  --display-name "dotCMS-CloudAnywhere" \
  --enrollment-account-name "<enrollment-account-id>"

Alternatively, create via the Azure Portal under Subscriptions → Add.

Step 2: Apply Policy Guardrails (Optional but Recommended) (Customer)#

Before granting access, apply Azure Policy to the subscription to enforce your governance requirements. Common policies include allowed regions, allowed resource types, and spending limits.

# Example: Restrict to specific Azure regions
az policy assignment create \
  --name "dotcms-allowed-regions" \
  --scope "/subscriptions/<sub-id>" \
  --policy "e56962a6-4747-49cd-b67b-bf8b01975c4c" \
  --params '{"listOfAllowedLocations": {"value": ["eastus", "eastus2"]}}'

This is how you maintain control. Azure Policy lets you constrain what dotCMS can create without blocking our ability to manage. This is the recommended pattern for MSP delegation — not restricting the delegation itself, but scoping what the delegate can do.

Step 3: Register dotCMS via Azure Lighthouse (Shared)#

Azure Lighthouse enables dotCMS to manage resources in your subscription from our own tenant, using service principals with RBAC roles that you define. dotCMS provides an ARM (Azure Resource Manager) template; your admin reviews and deploys it.

What dotCMS provides:

An ARM template specifying the RBAC roles needed and the service principals that will use them. Lighthouse enforces built-in restrictions: the Owner role is not supported, and roles with DataActions are blocked. Minimum roles typically include:

Note: Lighthouse intentionally prevents the service provider from holding Owner or unrestricted User Access Administrator roles. This is a security feature — dotCMS cannot escalate its own permissions or lock you out.

What you do:

# Deploy the Lighthouse registration ARM template
az deployment create \
  --name "dotcms-lighthouse-registration" \
  --location "eastus" \
  --template-uri "https://<dotcms-provided-template-url>" \
  --parameters \
    mspOfferName="dotCMS Cloud Anywhere" \
    mspOfferDescription="Managed dotCMS hosting in your Azure subscription"

What Lighthouse gives you: Full visibility in Azure Activity Log for every action dotCMS takes. Ability to review delegations at any time in Service providers → Service provider offers. One-click revocation — remove the delegation instantly with no dotCMS involvement.

Step 4: Networking Configuration (Shared)#

dotCMS provisions the VNet, subnets, and NSGs within the dedicated subscription. If you need VNet peering to connect to existing resources (e.g., corporate DNS, on-prem backends), this is coordinated jointly.

Discuss with your dotCMS engineering contact:

• IP address ranges / CIDR blocks for the dotCMS VNet (avoid overlap with existing VNets)
• Whether VNet peering is needed to your hub network
• DNS configuration (Azure Private DNS or your existing DNS infrastructure)
• Any required private endpoints for PaaS services

Step 5: Infrastructure Provisioning (dotCMS)#

Once Lighthouse is registered and networking is agreed, dotCMS provisions all infrastructure via Terraform through our CI/CD pipelines according to the scoped publishing architecture(s) defined during onboarding.

You will see all resource creation in your Azure Activity Log in real time. Provisioning timelines are scoped during the implementation plan based on project complexity.

Step 6: Validation & Handoff (Shared)#

dotCMS runs validation checks on all environments. Your team reviews resource compliance, confirms networking connectivity, and verifies that Azure Policy and Defender are active. After joint sign-off, the environments are ready for application onboarding.

Security Model — Why Lighthouse Is Safe#

---

Azure Lighthouse is Microsoft's first-party solution for managed service providers. It is not a back door — it is a front door with your key.

Pre-Setup Checklist for Your Azure Team#

---

• Confirm you can create a new Azure subscription under your Enrollment Account
• Identify the Azure AD Global Admin or Subscription Owner who will accept the Lighthouse registration
• Review your organization's Azure Policy requirements and decide which to apply to the dotCMS subscription
• Confirm Azure Lighthouse is not blocked by any tenant-level restriction (check: Azure AD → Properties → Manage Security defaults)
• Determine CIDR ranges for the dotCMS VNet (avoid overlap with existing address spaces)
• Decide if VNet peering to your hub network is needed
• Identify domains and DNS administrative access
• Confirm whether Microsoft Defender for Cloud will be enabled (recommended)
• Set up budget alerts on the new subscription
• Designate a technical contact from your Cloud Infrastructure team for the setup phase
• Schedule a kickoff call with dotCMS engineering

Addressing Common Concerns#

---

"Our enterprise risk team flagged Lighthouse as a security concern" We recommend a review call with your risk team where we can walk through: (1) Lighthouse is a Microsoft first-party feature, not a third-party tool, (2) your full audit and revocation controls, (3) how Azure Policy enforces your guardrails regardless of delegation, and (4) reference architectures from Microsoft's own documentation for regulated industries.

"Can we just give you remote desktop access instead?" Cloud Anywhere operates through automated systems (CI/CD, Terraform, monitoring agents) — not through humans sitting at desktops. Remote desktop access would mean dotCMS cannot guarantee SLAs: incident response depends on VDI availability, credential management, and network latency. Our operational reliability would be tied to your internal IT health rather than our own controlled systems.

"Can we run the Terraform for you?" For dotCMS to deliver on our managed-service SLAs, we need to execute infrastructure changes through our own CI/CD pipelines with automated testing, drift detection, and rollback. If changes require manual execution by your team, every update becomes a support ticket and our response times are bounded by your team's availability — not ours.

Typical Timeline#

---

---

dotCMS Cloud Anywhere — Azure Setup Guide · For customer cloud & infrastructure teams · v1.0