Deployment guide

This page provides a deployment guide for Omada Identity Cloud Private. It explains the deployment modes available, the shared prerequisites you need in place before deploying, and how to validate a completed deployment.

Deployment modes

Omada Identity Cloud Private supports two deployment approaches that provide different levels of control and automation: Installation Script mode and Raw IaC (Infrastructure as Code) mode.

Mode Selection

Start with Installation Script mode unless you have specific requirements for Raw IaC customization. You can transition to Raw IaC later if needed.

Installation Script mode (recommended)

Installation Script is the currently recommended and fully supported deployment mode. A single installation script (install.sh) orchestrates the entire deployment end-to-end, including preflight validation, toolchain bootstrap, infrastructure provisioning, artifact publishing, configuration validation, and node setup.

When to use:

• First-time Cloud Private deployments.
• Standard environment configurations.
• Teams that want a guided, validated deployment process.

For full step-by-step instructions, see Installation Script mode.

Raw IaC mode (advanced)

The Raw IaC mode provides direct access to Terraform and Ansible scripts for maximum control and customization. It is suitable for advanced users with IaC (infrastructure as code) expertise.

When to use:

• Significant customization or modifications required.
• Existing Terraform/Ansible infrastructure to integrate with.
• Internal tooling requires direct script access.
• Advanced users comfortable with IaC.

For full step-by-step instructions, see Raw IaC mode.

Prerequisites

Before proceeding, ensure the Azure tenant prerequisites are in place. For identity, quota, networking, and certificate requirements at the Azure tenant level, see Prerequisites in the Omada Identity Cloud Private overview.

System prerequisites

Installation Script prerequisites

The installation script handles toolchain setup automatically. Before running it, ensure the following:

Requirement	Details
OS	Ubuntu 24.04 LTS (native or WSL 2 on Windows)
RAM	Minimum 8 GB (recommended)
Disk space	Minimum 30 GB free
Azure CLI	Installed and authenticated (az login)
Network	Outbound HTTPS access to login.microsoftonline.com, api.github.com, and pypi.org (verified by preflight). Additional outbound access to Azure services and Docker registries is required but not preflight-checked.

The script installs Terraform, Ansible, kubectl, Helm, and other required tools automatically during the toolchain phase.

Raw IaC prerequisites

For reference, these are the minimal tooling requirements for the Raw IaC mode:

Tool	Version or other requirements
OS	Ubuntu 24.04
Terraform	1.13.4 (installer-pinned; IaC requires >= 1.1.0)
Ansible	13.0.0
Ansible Core	2.20.0
Azure CLI	2.66.0 or later
Python	3.12
Other	Defined within code (see scripts/install/ansible-requirements.txt for the full pinned set)

Networking prerequisites

Before deploying Cloud Private, ensure your Azure tenant has proper network infrastructure configured:

Virtual Network (VNet) planning

Each Cloud Private environment requires a dedicated VNet sized appropriately for your deployment. The default configuration allocates:

Environment	VNet CIDR	Recommended use
Development	10.1.0.0/20 (4,096 IPs)	Dev deployments
QA	10.2.0.0/20 (4,096 IPs)	UAT/staging environments
Production	10.3.0.0/20 (4,096 IPs)	Production workloads

Planning considerations:

• Ensure VNet CIDR ranges do not overlap with existing networks or on-premises networks
• If using VNet peering or ExpressRoute, plan non-overlapping address spaces
• Reserve the entire /20 even if not all IPs are immediately used
• Consider future expansion of subnets within the /20 range

Subnet configuration

Each VNet is subdivided into subnets for different functional areas. You must provision these subnets before deployment:

Subnet Name	CIDR	Total IPs	Purpose	Configuration
Compute (AKS)	/24	256	Kubernetes cluster nodes and pods	Network Security Group (NSG) required
Cloud App Gateway (CAG)	/28	16	Legacy system integration VM	NSG required; RDP access rules
App Service (delegated)	/27	32	App Service VNet integration	Delegated subnet; NSG required
Private endpoints	/26	64	Private Link connectivity	NSG recommended
Additional subnets	Variable	-	Reserved for future services	Plan expansion accordingly

Example subnet allocation for Dev (10.1.0.0/20):

10.1.0.0/24    > AKS Compute (Kubernetes nodes)
10.1.1.0/28    > CAG VM (Cloud App Gateway)
10.1.2.0/27    > App Service (delegated)
10.1.2.64/26   > Private endpoints
10.1.4.0/22    > Future expansion

Network Security Groups (NSGs)

NSGs control inbound and outbound traffic for each subnet. Deploy the following NSG configurations:

AKS Compute NSG Rules:

Direction	Priority	Name	Source	Destination	Port	Action	Purpose
Inbound	100	AllowFromWhitelistedIPs	Whitelisted IPs*	AKS subnet	All	Allow	Office/corporate network access
Inbound	110	AllowFromCAGPublicIP	CAG Public IP	AKS subnet	All	Allow	CAG to AKS communication
Inbound	120	DenyAllInbound	Any	Any	All	Deny	Default deny rule
Outbound	100	AllowAllOutbound	Any	Any	All	Allow	Required for image pulls, updates

Whitelisted IPs

*Configure the allowed source IPs based on your organization's network addresses (for example, office network ranges or VPN gateway IPs).

CAG VM NSG Rules:

Direction	Priority	Name	Source	Destination	Port	Action	Purpose
Inbound	100	AllowRDPFromOffice	Office VPN IPs	CAG subnet	3389	Allow	Remote desktop access
Inbound	110	AllowWinRMFromAzureDevOps	Azure DevOps service tag	CAG subnet	5985-5986	Allow	Azure DevOps automation
Inbound	120	DenyAllInbound	Any	Any	All	Deny	Default deny
Outbound	100	AllowAllOutbound	Any	Any	All	Allow	Enables communication with on-premises systems.

NSG rules for private endpoints (if enabled):

Direction	Priority	Name	Source	Destination	Port	Action	Purpose
Inbound	100	AllowFromComputeSubnet	AKS subnet	PE subnet	443	Allow	HTTPS to private services
Outbound	100	AllowToPrivateServices	PE subnet	Any	443	Allow	Private Link traffic

NSG Customization

The NSG rules above are templates. Customize the Whitelisted IPs and source ranges based on your organization's IP address allocation and security policies.

DNS configuration

External DNS (public endpoints):

• Register a DNS domain for your Cloud Private deployment (for instance, omada.<your-domain>.com).
• Create a DNS zone in Azure (via azure.microsoft.com or your registrar).
• After AKS deployment, an ingress IP will be assigned; create A records pointing to this IP.
• Obtain and import a valid TLS certificate for the DNS name.

Internal DNS (Azure-managed):

• Azure DNS automatically provides name resolution within the VNet.
• No configuration required; Kubernetes and service-to-service communication work automatically.

DNS Updates

DNS records are updated automatically during the Ansible deployment phase when update_private_dns_records is set to true in deployment-config.json (default). To manage DNS records manually, set this parameter to false.

Connectivity to on-premises networks

If your Cloud Private instance needs to integrate with on-premises systems (for example, AD, LDAP):

• VPN Gateway or ExpressRoute: Configure site-to-site connectivity from your Azure VNet to on-premises networks.
• Firewall rules: Ensure NSGs allow traffic from on-premises networks to the CAG VM subnet.
• DNS resolution: Configure hybrid DNS resolution so Azure resources can resolve on-premises hostnames.
• CAG Public IP: The CAG VM requires a public IP for VPN connectivity (enabled for Dev/QA, can be disabled for Prod with VPN/ExpressRoute).

Azure services and quota requirements

Before deployment, verify that your Azure subscription has sufficient quotas for all required resource types. For detailed quota tables covering compute, networking, AKS, and storage, see Subscription and quotas in the Omada Identity Cloud Private overview.

Certificates and Key Vault secrets

Azure Key Vault is used for secure storage and management of secrets, certificates, and sensitive configuration values. All certificates must be prepared and uploaded to Azure Key Vault before running the installation script: the script validates their presence during the secrets_validate phase and will stop if any are missing.

For required certificates, encoding instructions, automatically generated secrets, and a pre-deployment checklist, see Key Vault and secret management.

Deployment validation checklist

After deployment, run the health check script to validate that the environment is operational and ready for handover:

Tool: Bash shell

./scripts/health_check.sh --global-prefix <global-prefix>

The script automatically verifies the following:

Check	What is validated
Endpoint availability	All services (web apps, function apps, Enterprise Server) respond on their expected endpoints.
AKS pod readiness	Enterprise Server, RoPE, Timer, and CagOps pods each have at least one ready pod.
Component versions	All running components match the versions declared in variables.auto.tfvars.json.
Error logs	No errors in the OIS diagnostic log table (OIS_CL) in the last 30 minutes.
Service Bus dead letters	No dead-lettered messages across all Service Bus namespaces.

The script produces a PASS, WARN, or FAIL result per check, followed by an overall summary. The environment is ready for handover when the final result is PASS.

For full details on running the script and interpreting results, see Post-deployment health check.

tip

If the health check reports failures or warnings, see Collecting debug logs to gather diagnostic data for analysis or to send to Omada Support.