Cloud Application Gateway in Cloud Private

This page covers how the Cloud Application Gateway (CAG) is provisioned and used in Omada Identity Cloud Private, including the two CAG instances that are part of the standard deployment, and how to extend them for your systems.

tip

For general CAG concepts, configuration, and usage, see the Cloud Application Gateway section of the Omada Identity Cloud documentation.

Architecture overview

The Cloud Application Gateway consists of one set of Provisioning and Import Workers registered to a single instance group. The instance group determines which systems a CAG serves – any system configured in the Enterprise Server (ES) to use a given instance group is handled exclusively by the CAG registered to that group.

Cloud Private ships with two CAG instances, each mapped to a different instance group:

• The Windows CAG VM is registered to the omada-internal-group instance group, which serves the Omada Identity internal operations exclusively. It stores its private key inside the VM itself. It cannot be reused or redirected for other system integrations.

• The Linux CAG runs inside the AKS cluster, is registered to the Default instance group, and handles all other customer systems. It uses a dedicated Azure Managed Identity to authenticate against a CAG-specific Key Vault where its private key is stored – separate from the main application Key Vault.

known issue

Both the Linux and Windows versions of CAG are displayed with the same name in the System Heartbeats section (Setup > Operations Dashboard > System Heartbeats). While both versions function normally, you cannot distinguish between them by name alone in the UI.

The following diagram illustrates the architecture of the two CAG instances in a Cloud Private deployment:

The two CAG instances are independent – each serves its own instance group and neither can be redirected to the other's systems.

The following table summarizes the differences between the two CAG instances:

	Linux CAG	Windows CAG VM
Runs as	Two AKS pods (one import worker, one provisioning worker)	One Windows Server 2022 VM (import and provisioning both run on the same VM)
Instance group	Default	omada-internal-group
Purpose	General-purpose – for customer system integrations with Linux-compatible connectivity	Omada Identity internal use only – not supported for any other integration
Installed by	Installation script, Phase 1 (always runs)	Installation script, CAG phase (runs by default)

The subsequent sections provide more details about each CAG instance and how to extend the Linux CAG for additional instance groups if needed.

Linux CAG

The Linux CAG runs as a pair of Kubernetes pods on the AKS cluster – one import worker and one provisioning worker – and is registered to the Default instance group. Any system integration configured to use the Default instance group is handled by this CAG.

The Linux CAG uses Azure Workload Identity for authentication and stores its instance group key in a dedicated Azure Key Vault, separate from the main application Key Vault.

Connectivity compatibility

The Linux CAG supports connectors and collectors that are compatible with Linux. For the full list of supported connectivity options, see the Connectivity documentation.

Additional Linux CAG instances

If your deployment includes systems that require isolation into their own instance group, additional Linux CAG instances can be configured. Each additional instance runs as its own import/provisioning pod pair on the same shared AKS Linux node pool and is registered to a separate instance group.

note

Configuring additional Linux CAG instances is a supported option that requires changes to the deployment configuration before running the installer. It is not a self-service step – contact your Omada deployment team to discuss requirements.

Windows CAG VM

The Windows CAG VM is a single Windows Server 2022 virtual machine provisioned and configured automatically by the installer. It runs both import and provisioning workers and is dedicated exclusively to Omada Identity internal operations.

Using Windows-only connectivity

If you have a system integration that requires Windows-only connectivity, the built-in Windows CAG VM cannot be used – it is reserved for internal operations. In this case, deploy and register a separate CAG instance using the classic CAG package. Contact your Omada deployment team to obtain the package.

For installation instructions, see the CAG installation documentation.

Monitoring

CAG logs are available in the Log Analytics workspace (<global_prefix>-law) associated with your Cloud Private deployment.

info

The following Kusto (KQL) queries apply to the Linux CAG pods running on the AKS cluster. For Windows CAG VM logs, consult the VM directly.

Tool: Azure Log Analytics

Import worker logs:

ContainerLogV2
| where ContainerName contains "cag-import"

Provisioning worker logs:

ContainerLogV2
| where ContainerName contains "cag-provisioning"

note

For interactive pod and log inspection on the AKS cluster, third-party Kubernetes tools can be used alongside the Log Analytics queries above. Consult your internal tooling guidelines for approved options.