Installation Guidance: SAP Edge Integration Cell on OpenShift

Updated -

Part of: SAP Edge Integration Cell on Red Hat OpenShift

Table of Contents

Interactive Resources:

Note: Any scripts provided in this guide are provided as-is, without any form of support or warranty. All provided scripts can be modified by the customer at will.

1. Red Hat & SAP - Edge Solutions

What is it? - Solution Components and Definitions

1.1 Edge Lifecycle Management [ELM]

SAP Edge Lifecycle Management (ELM) is the solution used to deploy and register SAP payloads on customers' on-premise Kubernetes platforms, without SAP managing the infrastructure.

For detailed information, refer to the Administration Guide for SAP Edge Lifecycle Management.

1.2 Edge Integration Cell [EIC]

SAP Edge Integration Cell (EIC) is a hybrid integration runtime that enables businesses to manage APIs and execute integration scenarios within their private landscape, keeping sensitive data on-premise.

For more information, refer to:

Additional Resources:

2. Supported Versions & Access Model

2.1 Supported versions

The table below consolidates the component versions validated for running SAP Edge Integration Cell on Red Hat OpenShift (reflecting SAP Note 3247839 version 92, 2026-10-01). Always cross-check the latest version of that SAP Note, as supported versions are updated regularly.

Component Supported version(s) Notes
OpenShift Container Platform (OCP) 4.19 – 4.22 On-premise / self-managed
Azure Red Hat OpenShift (ARO) 4.19 – 4.22 Managed service
Red Hat OpenShift Service on AWS (ROSA) 4.19 – 4.22 Managed service
SAP Edge Integration Cell (EIC) 8.45, 8.46, 8.47 Active EIC versions per SAP Note 3247839
Red Hat OpenShift Service Mesh (OSSM) 3.1, 3.2, 3.3, 3.4 Required for the Restricted Access Model
PostgreSQL 15 External database (recommended)
Redis 6.x, 7.x External data store
Valkey 8.0–8.2 Open-source Redis-compatible alternative (compatible with Redis 7.2.x)
SAP HANA DB 2.0 SPS 08 Optional unified database + data store
Red Hat Quay 3.12 Optional local container registry
MetalLB via OperatorHub Optional LoadBalancer provider for bare-metal

Note: Currently, only container images for the operating system architecture linux/amd64 are supported. It is recommended to start new deployments with the highest available OpenShift version, as new versions are released frequently.

2.2 Deployment Solution

The following section defines the platforms that Edge Integration Cell [EIC] can run on - EIC is deployed using Edge Lifecycle Management [ELM]. ELM provides the delivery and management channel for EIC and other potential SAP payloads on the edge of SAP in the future.

Edge Integration Cell is released for use on the OpenShift versions listed in the Supported versions matrix above, with persistent storage provided by their respective dynamic volume provisioning.

In general, newer OpenShift versions are planned to be supported. SAP intends to perform compatibility tests on new OpenShift versions. Support for new versions will be communicated via this SAP Note.

As older OpenShift [OCP] versions phase out according to the OpenShift Container Platform Life Cycle Policy, they cannot undergo verification for compatibility with newer patches of Edge Integration Cell. Consequently, the minimum required OpenShift version rises over time. The target is to support four Kubernetes versions if available on a platform. Starting from OpenShift 4.19, all major OpenShift releases (including odd-numbered versions) are validated.

OCP best architectural practices can be found in the documentation here.

2.3 Cluster Access Models for ELM Registration

When registering an OpenShift cluster with SAP Edge Lifecycle Management (ELM), you can choose between two security models:

Full Cluster-Admin Access (Default)

The traditional approach where ELM uses a kubeconfig with full cluster-admin privileges to manage the cluster. This is the simplest setup but grants broad permissions.

  • OpenShift 4.19 onwards On-premise. Details can be found here.

Restricted Access Model (Supported)

A security-enhanced approach that uses fine-grained Role-Based Access Control (RBAC) instead of full cluster-admin rights. This model:

  • Uses a dedicated Service Account with precisely scoped permissions
  • Requires pre-configured namespaces and Red Hat OpenShift Service Mesh 3.x (3.1, 3.2, 3.3, 3.4)
  • Is suitable for shared/multi-tenant cluster environments
  • Provides enhanced security isolation
  • Is fully supported by SAP for production deployments

Important Notes:

3. Prerequisites for installing SAP Integration Suite Edge Integration Cell

Before you begin, make sure you have the following in place:

  • SAP S-user ID — required to access SAP software, SAP Notes, and documentation.
  • Reviewed the relevant SAP documentation:
  • A supported OpenShift cluster — see Supported versions.
  • A container registry — either the OpenShift-integrated registry, an external registry, or a local Quay instance for disconnected deployments.
  • oc (OpenShift CLI) authenticated to your cluster.
  • Reviewed the storage, networking, and external-service requirements in the sections below.

3.1 About this section

This section adapts and rewords material from SAP's official documentation and SAP Notes, interleaved with guidance specific to running SAP Edge Integration Cell on Red Hat OpenShift. SAP-sourced content has been edited for clarity rather than quoted verbatim, so always confirm the authoritative details in the linked SAP sources.

For the most accurate and up-to-date information, please refer to the Latest SAP Notes.

3.2 Synopsis

You plan to install SAP Integration Suite Edge Integration Cell on Openshift Container Platform, this may be a fresh installation, or incorporated into an existing deployment.

NB: For the respective landscape variant, make sure you have deployed the right Kubernetes and storage infrastructure.

3.3 Networking

Best Practices for OCP Networking can be found here configuration will vary depending on client needs and deployment architecture.

In OpenShift, a diverse array of Container Network Interface (CNI) solutions is available, including the default OVN-Kubernetes and SDN. Effective planning is important when configuring IP addressing and determining subnet sizes to efficiently accommodate the anticipated number of pods during OpenShift installation. Comprehensive network configuration parameters during OpenShift installation are provided for detailed guidance. After the installation, it is also flexible to expand the cluster network range if you need more IP addresses for additional nodes.

To ensure external accessibility to the Istio Ingress Gateway—a core component of the EIC solution—the recommended approach is to configure a LoadBalancer service. For environments like bare-metal clusters, MetalLB provides a robust LoadBalancer solution tailored for infrastructures without cloud-native load balancers, enabling fault-tolerant access to applications via external IP addresses. Alternatively, OpenShift Routes can be used to expose the Ingress Gateway, though this approach has architectural differences and operational restrictions compared to a LoadBalancer service. See Exposing the SAP EIC Istio Ingress Gateway for details on support scope and technical considerations.

MetalLB can be installed through OpenShift OperatorHub. Detailed information on MetalLB can be found here.

The SAP Edge Integration Cell leverages the SAP Cloud Connector to establish a communication channel with the SAP Business Technology Platform (BTP) in the cloud. This configuration requires the Integration Cell to initiate an internet connection, as it serves as a vital link between SAP BTP applications and on-premise systems.

The SAP Cloud Connector operates as a reverse invoke proxy, enabling secure and efficient communication between the on-premise network and SAP BTP. Note that an air-gapped network setup is not applicable in this scenario.

For more detailed information, please refer to the official SAP documentation on the SAP Cloud Connector.

Note: If you are registering the edge node using the External Cloud Connector option, the Cloud Connector requires two separate system mappings (OpenShift API and EIC local API) plus matching ELMO and EIC field values. For a field-by-field walkthrough, see Configuring EIC with an External Cloud Connector.

3.4 Storage

Storage configuration on OpenShift depends on the underlying infrastructure. By default, OpenShift installs CSI drivers and creates storage classes for most backing storage during installation; for background, see the OpenShift Container Platform storage overview and the list of supported CSI drivers. The per-component storage requirements are summarized in the table below.

Worker nodes should use ephemeral disks for the operating system (the default in most installations), with an ephemeral OS disk of at least 80 GB. Each node must also leave enough ephemeral storage for temporary runtime data — particularly when large messages are processed through the stream cache — and the Edge Integration Cell worker pod defaults to a 10 GiB ephemeral storage limit. As a practical baseline, allocating 120 GB of disk per OpenShift node provides ample capacity for these workloads.

For persistent storage, use disk-based storage classes (block storage or iSCSI) rather than file-based storage or NFS; the only exception is the RWX shared-storage use case described below, and the Message Service in particular does not support NFS. Make sure any storage class you use supports volume expansion — otherwise persistent volumes cannot be grown later. You can assign dedicated storage classes to the Message Service, PostgreSQL, and Redis for non-productive deployments; if you do not, the cluster's default storage class is used.

A few EIC components need RWX (ReadWriteMany) shared storage: the optional shared volumes for Java thread and heap dumps and for the SNC library (SAPCRYPTOLIB) used by the RFC Adapter, and — when Enable Shared File System is set to true during deployment — the shared file system itself. This is the one exception to the block-storage guidance above. On OpenShift Data Foundation, the ocs-storagecluster-cephfs storage class (described below) provides these RWX volumes; where ODF is not used, a managed file-storage service such as AWS EFS can serve the same purpose. RWX shared storage must use the Immediate volume binding mode.

Note: The Enable Shared File System option is chosen during EIC solution deployment. It preserves traces and dumps (SAP recommends enabling it for production) and is required to use Diagnostics on the Edge Integration Cell. It cannot be changed after the initial deployment, so decide whether you need it — and provision the RWX storage class above — before you deploy. See Deploy the Edge Integration Cell Solution.

Any CSI storage backend can be used, provided it supplies the access modes EIC requires — RWO for the components that need it, and both RWO and RWX where shared storage is involved (see the RWX components above). Before deploying, verify that your existing storageClass provides the features EIC and its external services require (see the CSI persistent storage documentation); if it does not, OpenShift Data Foundation (ODF) can be installed on top of the existing storage service. Many clusters also come pre-configured with default block storage classes — for example, thin on VMware vSphere, standard-csi/ssd-csi on GCP, or gp3-csi/gp2-csi on AWS — which can be used as block storage.

Installing ODF lets you use the SSD disks attached to your nodes (or an existing storage class) as backing storage, and provides unified storage classes for block, file, and object storage for a consistent EIC deployment across environments. With ODF, the ocs-storagecluster-ceph-rbd storage class provides RWO/RWX block volumes and can be set as the default storage class; ODF supports both RWO and RWX access modes for filesystem and block volumes, and allows expanding Persistent Volume Claims for added flexibility. During EIC deployment, the ocs-storagecluster-cephfs storage class — which offers RWX filesystem volumes — can serve as the Shared File System Storage Class when 'Enable Shared File System' is set to 'true'.

ODF's S3-compatible object storage (via the Multicloud Object Gateway) is also useful beyond EIC itself: the Day 2 logging (LokiStack) and distributed tracing (Tempo) stacks both require an object store, and ODF can provide it in-cluster. See Day 2 Operations. (Cluster monitoring with Prometheus uses block storage, not object storage.)

Note: When using ODF CephFS for the Shared File System Storage Class with full cluster-admin deployments, you may encounter "Permission Denied" errors due to SELinux MCS label conflicts. See Red Hat KB 7137220 for the resolution. This issue does not affect Restricted-Access deployments.

The table below provides an overview of the storage requirements for various components, detailing their access modes, whether they are optional, any relevant comments, and the required persistent volume sizes:

Component Access Mode Comments Persistent Volume (GiB)
Local Services - PostgreSQL database RWO Non-productive 50
Local Services - Redis data store RWO Non-productive 10
Monitoring - Prometheus (Optional) RWO 20
Shared storage - Java thread, heap dumps (Optional) RWX 50
Shared storage - SNC library (SAPCRYPTOLIB) for RFC Adapter (Optional) RWX 1
Message Service Tier 100 RWO Non-productive 100
Message Service Tier 250 (VPN/System) RWO 100
Message Service Tier 1K RWO 350
Message Service Tier 10K RWO 350
Crunchy PostgreSQL RWO 100
Redis Enterprise RWO 60

3.5 Additional services consumed by Edge Integration Cell

3.5.1 Deployment best practices

Additional Services, external to SAP Edge Integration Cell, are required to maintain state - these services are commonly deployed by many customers on existing OCP clusters.

There are three types of services required:

  1. Database Service - Used for storing local persistent data
    • PostgreSQL (recommended for most deployments)
    • SAP HANA DB (supported alternative - see SAP HANA DB Service)
  2. [Optional] Data Store Service - Used for caching state and persisting data of SAP EIC API proxy
  3. [Optional] Local Container Registry - Quay is a SAP certified solution as a local container registry for disconnected implementation and is used by Edge Lifecycle Management to deploy and manage the Edge Integration Cell (Quay is included as part of OCP - more information here)

PostgreSQL, Redis, and Quay can be easily deployed and managed using the Operator Framework. Valkey can be deployed using Helm charts or standard Kubernetes manifests. For POC environments, external database and data store services can be optional — SAP EIC deploys self-contained pods if they are left unconfigured during installation. However, this is not recommended for production.

Note: As an alternative to PostgreSQL and Redis/Valkey, SAP HANA DB can serve as both the database and data store service. For detailed information, see SAP Note 3247839.

Red Hats' OperatorHub is the web console interface that OCP cluster administrators use to discover and install Operators. With one click, an Operator can be pulled from its off-cluster source, installed and subscribed on the cluster, and made ready for engineering teams to self-service manage the product across deployment environments using Operator Lifecycle Manager [OLM]. OLM also supports interactions from command-line tools, similar to managing normal Kubernetes resources. More information on the Operator Hub and Operators can be found here

3.5.2 PostgreSQL Service

PostgreSQL version 15 is supported as the external database, with minimum requirements of 1 CPU and 2 GiB of memory. For backup and restore options, see the PostgreSQL Backup and Restore documentation.

One naming constraint applies: the database name must be lowercase, due to a current restriction in metadata handling. Refer to the PostgreSQL documentation for creating a schema and handling the schema search path, and avoid the public schema as a general PostgreSQL best practice.

3.5.2.1 Enterprise PostgreSQL operators

SAP Edge Integration Cell works with any conforming PostgreSQL 15 database. On OpenShift, you can deploy and manage it with an enterprise-grade operator. Two operators available through the Red Hat Ecosystem Catalog / Marketplace are:

Each vendor supports its operator under its own subscription terms, which typically cover bug fixes, security patches, updates, and technical support — see Crunchy's Terms of Use and EDB's respective terms. The choice of operator is yours; EIC only requires a conforming PostgreSQL 15 endpoint with the privileges listed below.

If you are using OpenShift deployed on hyperscalers, you can also use managed database services such as:

  • Azure: Azure Database for PostgreSQL
  • AWS: Amazon RDS for PostgreSQL

PostgreSQL connectivity and user credentials are required during solution deployment. The database user needs GRANT ALL on the schema, plus permission to create database objects such as tables and indexes in addition to standard SQL operations.

3.5.2a SAP HANA DB Service

SAP HANA DB 2.0 SPS 08 is currently supported as an external database and data store service for SAP Edge Integration Cell.

SAP HANA DB can serve as both the database and data store service:
- Storing local persistent data (database function)
- Caching state and persisting data of SAP EIC API proxy (data store function)

Important Notes:
- For minimum sizing requirements, please refer to SAP HANA documentation
- For backup and restore options, please refer to SAP HANA documentation
- DB connectivity and user information is required during solution deployment
- For detailed prerequisites and configuration, see SAP Note 3247839

Note: SAP HANA DB may be an appropriate choice for organizations already using SAP HANA in their landscape.

Preparing SAP HANA

SAP HANA runs side-by-side, external to the OpenShift cluster. The following steps prepare a dedicated tenant database, user, and schema for Edge Integration Cell. Replace the example passwords and names with your own.

  1. Connect to the system database and create a tenant database:
hdbsql -i 00 -d SYSTEMDB -u SYSTEM -p <systemdb-password>
CREATE DATABASE EICDB SYSTEM USER PASSWORD "<tenant-system-password>";
  1. Connect to the new tenant database, then create the EIC user and schema:
hdbsql -i 00 -d EICDB -u SYSTEM -p "<tenant-system-password>"
CREATE USER EICUSER PASSWORD "<eic-user-password>" NO FORCE_FIRST_PASSWORD_CHANGE;
CREATE SCHEMA EIC;
GRANT ALL PRIVILEGES ON SCHEMA EIC TO EICUSER;

Note: The EIC user requires privileges to create database objects (tables, indexes) in addition to standard SQL operations. See SAP Note 3247839 for the authoritative privilege requirements.

  1. Retrieve the SQL port of the tenant database (needed as the HANA DB port during deployment):
SELECT SQL_PORT FROM SYS.M_SERVICES WHERE SERVICE_NAME='indexserver';
  1. Gather the HANA DB root certificate, which is required to deploy EIC with SAP HANA as the database/data store. It is stored on the HANA node under $SECUDIR, typically named clientpki_<SID>.cer:
cd $SECUDIR

When deploying EIC with SAP HANA, supply the following values (example from the steps above):

Field Example
HANA DB Node <hana-host>:<SQL_PORT>
HANA DB Name EICDB
HANA DB Schema EIC
HANA DB Username EICUSER
HANA DB Password <eic-user-password>

3.5.3 Redis / Valkey Service

Redis 6.x and 7.x and Valkey 8.0–8.2 (compatible with Redis 7.2.x) are supported as the external data store. For backup and restore options, see Redis persistence or Valkey persistence.

3.5.3.1 Enterprise Operator Solution REDIS offered by Redis Enterprise via Red Hat Marketplace

Redis Enterprise is available as an operator through the Red Hat Marketplace; see the Redis Enterprise Software documentation for deployment details. This solution is directly backed by the Redis Labs team, detailed in Appendix 1 of the Redis Enterprise Software Subscription Agreement. The agreement categorizes support services into Support Services, Customer Success Services, and Consulting Services, offering assistance from basic troubleshooting to advanced consultancy and ongoing optimization tailored to diverse customer needs.

If you are using running OpenShift on hyperscalers, you can use managed data store services such as:

3.5.3.2 Valkey

Valkey is an open-source, high-performance key/value data store forked from Redis. It is wire-protocol compatible with Redis, making it a drop-in replacement for the data store service. Versions 8.0–8.2 (compatible with Redis 7.2.x) are supported, with minimum requirements of 1 CPU and 1 GiB of memory.

Valkey can be deployed on OpenShift using Helm charts or standard Kubernetes manifests; for more information, see the Valkey documentation.

If you are using OpenShift on hyperscalers, you can use managed services compatible with Valkey such as:

3.5.4 Quay Container Image Registry Service

Quay is a secure, scalable container registry that integrates seamlessly with OpenShift, providing robust image storage, management, vulnerability scanning, and distribution capabilities for your containerized applications. It is fully supported by Red Hat.

4. Installation

For more detailed instructions and troubleshooting tips, refer to the official SAP documentation. This resource provides in-depth guides, best practices, and FAQs to help you successfully install and manage your SAP Edge Integration Cell. Additionally, watch the following video to see all the necessary steps for the initial setup of the Edge Integration Cell: Initial Setup of SAP Edge Integration Cell.

4.1 Installing OpenShift

Before installing OpenShift Container Platform, choose between self-managing the cluster or using a managed service. Self-management involves deploying OpenShift on your chosen infrastructure, while managed services include options like OpenShift Dedicated, OpenShift Online, and services on Azure, AWS, etc. For detailed installation preparation, refer to OpenShift Installation Preparation.

4.2 Installing OpenShift Data Foundation (Optional)

For detailed instructions on installing OpenShift Data Foundation across various platforms, please refer to the official documentation at Red Hat OpenShift Data Foundation 4.18.

4.3 Installing External Services

Note: This step may be optional for a POC. You might not need to set up external database and data store instances. If you don't enable or configure them during the SAP Edge Integration Cell (EIC) installation, EIC will automatically deploy self-contained Postgres and Redis pods within its own service namespace.

Database and Data Store Options:
- PostgreSQL + Redis (Recommended for most deployments) - See Installing CrunchyData Postgres service and Installing Redis Enterprise Service
- PostgreSQL + Valkey (Alternative) - Valkey is an open-source, Redis-compatible data store. See Redis / Valkey Service
- SAP HANA DB (Alternative option) - Serves as both database and data store. For detailed information, see SAP Note 3247839 and SAP HANA DB Service

4.3.1 Installing CrunchyData Postgres service

To install the CrunchyData Postgres service on OpenShift, follow the detailed instructions provided in the CrunchyData Postgres Operator Installation Guide. This guide offers steps to deploy and configure the CrunchyData Postgres Operator, ensuring a smooth setup of your PostgreSQL environment within the OpenShift platform. For additional resources, including example scripts and YAML configurations for setting up a test PostgreSQL instance, refer to SAP Edge Integration Cell External Services Examples.

4.3.2 Installing Redis Enterprise Service

For detailed instructions on installing Redis Enterprise Service on OpenShift, consult the Redis Enterprise Operator Installation Guide. This guide provides step-by-step procedures to effectively deploy and configure the Redis Enterprise Operator, ensuring optimal setup and integration of Redis Enterprise within your OpenShift environment. Additionally, for example scripts and YAML configurations to set up a test Redis instance, consult the SAP Edge Integration Cell External Services Examples.

4.4 Installing Quay container registry (Optional)

If you need to set up a local Quay container registry to facilitate the installation of EIC in a disconnected environment, you can follow the detailed instructions in the Red Hat Quay Operator Installation Guide.

Wiring the registry into the Edge Node: Installing Quay only provides the registry — you must also configure ELM to use it. In the SAP Edge Lifecycle Management UI, when adding or initializing the Edge Node, enable Replicate Container Images and set the Local Container Registry URL to your registry host plus the target project (for example, registry.example.com/eic-project). Enable Authentication and provide the registry user name and password. If the registry uses a self-signed certificate or a certificate from an untrusted CA, select the non-trusted certificate option and upload the registry certificate.

4.5 Configuring Proxy (Optional)

If you wish to use a proxy for running the ELM/EIC on OpenShift, follow the instructions below to configure the HTTP(S) proxy settings.

Configuring the HTTP(S) Proxy is crucial for different components in the setup. The corresponding No Proxy settings are treated differently by each component:

  • management host (or jump host)
  • OpenShift cluster
  • ELM/EIC

The following sections assume the following configuration:

  • Cluster's base domain: example.com
  • Cluster name: foo (API is listening at api.foo.example.com:6443)
  • Local proxy server: http://proxy.example.com:3128
  • Management host's hostname: jump.example.com (add its shortname jump to the NO_PROXY settings)
  • Local network CIDR: 192.168.128.0/24
  • OpenShift's service network default range: 172.30.0.0/16

4.5.1 Configuring HTTP Proxy on the management host

Export the Proxy environment variables on your management host according to your Linux distribution. For RHEL, follow the instructions on applying a system-wide proxy. For example, in BASH:

sudo tee /etc/profile.d/http_proxy.sh > /dev/null <<EOF
export http_proxy=http://proxy.example.com:3128
export https_proxy=http://proxy.example.com:3128
export no_proxy=localhost,127.0.0.1,jump,.example.com,192.168.128.0/24
EOF
source /etc/profile.d/http_proxy.sh

In this example, .example.com is a wildcard pattern that matches any subdomains like foo.example.com.

4.5.2 Configuring HTTP Proxy on the OpenShift cluster

Typically, OpenShift is configured to use the proxy during installation, but it is also possible to set or re-configure it afterward. An example configuration might look like this:

Keep in mind that wildcard characters (e.g., *.example.com) are not supported by OpenShift. The complete no_proxy list, which includes container and service networks and additional service names, is generated automatically and stored in the .status.noProxy field of the proxy object:

4.5.3 Configuring HTTP Proxy for the ELM/EIC

The Edge Lifecycle Management (ELM) uses the proxy settings from the environment on the management host configured earlier. This is essential for ELM to communicate with the SAP image registry (proxied), local image registry, and OpenShift API (not proxied).

During ELM's initialization phase, set the Proxy settings when prompted. For detailed instructions on configuring the "Bypass HTTP Proxy For" settings, please refer to the information provided here.

You can generate the value for the 'Bypass HTTP Proxy For' option using the following helper command:

bash <(curl -s https://raw.githubusercontent.com/redhat-sap/sap-edge/master/utils/get_no_proxy.sh)
# to see the usage and options, append --help
bash <(curl -s https://raw.githubusercontent.com/redhat-sap/sap-edge/master/utils/get_no_proxy.sh) --help

4.6 Configuring Restricted Access for ELM (Optional)

Note: This section is optional and only applies if you plan to use the Restricted Access Model instead of the default full cluster-admin approach. This is a fully supported feature for production deployments.

Overview

The restricted access model allows you to onboard an OpenShift cluster into SAP Edge Lifecycle Management using fine-grained RBAC permissions instead of full cluster-admin rights. This approach is particularly valuable for:

  • Shared/Multi-tenant clusters where multiple teams or applications coexist
  • Enhanced security requirements that mandate least-privilege access
  • Compliance scenarios where cluster-admin access is restricted by policy
  • Production deployments where security isolation is a priority

Key Benefits

  • Least-Privilege Access: ELM operates with only the permissions it needs
  • Security Isolation: Limits the blast radius in case of security incidents
  • Multi-Tenancy Support: Enables safe coexistence with other workloads
  • Audit Compliance: Meets regulatory requirements for controlled access

Configuration Process

The restricted access setup consists of five main stages that must be completed before registering the cluster with ELM:

  1. Prepare Namespaces - Create and configure dedicated namespaces with appropriate security annotations
  2. Configure OpenShift Service Mesh 3.x - Deploy Red Hat OpenShift Service Mesh 3.x to manage network traffic
  3. Apply RBAC Permissions - Apply fine-grained permissions using resources from SAP Note 3618713
  4. Generate Kubeconfig File - Create a kubeconfig using the dedicated Service Account
  5. Register Cluster in ELM - Add the cluster as an Edge Node with restricted access enabled

Documentation Resources

For complete step-by-step instructions, detailed commands, verification procedures, and troubleshooting guidance, please refer to the official documentation:

Primary Documentation:

Additional Resources:

Prerequisites

Before proceeding with the restricted access configuration, ensure you have:

  • Cluster-admin privileges on the target OpenShift cluster (required for initial setup only)
  • Access to SAP Note 3618713 (requires SAP S-user credentials)
  • Downloaded resources.zip from SAP Note 3618713 containing RBAC manifests
  • Red Hat OpenShift Service Mesh 3.x Operators installed on the cluster
  • OpenShift CLI (oc) authenticated to your cluster
  • OpenShift Container Platform 4.14+ (tested versions for Service Mesh 3.x)

Important Notes

  • Production Ready: This feature is fully supported by SAP for production deployments
  • Timing: Configuration must be completed before registering the cluster with ELM
  • Critical Setting: When registering in the ELM UI, you must check the "Restricted Access to Kubernetes cluster" checkbox
  • Security: Keep the generated edgelm-kubeconfig file secure - it provides access to your cluster
  • Service Mesh Options: Choose between shared service mesh or dedicated service mesh (enhanced isolation) based on your security requirements

Quick Reference: Registration Steps

When you're ready to register the cluster after completing the configuration:

  1. In the ELM UI, start the Add an Edge Node process
  2. Enter a name for your Edge Node
  3. CRITICAL: Check "Restricted Access to Kubernetes cluster" checkbox
  4. Provide the contents of the generated edgelm-kubeconfig file
  5. Complete the remaining configuration steps as guided by the UI

4.7 Installing Edge Lifecycle Management

For detailed instructions on installing Edge Lifecycle Management, please refer to the SAP Edge Lifecycle Management Installation Guide.

4.8 Installing Edge Integration Cell

To set up and manage the Edge Integration Cell, consult the SAP Integration Suite Documentation.

4.9 Exposing the SAP EIC Istio Ingress Gateway (Optional)

The Istio ingress-gateway service requires an external IP or hostname to be assigned by your platform. This is a requirement for SAP EIC deployment to complete successfully.

Understanding Your Load Balancer Options

Before proceeding, check if your OpenShift platform already has an external Load Balancer integrated. In enterprise on-premise environments, clusters are often already behind hardware or software load balancers. If a load balancer is already configured and integrated with the cluster to handle type: LoadBalancer services, you do not need to install MetalLB or use Routes — your existing infrastructure will automatically assign an external IP to the istio-ingressgateway service.

If no load balancer infrastructure exists, you have the following options:

  • Option 1: LoadBalancer Provider — Use MetalLB or any other load balancer solution that can provide external IPs for type: LoadBalancer services. MetalLB is an officially supported Red Hat operator, but it is not mandatory if another load-balancing solution is already in place.

  • Option 2: OpenShift Routes — An alternative for environments without load balancer infrastructure, using the native OpenShift routing layer. See important support scope and technical restrictions below.

Option 1: Using a LoadBalancer Provider (e.g., MetalLB)

If your OpenShift cluster is running on bare-metal infrastructure without an existing load balancer, you can use MetalLB or a similar provider. MetalLB provides LoadBalancer functionality by assigning external IPs to services. Note that MetalLB is simply one provider option — any solution that can satisfy the type: LoadBalancer service requirement will work.

Step 1: Install and configure MetalLB

You can install MetalLB through OpenShift OperatorHub. Once the Operator and a MetalLB instance are deployed, MetalLB requires two resources to hand out external IPs: an IPAddressPool (the range of addresses it may assign) and an L2Advertisement (how those addresses are advertised on the network).

Create an IPAddressPool with at least one address available for the Istio Ingress Gateway (adjust the range to your network):

apiVersion: metallb.io/v1beta1
kind: IPAddressPool
metadata:
  name: eic-ingress-pool
  namespace: metallb-system
spec:
  addresses:
    - 192.0.2.240/32

Create an L2Advertisement so the pool is advertised in layer 2 mode:

apiVersion: metallb.io/v1beta1
kind: L2Advertisement
metadata:
  name: eic-ingress-l2
  namespace: metallb-system
spec:
  ipAddressPools:
    - eic-ingress-pool

Apply both manifests:

oc apply -f ipaddresspool.yaml
oc apply -f l2advertisement.yaml

Note: The metallb-system namespace is created when you install the MetalLB Operator. Confirm the namespace name in your environment before applying these resources.

Step 2: Verify the External IP

Since the Istio Ingress Gateway service is already configured as a LoadBalancer type service, MetalLB will automatically allocate an external IP for it. To verify the external IP, use the following command:

oc get svc istio-ingressgateway -n istio-system

You should see an EXTERNAL-IP assigned to the service:

NAME                  TYPE           CLUSTER-IP       EXTERNAL-IP   PORT(S)                      AGE
istio-ingressgateway   LoadBalancer   10.96.179.193    192.0.2.22     443:32057/TCP               10m

You will need to use DNS to correlate the SAP EIC "Default Virtual Host" with the EXTERNAL-IP allocated by MetalLB, so that traffic is correctly routed.

Step 3: Test External Access

Once MetalLB assigns an external IP, you can use the assigned IP to test external access. For example:

curl -k --request GET --url https://[Default Virtual Host]/http/example

Option 2: Using OpenShift Routes

OpenShift Routes are a native way to expose services using a hostname. This method works by mapping a domain name directly to an internal Kubernetes service, bypassing the need for a service of type LoadBalancer. Routes support both single and multiple Virtual Host configurations (e.g., Default + API Virtual Host) using SNI-based routing.

Note: The Default Virtual Host (iflow runtime) is reached directly via DNS → Istio ingress and is not a Cloud Connector mapping, whereas the API Virtual Host is exposed through the Cloud Connector. For how these hostnames map to Cloud Connector system mappings, ELMO, and EIC fields, see Configuring EIC with an External Cloud Connector.

Note: This deployment topology differs from the SAP-provided delivery model and has specific support scope boundaries and operational restrictions. Review the full guide before proceeding.

For complete instructions — including architectural differences, traffic flow diagrams, support scope, operational restrictions, and Route YAML configurations — see the dedicated guide:

Exposing SAP Edge Integration Cell via OpenShift Routes

5. Sizing & Reference Architectures

EIC's own resource requirements — the HA and non-HA CPU/memory/storage totals, the Message Service tiers, and the PostgreSQL/Redis/Valkey/HANA minimums — are defined and frequently updated by SAP. Take those figures from the authoritative sources rather than from a copy that can drift:

This section adds only what those documents do not cover: the OpenShift-specific guidance for turning the EIC application totals into cluster node topologies.

5.1 OpenShift sizing notes

  • Minimum node size. Avoid agent / worker nodes with fewer than 4 CPUs — scheduling overhead becomes disproportionate and pod placement harder on smaller nodes.
  • Pod density. A non-HA setup runs roughly 40 pods (including platform components); an HA setup runs around 80–90 at the minimum configuration. See the OpenShift recommended control-plane practices.
  • Reserve node overhead. The SAP totals are application requirements only. Each node also runs the kubelet, the operating system, and cluster DaemonSets (CNI, monitoring, logging, Service Mesh), which reserve additional CPU and several GiB of memory per node. Size nodes above the raw application totals and leave memory headroom rather than packing pods to the SAP figures.
  • Scale best practices. For OpenShift sizing and scale guidance, see the recommended infrastructure practices.
  • Single node and hosted control planes. Red Hat supports single-node OpenShift where appropriate, and Hosted control planes can consolidate control planes onto fewer nodes to optimize resource use.

5.2 Message Service Storage

Message Service requires block storage (no file-based storage or NFS) formatted with XFS, backed by disks that deliver at least 1000 IOPS (SSDs are recommended), and the storage class must support volume expansion. The example below defines a dedicated storage class on OpenShift Data Foundation (ODF) using the Ceph RBD provisioner with fsType: xfs. Adjust the clusterID, pool, and secret names to match your ODF deployment.

apiVersion: storage.k8s.io/v1
kind: StorageClass
metadata:
  name: eic-message-service
provisioner: openshift-storage.rbd.csi.ceph.com
parameters:
  clusterID: openshift-storage
  pool: ocs-storagecluster-cephblockpool
  imageFeatures: layering
  csi.storage.k8s.io/fstype: xfs
  csi.storage.k8s.io/provisioner-secret-name: rook-csi-rbd-provisioner
  csi.storage.k8s.io/provisioner-secret-namespace: openshift-storage
  csi.storage.k8s.io/node-stage-secret-name: rook-csi-rbd-node
  csi.storage.k8s.io/node-stage-secret-namespace: openshift-storage
reclaimPolicy: Delete
volumeBindingMode: Immediate
allowVolumeExpansion: true

5.3 Reference node topologies (illustrative)

Illustrative starting points — verify before you build. The node sizes below bundle the EIC application totals with OpenShift Data Foundation (ODF) and the external services (Crunchy Postgres and Redis), assuming Message Service Tier 250. They are not a substitute for current SAP figures: confirm the EIC, Postgres, Redis, and Message Service numbers against SAP Note 3247839, adjust for your tier and workload, and engage the Red Hat team for a sizing review. Add node overhead on top of these totals (see §5.1).

Three representative layouts are shown: a full HA cluster with dedicated storage, a standard non-HA cluster, and a single node. Other supported variants — worker-hosted ODF (no dedicated ODF nodes), compact three-node clusters, external services deployed off-cluster, and SAP HANA as a unified database/data store — follow the same method; contact the Red Hat team for sizing on those.

5.3.1 HA — 3 master + 3 worker + 3 ODF nodes

Sized for the EIC HA totals plus ODF, Crunchy Postgres (2 replicas), and Redis Enterprise (3 nodes).

Node Type Resources
Master Node * 3 4 CPUs / 16 GB RAM / 120 GB Disk Storage
ODF Node * 3 10 CPUs / 24 GB RAM / 120 GB Disk Storage (+Additional storage >= 0.5 T)
Worker Node * 3 14 CPUs / 30 GB RAM / 120 GB Disk Storage

5.3.2 Non-HA — 3 master + 3 worker nodes

Sized for the EIC non-HA totals plus ODF, Crunchy Postgres (1 replica), and Redis Enterprise (1 node).

Node Type Resources
Master Node * 3 4 CPUs / 16 GB RAM / 120 GB Disk Storage
Worker Node * 3 16 CPUs / 38 GB RAM / 120 GB Disk Storage (+Additional storage >= 0.3 T)

5.3.3 Single Node OpenShift (SNO)

Sized for the EIC non-HA totals on a single node. Provide extra local storage in place of ODF, for example via the LVM Storage operator.

Node Type Resources
Single Node 20 CPUs / 50 GB RAM / 200 GB Disk Storage (+Additional 300 GB storage)

Note: If your cluster uses a storage service other than ODF, size it per that service's own guidelines and ensure enough resources remain for its workloads.

Red Hat also offers fully managed OpenShift (OpenShift Dedicated / ROSA on AWS and Google Cloud); EIC certification for that model is under discussion. For those environments, and for the variants listed above, consult the Red Hat team for a sizing review.

6. Day 2 Operations

After SAP Edge Integration Cell is installed and registered, ongoing operational tasks are documented in the companion guides below. This section is a hub — each topic links to its dedicated guide.

Operator-driven Day 2 management

A key advantage of running EIC on OpenShift is the Operator Framework and Operator Lifecycle Manager (OLM). The external services and platform components used by EIC are deployed and managed by Operators, which dramatically simplify Day 2 operations:

  • Automated certificate and secret management — Operators such as Crunchy PostgreSQL and Redis Enterprise provision and rotate TLS certificates automatically and expose them as Kubernetes secrets. There is no manual certificate authority, CSR, or cert-manager workflow to maintain for these services — you simply reference the operator-managed secret. Example configurations are available in the SAP Edge external services examples.
  • Automated upgrades and patching — OLM surfaces available Operator updates in OperatorHub and applies them with the configured approval strategy (automatic or manual), keeping databases, data stores, service mesh, and monitoring current with minimal effort.
  • Self-healing and lifecycle automation — Operators continuously reconcile desired state, handling failover, backups, and scaling for their components according to their custom resources.

For these reasons, most Day 2 tasks that require manual scripting on other platforms are handled natively by Operators on OpenShift.

Observability & Monitoring

Security & Access

  • Restricted access (OpenShift Service Mesh 3.x) — Restricted Access with OSSM 3.x. This guide also covers the version-conditional preparation for Edge Integration Cell versions before 8.41 (see its "Appendix: EIC Before 8.41").

Connectivity

Backup & Restore

Upgrades

Comments