Guide: Setting Up a Restricted-Access OpenShift Cluster for SAP Edge Lifecycle Management (ELM) with Service Mesh 3.x

Part of: SAP Edge Integration Cell on Red Hat OpenShift

Table of Contents

• Overview
• Prerequisites
• Process Overview
• Step 1: Install Service Mesh 3.x Operators
• Step 2: Configure OpenShift Service Mesh 3.x
• Step 3: Register the Cluster in ELM
  • Initialize Edge Node
  • Component Resource Downloads (Deployment and Upgrades)
• Optional: Exposing the Istio Ingress Gateway via OpenShift Routes
• Advanced: Multiple Service Mesh Instances
• Appendix: EIC Before 8.41

Overview

This guide provides step-by-step instructions for onboarding a shared Red Hat OpenShift cluster into SAP Edge Lifecycle Management (ELM) using a restricted-privilege model. Instead of requiring full cluster-admin rights, ELM will use a dedicated Service Account with a precise, limited set of permissions. The official source of truth for this process is SAP Note 3618713, and this guide serves as an extension of the information provided therein.

Intended Audience: This document is for Red Hat OpenShift Cluster Administrators responsible for preparing the cluster environment.

Prerequisites

Before beginning this setup, ensure you have completed the following requirements:

Required Access and Credentials

• Cluster-admin privileges on the target OpenShift cluster (required for initial setup only)
• Access to SAP Note 3618713 (requires SAP S-user credentials)
• Authenticated oc CLI session to your OpenShift cluster

Software Requirements

• Red Hat OpenShift Container Platform 4.14+ (tested versions for Service Mesh 3.x)
• OpenShift CLI (oc) version matching your cluster
• Red Hat OpenShift Service Mesh 3.x Operators installed:
  • Red Hat OpenShift Service Mesh 3.x (required)
  • Kiali Operator (optional - for service mesh visualization)
  • Red Hat OpenShift distributed tracing platform (optional - for distributed tracing)

Downloaded Resources

Resources are downloaded directly from the ELM UI during the Initialize Edge Node and component deployment workflows. No manual download from the SAP Note is required.

EIC before 8.41: If you are using EIC before 8.41 (Edge Integration Cell Services before 1.34), see Appendix: EIC Before 8.41 for additional manual steps.

Process Overview

The setup process consists of three main stages:

1. Install Operators: Install the Red Hat OpenShift Service Mesh 3.x Operators.
2. Configure Service Mesh 3.x: Deploy and customize the Red Hat OpenShift Service Mesh 3.x to manage network traffic.
3. Register the Cluster in ELM: Download resources from the ELM UI to create namespaces and RBAC permissions, generate the Kubeconfig, and register the cluster as an Edge Node.

EIC before 8.41: The process requires additional manual steps for namespace creation, RBAC application, and kubeconfig generation. See Appendix: EIC Before 8.41.

Step 1: Install Service Mesh 3.x Operators

Before configuring any components, you must install the necessary operators.

Installation Method:

1. Log in to the OpenShift web console.
2. Navigate to Operators → OperatorHub.
3. Search for Red Hat OpenShift Service Mesh.
4. Select the Service Mesh 3.x version.
5. Click Install and follow the prompts to complete the installation.

Verify Installation:

Run the following command to confirm the operators are installed:

# Verify the required Service Mesh 3.x operator is installed
# Adjust the grep pattern if your operator name differs
oc get csv -n openshift-operators | grep -E "servicemeshoperator3|Service Mesh 3"

Step 2: Configure OpenShift Service Mesh 3.x

The SAP Note requires a service mesh to be present. This guide provides a specific, tested configuration for Red Hat OpenShift Service Mesh version 3.x. The architecture and configuration approach has changed significantly from Service Mesh 2.x.

Deployment Options:

This step shows the standard shared service mesh approach. For environments requiring enhanced security isolation or multi-tenancy, see Advanced: Multiple Service Mesh Instances for deploying a dedicated service mesh specifically for SAP workloads.

Note: The configurations provided below are general guidance for a standard Service Mesh 3.x deployment. If you need to make customized changes to the service mesh configuration, please refer to the official Red Hat OpenShift Service Mesh 3.x documentation for detailed customization options.

# --- Command 1: Create the Service Mesh control plane namespace ---
oc new-project istio-system

# --- Command 2: Create the CNI namespace ---
oc new-project istio-cni

# --- Command 3: Create the IstioCNI resource ---
oc apply -f - <<EOF
apiVersion: sailoperator.io/v1
kind: IstioCNI
metadata:
  name: default
  namespace: istio-cni
spec:
  namespace: istio-cni
EOF

Command 4: Create the Istio Control Plane

Choose the appropriate configuration based on your environment:

Standard Configuration (Direct Internet Access):

Use this configuration if your cluster has direct internet access without requiring a corporate proxy.

# --- Command 4a: Create the Istio control plane (standard) ---
oc apply -f - <<EOF
apiVersion: sailoperator.io/v1
kind: Istio
metadata:
  name: default
  namespace: istio-system
spec:
  namespace: istio-system
  values:
    meshConfig:
      discoverySelectors:
        - matchLabels:
            istio-discovery: enabled
EOF

Corporate Proxy Configuration (HTTP Proxy Required):

Use this configuration if your environment requires a corporate proxy for external connectivity (e.g., to reach SAP BTP, XSUAA, or other external services). This configuration enables DNS capture, which is required for proper proxy traffic routing through the Istio sidecar.

# --- Command 4b: Create the Istio control plane (with corporate proxy support) ---
oc apply -f - <<EOF
apiVersion: sailoperator.io/v1
kind: Istio
metadata:
  name: default
  namespace: istio-system
spec:
  namespace: istio-system
  values:
    meshConfig:
      discoverySelectors:
        - matchLabels:
            istio-discovery: enabled
      defaultConfig:
        proxyMetadata:
          ISTIO_META_DNS_CAPTURE: "true"
          ISTIO_META_DNS_AUTO_ALLOCATE: "true"
EOF

Why is DNS capture needed for corporate proxy? When SAP EIC applications connect to external services through a corporate proxy using HTTP CONNECT tunneling, the Istio sidecar (Envoy) must properly intercept DNS queries to route traffic correctly. Without DNS capture enabled, you may encounter ECONNRESET errors or 404 route_not_found responses.

Corporate Proxy ServiceEntry:

When using a corporate proxy, you must also create a ServiceEntry so that the Istio sidecar permits outbound TCP connections to the proxy. Replace the placeholders with your proxy's hostname, IP address(es), and port.

Note: Apply this ServiceEntry after the edgelm namespace is created in Step 3. You can return to this command after completing step 6 of the Initialize Edge Node procedure.

oc apply -f - <<EOF
apiVersion: networking.istio.io/v1alpha3
kind: ServiceEntry
metadata:
  name: allow-http-proxy
  namespace: edgelm
spec:
  hosts:
    - <proxy-hostname>
  addresses:
    - <proxy-IP>
  ports:
    - number: <proxy-port>
      name: tcp-proxy-tunnel
      protocol: TCP
  location: MESH_EXTERNAL
  resolution: NONE
EOF

Note: Add additional entries under addresses if your proxy has multiple IP addresses.

Complete the Service Mesh Setup

# --- Command 5: Label the control plane namespace for discovery ---
oc label namespace istio-system istio-discovery=enabled

Wait for Service Mesh Control Plane to Be Ready

The Service Mesh 3.x control plane takes 5-10 minutes to deploy and become ready. You must wait for it to be ready before proceeding to Step 3.

# Wait for Istio control plane to be ready (may take 5-10 minutes)
oc wait --for=condition=Ready istio/default -n istio-system --timeout=600s

# Verify all components are running
oc get pods -n istio-system
oc get pods -n istio-cni

Expected output: All pods should show Running or Completed status.

Step 3: Register the Cluster in ELM

This step uses the ELM UI to download Kubernetes resources (namespaces, CRDs, RBAC), apply them to the cluster, generate a Kubeconfig, and complete the Edge Node registration.

The resource handling is split into two phases:

1. Initialize Edge Node — Downloads the ELM resources (CRDs, ClusterRoles, edgelm namespace and RBAC). You also generate the Kubeconfig and upload it to complete registration.
2. Component Deployment — Each component has its own resource archive. See Component Resource Downloads below.

Critical: Apply Annotations After Each Resource Download

⚠️ IMPORTANT

Each downloaded resource archive contains namespace definitions that do not include the required SCC annotations or Service Mesh labels. You must apply these immediately after each resource download, following the instructions below.

This also applies to upgrades: updated resource archives will overwrite existing namespace metadata, so you must re-apply SCC annotations and Service Mesh labels after every upgrade.

Initialize Edge Node

1. In the ELM UI, start the Add an Edge Node process.
2. On the first stage, Provide Edge Node Details, enter a name for your Edge Node.
3. ⚠️ CRITICAL: Check "Restricted Access to Kubernetes cluster" checkbox
   • You MUST select this checkbox
   • Without this, ELM will attempt to use cluster-admin privileges and the deployment will fail
4. When you reach the Initialize Edge Node stage, click Download Kubernetes Resources to download the resource files.
5. Extract and apply all resources from the downloaded archive:

oc apply -f <path-to-downloaded-resources>/

6. Apply SCC annotations and Service Mesh labels to the edgelm namespace:

Note: At this stage, only the edgelm namespace resources are included. Additional namespaces are handled during component deployment — see Component Resource Downloads.

# Apply SCC annotation to edgelm namespace
oc annotate namespace edgelm openshift.io/sa.scc.supplemental-groups="67000/1000" --overwrite

# Label edgelm namespace for Service Mesh discovery and sidecar injection
oc label namespace edgelm istio-discovery=enabled istio-injection=enabled edgelm.sap.com/product=edgelm --overwrite

7. Generate the Kubeconfig file. The downloaded resources created the edgelm namespace and its RBAC bindings. Now create the service account and kubeconfig that ELM will use to authenticate to your cluster:

⚠️ CRITICAL: You must use the edgelm service account in the edgelm namespace.

The RBAC resources you just applied are specifically bound to this service account. Do not substitute your own service account or one from a different namespace.

# --- 1. Create the 'edgelm' service account in the 'edgelm' namespace ---
oc create sa edgelm -n edgelm

# --- 2. Create a secret to hold the long-lived service account token ---
oc apply -n edgelm -f - <<EOF
apiVersion: v1
kind: Secret
metadata:
  name: edgelm-kubeconfig-token
  annotations:
    kubernetes.io/service-account.name: edgelm
type: kubernetes.io/service-account-token
EOF

# --- 3. Extract the token and generate the Kubeconfig file ---
export SECRET_NAME_SA=edgelm-kubeconfig-token
export TOKEN_SA=$(oc get secret ${SECRET_NAME_SA} -n edgelm -ojsonpath='{.data.token}' | base64 -d)
oc config view --raw --minify > edgelm-kubeconfig
oc config unset users --kubeconfig=edgelm-kubeconfig
oc config set-credentials edgelm --kubeconfig=edgelm-kubeconfig --token=${TOKEN_SA}
oc config set-context --current --kubeconfig=edgelm-kubeconfig --user=edgelm

echo "Kubeconfig file 'edgelm-kubeconfig' has been generated successfully."

# Test the kubeconfig file to ensure it works
oc --kubeconfig=edgelm-kubeconfig auth can-i list pods -n edgelm

# Expected output: "yes" - this confirms the kubeconfig works correctly

8. Back in the ELM UI:

   1. Check the "I confirm that I have downloaded and applied resources" checkbox
   2. Upload the edgelm-kubeconfig file you generated in the previous step
   3. Enter a Context Password and click Download Bootstrapping File
   4. Proceed with the rest of the configuration as guided by the UI

9. If your environment requires a corporate proxy, select "Enable HTTP Proxy" and configure the proxy settings.

   • Note: Ensure you used the Corporate Proxy Configuration option in Step 2 when deploying the Istio control plane, and apply the ServiceEntry for your proxy now that the edgelm namespace exists.

Verification

After applying annotations, verify they were applied correctly:

# Verify SCC annotations on edgelm namespace
oc get namespace edgelm -o yaml | grep -A 2 "openshift.io/sa.scc"

# Expected output should show:
#   openshift.io/sa.scc.supplemental-groups: 67000/1000

Component Resource Downloads (Deployment and Upgrades)

Each deployed component has its own Kubernetes resources that must be downloaded and applied to the cluster. These resources are available from the All Deployments view in the ELM UI.

Components Requiring Resource Downloads

Component	Archive	Namespaces Created
IstioGateways	restricted-resources-IstioGateways-<version>.zip	istio-gateways
Edge Integration Cell Services	restricted-resources-Edge_Integration_Cell_Services-<version>.zip	edge-icell-services
Edge Integration Cell	restricted-resources-Edge_Integration_Cell-<version>.zip	edge-icell, edge-icell-secrets, edge-icell-ela

How to Download Component Resources

1. Navigate to All Deployments in the ELM UI
2. Locate the component (e.g., IstioGateways, Edge Integration Cell)
3. Click the "..." (actions menu) for the component
4. Select "Download Kubernetes Resources"
5. Apply the downloaded resources to your cluster: oc apply -f <path-to-component-resources>/
6. Immediately after applying, apply the SCC annotations and Service Mesh labels for the namespaces created by that component (see below)

SCC Annotations and Service Mesh Labels per Component

⚠️ CRITICAL: Each component's downloaded resources create namespaces. You must apply SCC annotations and Service Mesh labels immediately after applying each component's resources, before proceeding with deployment.

After applying IstioGateways resources:

# Apply Service Mesh labels to istio-gateways namespace
oc label namespace istio-gateways istio-discovery=enabled istio-injection=enabled edgelm.sap.com/product=edgelm --overwrite

After applying Edge Integration Cell Services resources:

# Apply SCC annotations to edge-icell-services namespace
oc annotate namespace edge-icell-services openshift.io/sa.scc.uid-range="1000000/1000" --overwrite
oc annotate namespace edge-icell-services openshift.io/sa.scc.supplemental-groups="1000002/1000" --overwrite

# Apply Service Mesh labels
oc label namespace edge-icell-services istio-discovery=enabled istio-injection=enabled edgelm.sap.com/product=edgelm --overwrite

After applying Edge Integration Cell resources:

# Apply SCC annotations to edge-icell namespace
oc annotate namespace edge-icell openshift.io/sa.scc.uid-range="10000/100" --overwrite
oc annotate namespace edge-icell openshift.io/sa.scc.supplemental-groups="1000/100" --overwrite

# Apply SCC annotations to edge-icell-ela namespace
oc annotate namespace edge-icell-ela openshift.io/sa.scc.uid-range="100000/1000" --overwrite
oc annotate namespace edge-icell-ela openshift.io/sa.scc.supplemental-groups="100002/1000" --overwrite

# Apply Service Mesh labels
oc label namespace edge-icell edge-icell-ela istio-discovery=enabled istio-injection=enabled edgelm.sap.com/product=edgelm --overwrite
oc label namespace edge-icell-secrets istio-discovery=enabled edgelm.sap.com/product=edgelm --overwrite

Checksum Validation

Each component includes a built-in checksum that validates whether the correct resources are applied to the cluster. If the resources do not match the expected version, the deployment or upgrade will fail.

Upgrade Requirements

⚠️ IMPORTANT: Resource Updates Required for Upgrades

When upgrading any component to a new version, you must download and apply the updated Kubernetes resources for that component. The system validates resource checksums — if the resources do not match the new version, the upgrade will fail.

Upgrade procedure:

1. Before upgrading a component in the ELM UI, download its latest Kubernetes resources
2. Apply the resources to the cluster
3. Re-apply SCC annotations and Service Mesh labels for the component's namespaces (see SCC Annotations and Service Mesh Labels per Component above)
4. Proceed with the upgrade in the ELM UI

Optional: Exposing the Istio Ingress Gateway via OpenShift Routes

If your environment does not have a LoadBalancer provider (e.g., MetalLB), you can expose the Istio Ingress Gateway using OpenShift Routes instead.

Important: For restricted-access deployments, the Route must be created in the istio-gateways namespace (not istio-system), since that is where the istio-ingressgateway service resides.

For full instructions — including Route YAML examples, the manual service patch workaround, support scope, traffic flow with external load balancers, and operational restrictions — see Exposing the SAP EIC Istio Ingress Gateway in the Installation Guide.

---

Advanced: Multiple Service Mesh Instances

OpenShift Service Mesh 3.x supports deploying multiple service mesh instances on a single cluster. This advanced pattern allows the entire SAP ELM / EIC stack to run in its own isolated service mesh, separate from other applications on the same cluster. This offers a higher degree of security and autonomy.

The Istio CNI configuration created earlier (in Step 2 of the main flow) is cluster-wide and is reused by both the shared and dedicated control planes. You do not need to create an additional CNI namespace or IstioCNI resource for the dedicated mesh.

For detailed information about this feature, refer to the official Red Hat documentation: Deploying multiple service meshes on a single cluster.

When to Use This Configuration:
- Multi-tenancy: When multiple teams or applications share the same cluster
- Security isolation: When SAP workloads require complete network isolation
- Independent lifecycle management: When different mesh versions or configurations are needed

Alternative Deployment: Dedicated SAP Service Mesh

In the standard flow, Step 2: Configure OpenShift Service Mesh 3.x creates a shared service mesh used by SAP workloads and potentially other applications.
If you require stronger isolation or separate lifecycle management, you can replace Step 2 with the following dedicated mesh configuration.
All other steps (Step 1, Step 3) remain the same.

Prerequisites for this alternative path:
- You have completed Step 1: Install Service Mesh 3.x Operators
- The Istio CNI namespace and IstioCNI resource from Step 2 have already been created

If these prerequisites are not yet fulfilled, go back to the main flow and complete the CNI setup in Step 2 before proceeding.

Step 2 (Alternative): Deploy an Independent Control Plane for SAP

# Create dedicated namespace for SAP mesh
oc new-project istio-system-sap-edge

Choose the appropriate Istio configuration based on your environment:

Standard Configuration (Direct Internet Access):

# Create dedicated Istio resource with unique selector (standard)
oc apply -f - <<EOF
apiVersion: sailoperator.io/v1
kind: Istio
metadata:
  name: sap-mesh-istio
  namespace: istio-system-sap-edge
spec:
  namespace: istio-system-sap-edge
  values:
    meshConfig:
      discoverySelectors:
        - matchLabels:
            istio-discovery: sap-edge-mesh
EOF

Corporate Proxy Configuration (HTTP Proxy Required):

# Create dedicated Istio resource with unique selector (with corporate proxy support)
oc apply -f - <<EOF
apiVersion: sailoperator.io/v1
kind: Istio
metadata:
  name: sap-mesh-istio
  namespace: istio-system-sap-edge
spec:
  namespace: istio-system-sap-edge
  values:
    meshConfig:
      discoverySelectors:
        - matchLabels:
            istio-discovery: sap-edge-mesh
      defaultConfig:
        proxyMetadata:
          ISTIO_META_DNS_CAPTURE: "true"
          ISTIO_META_DNS_AUTO_ALLOCATE: "true"
EOF

Assign SAP Namespaces to the Dedicated Mesh

After the application namespaces are created (during Step 3 resource downloads, or during Appendix Step A for EIC before 8.41), label them to join the dedicated mesh:

# Label the control plane namespace for discovery
oc label namespace istio-system-sap-edge istio-discovery=sap-edge-mesh --overwrite

# Assign all SAP-related namespaces to the dedicated mesh
oc label namespace edgelm edge-icell edge-icell-services edge-icell-secrets edge-icell-ela istio-gateways \
  istio-discovery=sap-edge-mesh istio.io/rev=sap-mesh-istio --overwrite

Important – Avoid Label Conflicts for Sidecar Injection

When using revision-based control planes, sidecar injection must be driven only by the istio.io/rev label.
Having both istio.io/rev=sap-mesh-istio and istio-injection=enabled on the same namespace can cause conflicts:

• istio-injection=enabled targets the default Istio control plane/webhook.
• istio.io/rev=sap-mesh-istio targets the dedicated SAP mesh revision.

If both are present, injection behavior becomes unpredictable and may fail entirely if the default webhook is not configured for this mesh.

To clean up existing labels and rely solely on the revision label, run:

# Remove the legacy istio-injection label from all SAP namespaces (if present)
oc label namespace edgelm edge-icell edge-icell-services edge-icell-secrets edge-icell-ela istio-gateways istio-injection-

# Optional: Verify that only istio.io/rev and istio-discovery remain
oc get namespace edgelm --show-labels

⚠️ Important — Resource application re-adds istio-injection=enabled:
The downloaded namespace definitions contain istio-injection: enabled as a label. When you apply resources during Step 3 (or the Appendix for EIC before 8.41), this will re-add the label you just removed, creating the conflict described above. You must re-run the label removal command after every resource application:

oc label namespace edgelm edge-icell edge-icell-services edge-icell-secrets edge-icell-ela istio-gateways istio-injection-

The istio.io/rev=sap-mesh-istio label on the namespaces ensures that sidecar injection for pods in these namespaces is handled by the dedicated SAP mesh control plane (sap-mesh-istio) instead of the shared mesh.
Optional: You can verify the available mesh revisions and confirm the sap-mesh-istio revision name by running:

oc get istiorevisions -n istio-system-sap-edge

Verify the Dedicated Mesh Deployment

# Wait for the dedicated control plane to be ready
oc wait --for=condition=Ready istio/sap-mesh-istio -n istio-system-sap-edge --timeout=600s

# Verify the dedicated control plane pods
oc get pods -n istio-system-sap-edge

# Verify namespace labels
oc get namespace edgelm -o yaml | grep -A 10 labels

After the dedicated control plane is ready and all namespaces are correctly labeled, continue with Step 3: Register the Cluster in ELM in the main flow.

Important Notes:
- This configuration creates isolation between SAP workloads and any other service mesh instances on the same cluster
- Use this approach when you need independent service mesh management or enhanced security isolation
- Both the shared and dedicated mesh approaches are supported — choose based on your cluster's multi-tenancy and isolation requirements

---

Appendix: EIC Before 8.41

If you are using EIC before 8.41 (Edge Integration Cell Services before 1.34), the namespace creation, RBAC application, and kubeconfig generation must be performed manually instead of through the ELM UI resource downloads described in the main flow.

Follow this sequence:

1. Complete Step 1 and Step 2 from the main flow above.
2. Then follow Steps A through D below instead of Step 3.

Step A: Prepare Namespaces

Create all required namespaces and apply the necessary security annotations and service mesh labels.

# --- Create all required namespaces ---
oc create namespace edgelm
oc create namespace istio-gateways
oc create namespace edge-icell
oc create namespace edge-icell-secrets
oc create namespace edge-icell-ela
oc create namespace edge-icell-services

# --- Label namespaces for Service Mesh discovery ---
oc label namespace \
  edgelm \
  edge-icell \
  edge-icell-services \
  edge-icell-secrets \
  edge-icell-ela \
  istio-gateways \
  istio-discovery=enabled

# --- Label namespaces for Service Mesh auto-injection ---
oc label namespace edgelm edge-icell edge-icell-ela edge-icell-services istio-gateways istio-injection=enabled edgelm.sap.com/product=edgelm
oc label namespace edge-icell-secrets edgelm.sap.com/product=edgelm

# --- Apply the necessary security annotations for SCCs ---
oc annotate namespace edgelm openshift.io/sa.scc.supplemental-groups="67000/1000" --overwrite
oc annotate namespace edge-icell openshift.io/sa.scc.uid-range="10000/100" --overwrite
oc annotate namespace edge-icell openshift.io/sa.scc.supplemental-groups="1000/100" --overwrite
oc annotate namespace edge-icell-ela openshift.io/sa.scc.uid-range="100000/1000" --overwrite
oc annotate namespace edge-icell-ela openshift.io/sa.scc.supplemental-groups="100002/1000" --overwrite
oc annotate namespace edge-icell-services openshift.io/sa.scc.uid-range="1000000/1000" --overwrite
oc annotate namespace edge-icell-services openshift.io/sa.scc.supplemental-groups="1000002/1000" --overwrite

Verify namespace setup:

# Verify all namespaces exist and are Active
oc get namespaces | grep -E "(edgelm|edge-icell|istio-gateways)"

# Expected output: 6 namespaces listed, all showing "Active" status

Step B: Apply Permissions (RBAC)

Download the resources.zip archive from SAP Note 3618713 and apply the resources manually.

Navigate to the extracted resource directory:

cd <path-to-extracted-resources>/

⚠️ Important: Do not use oc apply -f . to apply all files at once. The files role-edgelm-manage.yaml and rb-edgelm-manage.yaml do not contain a hardcoded namespace in their metadata and must be applied individually to each namespace using the -n flag. Running oc apply -f . would only create these resources in your current context namespace, leaving the other namespaces without the required permissions.

Apply cluster-wide resources:

oc apply -f cr-edgelm-cluster-admin.yaml
oc apply -f crb-edgelm-cluster-admin.yaml
oc apply -f crd-helms.yaml
oc apply -f crd-imagereplications.yaml
oc apply -f crd-replicationservices.yaml
oc apply -f crd-sapcloudconnectors.yaml
oc apply -f crd-sourceregistries.yaml
oc apply -f crd-systemmappings.yaml
oc apply -f crd-solacesoftwarebrokers.yaml

Apply namespace-scoped permissions:

Each namespace requires the common role-edgelm-manage.yaml and rb-edgelm-manage.yaml files, plus its own namespace-specific Role and RoleBinding files.

# --- edgelm namespace ---
oc apply -f role-edgelm-manage.yaml -n edgelm
oc apply -f rb-edgelm-manage.yaml -n edgelm
oc apply -f role-edgelm-admin.yaml -n edgelm
oc apply -f rb-edgelm-admin.yaml -n edgelm

# --- istio-gateways namespace ---
oc apply -f role-edgelm-manage.yaml -n istio-gateways
oc apply -f rb-edgelm-manage.yaml -n istio-gateways
oc apply -f role-istio-gateways-admin.yaml -n istio-gateways
oc apply -f rb-istio-gateways-admin.yaml -n istio-gateways

# --- edge-icell namespace ---
oc apply -f role-edgelm-manage.yaml -n edge-icell
oc apply -f rb-edgelm-manage.yaml -n edge-icell
oc apply -f role-edge-icell.yaml -n edge-icell
oc apply -f rb-edge-icell.yaml -n edge-icell
oc apply -f rb-edge-icell-admin.yaml -n edge-icell

# --- edge-icell-ela namespace ---
oc apply -f role-edgelm-manage.yaml -n edge-icell-ela
oc apply -f rb-edgelm-manage.yaml -n edge-icell-ela
oc apply -f role-edge-icell-ela.yaml -n edge-icell-ela
oc apply -f rb-edge-icell-ela.yaml -n edge-icell-ela
oc apply -f rb-edge-icell-ela-admin.yaml -n edge-icell-ela

# --- edge-icell-secrets namespace ---
oc apply -f role-edgelm-manage.yaml -n edge-icell-secrets
oc apply -f rb-edgelm-manage.yaml -n edge-icell-secrets
oc apply -f rb-edge-icell-secrets-admin.yaml -n edge-icell-secrets

# --- edge-icell-services namespace ---
oc apply -f role-edgelm-manage.yaml -n edge-icell-services
oc apply -f rb-edgelm-manage.yaml -n edge-icell-services
oc apply -f role-edge-icell-services.yaml -n edge-icell-services
oc apply -f rb-edge-icell-services.yaml -n edge-icell-services
oc apply -f rb-edge-icell-services-admin.yaml -n edge-icell-services

Verify RBAC application:

# Verify the common Role exists in all namespaces
for ns in edgelm istio-gateways edge-icell edge-icell-ela edge-icell-secrets edge-icell-services; do
  echo "--- $ns ---"
  oc get role edgelm-manage -n $ns
done

Step C: Generate Kubeconfig File

⚠️ CRITICAL: You must use the edgelm service account in the edgelm namespace.

The RBAC resources applied in Step B are specifically bound to the edgelm service account in the edgelm namespace. Using a service account from any other namespace will result in Insufficient privileges errors during Edge Node registration, because that service account will not have the required permissions.

Do not substitute your own service account or one from a different namespace — even if it has broad permissions elsewhere, it will not have the specific Roles and RoleBindings required by ELM.

These commands create the edgelm Service Account and generate a edgelm-kubeconfig file using a persistent, non-expiring token. ELM will use this file to authenticate to your cluster.

# --- 1. Create the 'edgelm' service account in the 'edgelm' namespace ---
oc create sa edgelm -n edgelm

# --- 2. Create a secret to hold the long-lived service account token ---
oc apply -n edgelm -f - <<EOF
apiVersion: v1
kind: Secret
metadata:
  name: edgelm-kubeconfig-token
  annotations:
    kubernetes.io/service-account.name: edgelm
type: kubernetes.io/service-account-token
EOF

# --- 3. Extract the token and generate the Kubeconfig file ---
export SECRET_NAME_SA=edgelm-kubeconfig-token
export TOKEN_SA=$(oc get secret ${SECRET_NAME_SA} -n edgelm -ojsonpath='{.data.token}' | base64 -d)
oc config view --raw --minify > edgelm-kubeconfig
oc config unset users --kubeconfig=edgelm-kubeconfig
oc config set-credentials edgelm --kubeconfig=edgelm-kubeconfig --token=${TOKEN_SA}
oc config set-context --current --kubeconfig=edgelm-kubeconfig --user=edgelm

echo "Kubeconfig file 'edgelm-kubeconfig' has been generated successfully."

# Test the kubeconfig file to ensure it works
oc --kubeconfig=edgelm-kubeconfig auth can-i list pods -n edgelm

# Expected output: "yes" - this confirms the kubeconfig works correctly

Verify kubeconfig:

# Verify the service account exists
oc get sa edgelm -n edgelm

# Verify the secret exists and contains a token
oc get secret edgelm-kubeconfig-token -n edgelm -o yaml | grep "token:"

# Test authentication with the generated kubeconfig
oc --kubeconfig=edgelm-kubeconfig get namespaces | grep edgelm

# Expected: Should list edgelm namespace, confirming authentication works

Step D: Register the Cluster in ELM

1. In the ELM UI, start the Add an Edge Node process.
2. On the first stage, Provide Edge Node Details, enter a name for your Edge Node.
3. ⚠️ CRITICAL: Check "Restricted Access to Kubernetes cluster" checkbox
   • You MUST select this checkbox
   • Without this, ELM will attempt to use cluster-admin privileges and the deployment will fail
4. When prompted for the Kubeconfig, provide the contents of the edgelm-kubeconfig file you just created.
5. If your environment requires a corporate proxy, select "Enable HTTP Proxy" and configure the proxy settings.
   • Note: Ensure you used the Corporate Proxy Configuration option in Step 2 when deploying the Istio control plane.
6. Proceed with the rest of the configuration as guided by the UI.

---

For Customer Reference: If you are looking for an implementation you can experiment with, an OpenShift Service Mesh 2.x version is available. Please note that this is provided for experimentation purposes only and is not officially supported by SAP. The Service Mesh 3.x implementation described in this guide represents SAP's future direction for this feature.