Secure Deployment of IBM ODM on AWS EKS

Enabling Mainframe Modernization in a “Restricted” OPA Gatekeeper Environment

Published

April 2, 2026

MD  Mat Davis  MS  Maria Salamone 


Description: “Secure Deployment of IBM ODM on AWS EKS”

The Why

The client is executing a strategic initiative to modernize their business rule management systems, transitioning critical decision logic from the mainframe to a cloud-native architecture on AWS EKS. This modernization effort requires the agility of containerization without compromising the rigorous security standards inherent to the financial services sector.

  • Balancing Agility and Security: The primary challenge lies in reconciling the rapid deployment capabilities of IBM ODM with the client’s “Zero Exception” security posture.
  • Strict Compliance alignment: Financial services environments often enforce “Restricted” Pod Security Standards that exceed standard Kubernetes defaults. Deploying complex enterprise software into these environments requires bridging the gap between standard deployment manifests and bespoke security constraints.
  • Operational Standardization: The client requires a repeatable, automated deployment pipeline that satisfies automated policy gates (OPA Gatekeeper) without requiring manual intervention or policy waivers.

Problem Details

Technical Hurdles & Policy Integration

The objective is to deploy IBM Operational Decision Manager (ODM) v9.5 into an AWS EKS cluster protected by OPA Gatekeeper constraints. While the IBM ODM Helm Chart covers the vast majority of Kubernetes security configurations, this specific environment enforces a distinct set of “Restricted” policies that require granular control over every aspect of the Pod Security Context.

The specific integration challenges addressed in this solution include:

  1. Granular Security Context Enforcement: The target environment mandates explicit definitions for runAsGroup and supplementalGroups at the Pod level. The solution requires a method to inject these specific, client-mandated security contexts into the standard deployment manifests during the CI/CD process.
  2. Zero-Trust Persistence Architecture: The standard internal database configuration utilizes specific filesystem groups (fsGroup) for storage permission management. To align with the client’s non-root requirements (UID/GID > 1000), the architecture must be adapted to utilize an External Database (e.g. AWS RDS) rather than containerized persistence.
  3. Secure Supply Chain: The environment prohibits pulling images from public or vendor registries. The deployment workflow must accommodate an air-gapped supply chain, utilizing an internal artifact repository and referencing all container images strictly by SHA256 digests.
  4. Ingress Hardening: To meet strict traffic control policies, the solution must explicitly disable HTTP pathways and enforce TLS termination and specific ingress host matching at the manifest level.

Additional Context

Environment & Constraints

  • Platform: AWS Elastic Kubernetes Service (EKS).
  • Policy Engine: Open Policy Agent (OPA) Gatekeeper enforcing the Kubernetes “Restricted” Pod Security Standard.
  • Constraint Strictness:
    • Immutable Policies: The platform team does not allow policy exceptions or namespace-level whitelisting.
    • Pre-Deployment Validation: Deployment manifests must be fully compliant before applying to the cluster; relying on post-admission mutations is not permitted.
  • Software Version: IBM ODM 9.5.0.1 (Helm Chart 25.1.0).
  • Network Posture: Strict egress filtering requires explicit allowance for connectivity to external services (RDS) and internal tooling (Artifactory).