Configuring RoPE in Omada Identity Cloud Private

In Omada Identity Cloud Private, the Role and Policy Engine (RoPE) can be configured manually, through the engine configuration file.

This page explains how to modify (or replace) the EngineConfiguration.config file used by the RoPE pod running in the Omada Identity Cloud Private AKS cluster. It is written for operators who have kubectl access to the cluster (and, optionally, access to the backing Azure Storage account). No source code changes or pipeline runs are required.

Modifying RoPE configuration

To modify the RoPE configuration, place a file named exactly EngineConfiguration.config on the shared Azure Files store that the RoPE pod mounts at C:\OmadaRoPE\ConfigFilesMapped, then restart the RoPE deployment (see Method A, Step 4 or Method B, Step 3). The pod entrypoint detects the file and uses it instead of the built-in default.

info

By default, the current deployment runs one RoPE pod, but multi-instance scenarios are supported. The override file is shared across all pods via the shared Azure Files store, so all instances use the same configuration.

The following table explains the locations of the RoPE configuration file in the pod and on the backing Azure Files share:

Item	Value
In-pod mount path	C:\OmadaRoPE\ConfigFilesMapped\EngineConfiguration.config
Backing storage	Azure Files share, PVC <alias>configurationstore (ReadWriteMany)
File name (exact, case-sensitive)	EngineConfiguration.config
Built-in default (read-only reference, inside pod)	C:\OmadaRoPE\ConfigFileTemplates\EngineConfiguration.config
Currently active config (inside pod)	C:\OmadaRoPE\ConfigFiles\EngineConfiguration.config

tip

The <alias> is your environment/customer alias; it is also the Kubernetes namespace name. The RoPE deployment is named <alias>-rope. If unsure, run:

Tool: kubectl

kubectl get deploy -A | grep -i rope

Applying custom configuration

To apply custom configuration, two delivery methods are available:

• Method A (kubectl) is recommended because it requires no storage-account credentials.
• Method B (Azure Files) is provided for teams that prefer the Azure portal or Storage Explorer.

Prerequisites

To follow the instructions below, you need:

• kubectl configured against the Omada Identity Cloud Private AKS cluster.
• Permission to exec, cp, and rollout restart in the <alias> namespace.
• A text/XML editor.

Set these shell variables before running the commands below:

Tool: bash

ALIAS=<alias>                 # your environment alias / namespace
NS=$ALIAS
DEPLOY=$ALIAS-rope
POD=$(kubectl get pod -n $NS -l app=$ALIAS-rope -o jsonpath='{.items[0].metadata.name}')
echo "Namespace=$NS  Deployment=$DEPLOY  Pod=$POD"

Method A: via kubectl (recommended)

Step 1: Get a copy of the current configuration

Copy the currently-active config out of the running pod, so you have a valid baseline to edit:

Tool: kubectl

kubectl cp "$NS/$POD:OmadaRoPE/ConfigFiles/EngineConfiguration.config" ./EngineConfiguration.config

note

The container is Windows. With kubectl cp, use the path relative to the container root with forward slashes (OmadaRoPE/ConfigFiles/...), not a C:\... path.

Step 2: Edit the file

Open ./EngineConfiguration.config and make your changes. See What you can and cannot change for which parts are safe to modify and which are platform-managed.

Validate that the file is well-formed XML before uploading:

Tool: xmllint

xmllint --noout ./EngineConfiguration.config && echo "XML OK"

Step 3: Place the file on the shared store

Copy your edited file into the mounted share path. Writing here writes to the persistent Azure Files share, so it survives pod restarts:

Tool: kubectl

kubectl cp ./EngineConfiguration.config "$NS/$POD:OmadaRoPE/ConfigFilesMapped/EngineConfiguration.config"

Step 4: Restart the RoPE deployment

Tool: kubectl

kubectl rollout restart deployment/$DEPLOY -n $NS
kubectl rollout status  deployment/$DEPLOY -n $NS

Then proceed to Verifying the change took effect.

Method B: via the Azure Files share (Azure Portal / az CLI)

Step 1: Find the storage account and share backing the PVC

Tool: kubectl

PVC=$ALIAS"configurationstore"
PV=$(kubectl get pvc $PVC -n $NS -o jsonpath='{.spec.volumeName}')
kubectl get pv $PV -o jsonpath='{.spec.csi.volumeAttributes}{"\n"}'

The output contains the shareName and the storage account and resource group backing the dynamically provisioned Azure Files share.

Step 2: Upload the file to the share root

Using the Azure Portal (Storage account > File shares > share > Upload), Azure Storage Explorer, or the CLI:

Tool: Azure CLI

az storage file upload \
  --account-name <storageAccount> \
  --share-name  <shareName> \
  --source      ./EngineConfiguration.config \
  --path        EngineConfiguration.config

note

Upload the file to the root of the share (path EngineConfiguration.config, with no subfolder). The RoPE pod mounts the share root at C:\OmadaRoPE\ConfigFilesMapped.

Step 3: Restart the RoPE deployment

Tool: kubectl

kubectl rollout restart deployment/$ALIAS-rope -n $ALIAS
kubectl rollout status  deployment/$ALIAS-rope -n $ALIAS

What you can and cannot change

The override file fully replaces the default document. You control the entire contents except for a set of values that the pod entrypoint reapplies on every start. If you set these values in the file, they are overwritten from the pod environment or Kubernetes secret.

• Safe to customize:

  • The <extensions> block under <executor> (add, remove, or configure RoPE extensions). Changes here are also hot-reloaded within ~5 minutes without a pod restart.
  • Any executor or engine setting not listed in the platform-managed table below.

• Managed by Omada (not configurable via this file):

  These <executor> attributes (and the Application Insights extension) are forced by the entrypoint regardless of what your file contains:

  Attribute / item	Source	Notes
  loggingLevel	env loggingLevel (default 3)
  batchSize	env batchSize (default 1000)
  queueAllPeriodically	hard-coded true
  queuePeriodicallyWeekDays	hard-coded Saturday
  skipQueuingUnresolved	env skipQueuingUnresolved (default false)
  allowedRemoteIPMask	env allowedRemoteIPMask	platform networking
  deleteHistoricalCalculationsOlderThanDays	env delHistCalOTD (default 30)
  Application Insights telemetry extension	injected if absent	required for monitoring

  tip

  If you need to change one of the managed values, contact Omada. These values are set as environment variables in the RoPE pod – not in the configuration file – and can only be updated by Omada.

Example structure

Format: XML

<?xml version="1.0" encoding="utf-8"?>
<engineConfiguration>
  <executor batchSize="1000" loggingLevel="3" ...>
    <extensions>
      <!-- Customize freely; hot-reloaded ~every 5 minutes -->
      <add type="Your.Custom.Extension, Your.Assembly" />
      <!-- AppInsights extension is force-injected by the platform if missing -->
    </extensions>
  </executor>
  <!-- other engineConfiguration sections you may customize -->
</engineConfiguration>

tip

Start from the file you pulled in Method A, Step 1 rather than creating it from scratch, so you keep the correct schema for your product version.

Verifying the change took effect

Check the logs to confirm that the pod is using your override file:

1. Confirm the pod restarted and is healthy:

   Tool: kubectl

   kubectl get pods -n $NS -l app=$ALIAS-rope

2. Confirm the override was picked up — check the startup logs for the confirmation line:

   Tool: kubectl

   kubectl logs -n $NS deployment/$ALIAS-rope --tail=200 | grep -i "configuration"

• Taking configuration from Azure Storage: your override is in use. ✅
• Taking Standard Configuration: the file was not found; recheck the name and location (see the table in Modifying RoPE configuration). ⚠️

Live reload without restart

For an <extensions>-only change applied live, look for Configuration Change Detected / Restarting RoPE due to config change in the logs (appears within ~5 minutes; no pod restart required).

Reverting to default configuration

To revert to the built-in default configuration, remove the override file from the share and restart the RoPE deployment. The pod will then fall back to the built-in default (Taking Standard Configuration).

Method A (kubectl)

Tool: kubectl + PowerShell

kubectl exec -n $NS deploy/$ALIAS-rope -- powershell -Command \
  "Remove-Item C:\OmadaRoPE\ConfigFilesMapped\EngineConfiguration.config -Force"
kubectl rollout restart deployment/$ALIAS-rope -n $NS

Method B (Azure Files)

Tool: Azure CLI + kubectl

az storage file delete \
  --account-name <storageAccount> \
  --share-name  <shareName> \
  --path        EngineConfiguration.config
kubectl rollout restart deployment/$ALIAS-rope -n $ALIAS

Troubleshooting

Symptom	Likely cause	Action
Logs show Taking Standard Configuration after upload.	File is not at the share root, or the name is incorrect.	Ensure path is exactly EngineConfiguration.config at the share root (C:\OmadaRoPE\ConfigFilesMapped\ in-pod).
Pod crash-loops after change.	Malformed XML / invalid schema	Revert (see Reverting to default configuration), validate with xmllint --noout, fix, and reapply.
Could not apply new RoPE Configuration File in logs.	Invalid XML in the override during hot-reload	Fix the XML; the running engine keeps the last good config until corrected.
A managed attribute won't change.	It is platform-managed.	Contact Omada to change the corresponding environment variable.
Change to non-<extensions> section not applied.	Hot-reload only covers <extensions>	Restart the deployment (Method A, Step 4).