From Red Hat OpenShift Guidance to an Ecosystem of Identity, Recovery, and Control

Summary: What started as Red Hat OpenShift operating guidance turned into a multi-year expansion, establishing OpenShift as the unified platform across on-prem and cloud with identity, resilience, observability, and governance layers needed for consistency and control.

Five years ago, our client bought OpenShift and stood up production and non-production clusters.

But they lacked practical operating guidance on designing the platform, planning capacity, running CI/CD safely on Kubernetes, and defining a recovery and security baseline.

Their support contract handled tickets.

However, they couldn’t manage the architecture and operating decisions the team needed. We led a series of targeted expansions as OpenShift became the unified platform across the environment, and the surrounding stack had to mature with it

Over the next several years, we guided the evolution of OpenShift from a point solution to an evolving ecosystem and the core platform.

When Running OpenShift Stops Being the Main Focus

As adoption expanded, the client turned Red Hat OpenShift into the default platform for teams shipping and operating workloads.

The question stopped being “how do we use OpenShift” and became “how do we regulate use, so teams move fast without creating security, audit, and change-control problems the business can’t explain later.”

By October 2025, the client asked Shadow-Soft to put guardrails and visibility around that usage: define clear role boundaries, block common permission-escalation paths, separate admin privileges from data access, and route access and change signals into Dynatrace with alerts for sensitive events.

Shadow-Soft delivered the controls as a versioned configuration so the client could review changes, track what changed and why, and apply the same rules consistently as the environment evolved.

Tech highlights:

• Google Cloud IAM: defined role boundaries and blocked common escalation patterns.
• HashiCorp Terraform: codified controls and made changes reviewable and repeatable.
• Audit logs → Dynatrace: centralized visibility and alerting for sensitive access and IAM changes.
• Policy guardrails: enforced consistent control coverage as the footprint expanded.

But the client’s infrastructure wasn’t always like this.

The client began a small advisory engagement after buying OpenShift and failing to receive practical architecture and operating guidance through their standard support path.

Initial operational struggles with OpenShift

In 2021, the client had recently brought OpenShift into their environment and was running two clusters: one production and one non-production.

They opened multiple tickets with Red Hat support, but still lacked practical guidance on running the platform day-to-day, making sound architectural decisions, and setting up delivery practices that wouldn’t break under load.

After searching for trusted Red Hat partners, the client contacted Shadow-Soft. They used a short set of intro calls to confirm fit and align on the immediate issues, then scoped a 40-hour engagement with a front-loaded assessment followed by advisory time to work through recommendations and unblock the team.

Shadow-Soft used the assessment to map the current OpenShift setup and operating approach across architecture, performance, and health, CI/CD and release process, disaster recovery, and security posture.

Next, our team delivered a pain-point readout and a prioritized improvement plan, plus troubleshooting and best-practice guidance during the remaining hours.

Tech highlights:

• Red Hat OpenShift: two clusters (production and non-production) already in place; the work focused on operating design and day-to-day practices.
• Platform architecture and capacity: reviewed cluster design assumptions and capacity planning to support defensible sizing decisions.
• CI/CD and release process: assessed build and deployment flow into OpenShift and the controls needed for repeatable releases.
• Performance and health: reviewed how the team monitored the platform and workloads for early signal, not just ticket response.
• Disaster recovery: reviewed recovery expectations and gaps for platform and workloads.
• Security posture: reviewed access, configuration, and platform hardening to establish an enforceable baseline.

The first phase solved the immediate question: how to run OpenShift more effectively. Once the platform stabilized, the next dependency came into focus: identity.

Fixing Authentication As a Single Point of Failure

Authentication no longer sat at the edge of the platform. It sat on the critical path. If it failed, teams lost access to applications and admin surfaces across environments.

The client engaged Shadow-Soft for a multi-phase Red Hat Single Sign-On (RHSSO) rollout with failover testing across on-prem OpenShift and Azure Red Hat OpenShift (ARO).

Shadow-Soft stood up the on-prem RHSSO cluster first and paired it with a highly available Azure SQL backend. The team then mirrored the deployment in an ARO test environment to validate re-authentication behavior and DNS traffic shifts under failover conditions.

After that test work, Shadow-Soft completed the production ARO deployment and standardized the configuration as Kubernetes manifests stored in Git, so the client could manage changes through version control rather than one-off console edits.

Tech highlights:

• RHSSO: shared authentication layer for platform and application access across environments.
• On-prem OpenShift + ARO: identity needed consistent behavior across both footprints.
• Azure SQL (HA across AZs): resilient backing database for a dependency that can block access when it fails.
• Kubernetes manifests in Git: versioned deployments and repeatable changes for the identity layer.
• Enterprise identity integration (LDAP or SAML): connection to the client’s existing identity provider.

With identity running across both footprints, the next constraint shifted again: the supporting layers that make a platform usable at scale.

Extending OpenShift into an Operational Ecosystem

After the identity layer was implemented, the client began treating OpenShift as the unified platform for workloads.

That shift uncovered the next challenge.

The platform needed supporting layers that made use scalable: a repeatable way to move data through the environment, storage that could handle stateful workloads, and observability that surfaced issues before teams found them the hard way.

Across 2023 and 2024, the client pulled Shadow-Soft into that ecosystem work. We helped deploy Apache NiFi on OpenShift to replace a legacy ingestion process and integrate access control with the client’s existing directory, so the team didn’t create a separate identity surface.

As requirements expanded to support stateful workloads and operational visibility, the account also brought in add-on tooling that sat alongside OpenShift rather than inside it.

Tech highlights:

• Apache NiFi on OpenShift: ran ingestion and processing inside the platform instead of a legacy point solution.
• Directory integration (AD/LDAP): kept access control aligned with existing identity management.
• Portworx: addressed storage and data services requirements that outgrew baseline approaches.
• Dynatrace: added deeper observability coverage for platform and workloads.

With those layers in place, the work shifted from adding capabilities to keeping critical dependencies current and recoverable as the footprint grew.

Keeping Authentication Current and Recoverable

Once the client ran a shared identity layer across OpenShift and Azure Red Hat OpenShift, authentication risked becoming an operational dependency. Version drift, failed upgrades, or a broken database could lock teams out across environments.

In March 2025, the client scoped a fixed-price engagement with Shadow-Soft to upgrade RHSSO to version 7.6 across OpenShift and ARO and establish a recovery path.

We replicated the existing RHSSO instance and its Postgres database in each environment, upgraded the replicated copies to 7.6, then configured backups to a client-provided S3 bucket using OpenShift-aligned data protection tooling.

The output of this phase focused on keeping a critical dependency current and recoverable while the footprint expanded.

Tech highlights:

• RHSSO 7.6: upgraded the identity layer across environments.
• OpenShift + ARO: maintained version parity and consistent behavior across both footprints.
• Postgres: replicated and protected the RHSSO persistence layer during the upgrade workflow.
• OpenShift data protection tooling (OADP or PX-Backup): implemented backup and restore workflows aligned to the platform.
• Client S3 bucket: backup target for recovery capability.

And that brings us to where we are today.

Red Hat OpenShift as the Future-Proof Foundation

The relationship started with a narrow need: OpenShift operating guidance that standard support didn’t cover.

Over time, the scope expanded in phases as OpenShift became the unifed platform, and the surrounding layers had to mature with it. Each phase addressed the next constraint that showed up once the previous layer was held.

Going forward, the environment now runs on a platform foundation built to support what comes next, not just what exists today. Red Hat OpenShift provides the client with a consistent operating model across containers, virtual machines, and emerging AI workloads.

Now, our work is evolving into repeatable hardening cycles: keeping shared services current, testing recovery paths, tightening access and audit coverage, and standardizing change control across teams and cloud footprints so the platform stays usable, governable, and ready for the next workload shift.

Shadow-Soft’s role stays the same as it has throughout the story: a focused delivery partner when the next constraint outpaces internal capacity or expertise.