Platform engineering, security architecture, and operations teams are being asked to support 2 realities at once: modern application platforms such as Red Hat OpenShift, and long-lived Red Hat Enterprise Linux (RHEL) fleets that still run critical automation. These parallel systems introduce risk, especially around how users, workloads, or automation identities can be authenticated across environments. But there’s also larger questions at play: What boundary exists after privileged work starts? How are exceptions approved? How can operators prove that the intended boundary was active when the work ran?The pattern is most relevant when teams are designing OpenShift workload classes, onboarding continuous integration (CI) and build namespaces, creating privileged automation identities, or reviewing posture after kernel vulnerabilities advisories. It isn't a replacement for existing controls. It is a way to make privileged workload and automation behavior explicit, centrally governed, and verifiable.I built Blastwall to test a practical question: Can privileged work arrive with a named, verifiable boundary instead of broad, implicit trust? Blastwall is a proof-of-concept reference pattern, not a Red Hat product or prescribed deployment model. The proof uses OpenShift workload confinement, Red Hat Ansible Automation Platform workflow evidence, Identity Management (IdM) policy, and SELinux confinement on RHEL to show how these boundaries can be made visible before privileged work runs.Start with OpenShift workload boundariesOpenShift provides a consistent hybrid cloud foundation for building and scaling containerized applications. That makes OpenShift the right anchor for this discussion: many high-impact tasks now begin as platform work, not as a traditional host login.OpenShift already includes multiple layers of workload control. Security context constraints (SCCs) can control pod permissions, including privileged containers, requested capabilities, host directory access, host namespace use, SELinux context, and allowable seccomp profiles. For custom behavior, Red Hat documentation advises creating custom SCCs instead of modifying defaults.The Security Profiles Operator (SPO) adds a Kubernetes-native policy-management path for workload-specific hardening. It defines secure computing mode (seccomp) and SELinux profiles as custom resources and synchronizes those profiles to nodes in a namespace. In the Blastwall OpenShift proof, SPO installs 2 workload classes, blastwall and blastwall-nested. Custom SCCs select the appropriate class, and safe probes validate that selected pods run with the expected SELinux workload type and boundary behavior.The OpenShift path should stay Kubernetes-native. Selected workloads are bound to approved profiles, exceptions are explicit, and operators can verify that the intended boundary is active. That keeps the control aligned with how OpenShift manages workloads while preserving the broader Blastwall principle: privileged activity should land inside a defined, inspectable confinement boundary.Make exceptions named, not implicitThe most useful part of the OpenShift path isn't that every workload receives the same policy. Real platforms need a default boundary and a governed exception path.The standard blastwall class should remain the default for ordinary workloads. It denies workload-created user namespaces along with other high-risk kernel entry points. That's the right starting point for workloads that don't need to create nested containers or run rootless build tooling inside the pod.The blastwall-nested class is different by design. It's intended for development and CI use cases where a pod legitimately needs pod-level user namespace behavior, such as running rootless build or nested-container workflows with tools such as Podman and Buildah, often alongside image workflow tools such as Skopeo. Red Hat documentation describes running Skopeo, Buildah, and Podman in a container for isolated development environments or continuous integration / continuous delivery (CI/CD) pipelines, and Red Hat Developer content discusses nested containers in OpenShift Dev Spaces as a developer-workspace use case with security tradeoffs.That kind of exception should not quietly become the production default. In Blastwall, the nested class uses a separate service account, a separate SCC, and pod-level user namespace behavior. It doesn't grant a privileged container, host namespaces, hostPath access, extra capabilities, or privilege escalation. It also keeps the remaining deny posture in place for other high-risk surfaces.That's the difference between an exception and a workaround. A workaround hides risk in a one-off deployment. A platform exception gives application teams, platform engineers, and security teams the same vocabulary for the boundary: which workload class was selected, which service account requested it, which admission path allowed it, and how operators can verify the active SELinux context and probe results.Use Ansible Automation Platform to orchestrate evidenceConfinement without evidence becomes another hidden control. Enterprise platforms rely on automation to configure hosts, remediate incidents, patch systems, rotate settings, and respond to drift. Automation is valuable because it moves faster than a person. That's also why it needs a preflight gate and an evidence trail.Ansible Automation Platform is a practical layer for that control point. Red Hat documentation describes workflow job templates as a way to link resources such as job templates, workflow job templates, project syncs, and inventory source syncs. In Blastwall, Ansible Automation Platform doesn't enforce the SELinux boundary on the host or OpenShift node. It can enforce automation policy at runtime before work proceeds, including policy checks tied to organizations, inventories, and job templates. In this pattern, Ansible Automation Platform provides both control and evidence—source, inventory, credential, policy decision, preflight result, and runtime proof.The Blastwall Day 2 workflow demonstrates one way to run that loop. It builds a candidate SELinux policy RPM for the RHEL and IdM path, renders a versioned OpenShift/SPO custom resource bundle from the same policy version, verifies the managed-host boundary, promotes IdM marker state, and refreshes inventory so later preflight checks can consume that state.That example is a model, not a mandate. In production, different organizations might use Ansible Automation Platform, Red Hat OpenShift GitOps, Tekton, GitLab runners, GitHub Actions or a combination of tools. The important part is the contract, not the specific runner—policy starts as versioned source, build or render steps produce reviewable artifacts, tests prove the policy still supports intended work, safe probes verify the boundary, and promotion only happens when the evidence is usable.For OpenShift/SPO profiles, the rendered custom resource bundle can move through the cluster change-control process that fits the organization. For RHEL automation, the policy RPM, IdM state, inventory facts, and Ansible Automation Platform preflight checks must agree before high-value automation runs. Blastwall shows how both artifact paths could be produced and verified—each organization still owns how those examples are tuned, tested, and promoted.Make automation identity a centrally managed policy objectThe RHEL and IdM path is where the operating model changes most. The hard part isn't creating a confined SELinux domain on one host. The hard part is making the automation identity, host eligibility, elevation path, and SELinux mapping understandable, centrally managed, and auditable across a fleet.IdM provides a centralized way to manage identity stores, authentication, policies, and authorization policies in a Linux-based domain. For Blastwall, that centrality matters because the automation identity becomes a policy object rather than just a local account or SSH credential.In that model, host-based access control (HBAC) defines where the automation identity may land and through which access service. Centralized sudo policy defines whether it may elevate there, which commands it may run and, when needed, as which run-as user or group. SELinux user maps then connect that IdM user and host relationship to the SELinux context assigned to the session.That ensemble materially changes the operational weight of confinement. Without a central authority, a confined automation boundary risks becoming a set of host-local exceptions. With IdM, the boundary becomes a fleet policy, defining who the automation identity is, where it may land, how it may elevate, and which SELinux user it should inherit. Ansible Automation Platform can then read that state as part of preflight, and SELinux can enforce the result on the managed host.This matters because RHEL SELinux documentation states that Linux users in RHEL, including users with administrative privileges, are mapped to the unconfined SELinux user by default. The RHEL host path in Blastwall applies a different shape for automation: IdM records the identity and policy state, SSH, SSSD and PAM apply the login path, and SELinux confines the resulting process. The proof maps the automation path into blastwall_u:blastwall_r:blastwall_t:s0, but the exact label is not the point. The point is that privileged automation should have a named local boundary that is governed centrally.Turn emergency response into postureRecent Linux kernel local privilege escalation issues make this operating model concrete. Copy Fail, tracked as CVE-2026-31431, reached the Cybersecurity and Infrastructure Security Agency (CISA) Known Exploited Vulnerabilities catalog. Red Hat also published OpenShift mitigation guidance for Copy Fail.Dirty Frag, described in Red Hat Security Bulletin RHSB-2026-003, refers to 2 Linux kernel networking subsystem issues involving IPsec ESP and RxRPC paths. Red Hat identifies the IPsec ESP issue as CVE-2026-43284, and the RxRPC issue as CVE-2026-43500.Blastwall isn't a replacement for patching, live patching, vendor mitigation guidance, or runtime detection. It uses events like Copy Fail and Dirty Frag as forcing functions: platform teams should know which workload classes and automation identities can reach sensitive kernel surfaces, which exceptions exist, and how that posture is verified before privileged work runs.A deny scope shouldn't live only as an emergency command in a chat thread. It should become policy source, a versioned artifact, a rollout, a verification step, an inventory or identity marker, and a preflight check. The specific policy should be tuned against the organization's automation corpus, build workflows, workload classes, and risk model.What this proof does not claimBlastwall is a proof of concept. It is not a Red Hat product, supported feature, vulnerability mitigation, or prescribed deployment model. Its value is a reference pattern—a way to show how RHEL and OpenShift can anchor a security architecture where privileged workload and automation boundaries are explicit, testable, and auditable.A useful security architecture should be clear about where each control starts, where it stops, and which evidence proves it's active.The takeawayThe pattern puts established platform security practices into an operating model: OpenShift provides Kubernetes-native workload boundaries, Ansible Automation Platform helps orchestrate workflow evidence, IdM makes automation identity and access policy centrally managed and auditable, and RHEL with SELinux provides the host-level enforcement foundation.Privileged work shouldn't arrive as broad, implicit trust. It should arrive with a named workload class, a reviewed automation identity, a preflight decision, and evidence that the selected boundary is active. Blastwall shows one way to explore that pattern in a lab. The bigger lesson is one platform teams can apply now—make privileged boundaries visible before privileged work runs.Explore Red Hat Ansible Automation Platform for workflow orchestration and evidence capture.Review Identity Management for centralized automation identity, HBAC, sudo, and SELinux mapping across managed RHEL hosts.Use the Blastwall documentation as a reference pattern for how policy RPM and OpenShift/SPO custom resource production could be modeled, tested, and verified in your own operating environment.Try Red Hat OpenShift Container Platform to explore the application platform foundation for governed workload policy.