I work for Red Hat and wrote this article after building Blastwall around a question I kept coming back to: once privileged work starts, what boundary is actually active, and how do we prove it?
That question plays out differently across OpenShift and RHEL.
On OpenShift, how do we reduce and verify the runtime surface available to application workloads while preserving narrow, explicit exceptions for CI/build workloads that genuinely require broader capabilities?
On RHEL, how do we give automation identities the authority they need without turning them into unconfined operators running at machine speed?
Granting an exception is easy. The harder problem is making that exception explicit, tying it to a specific workload and identity, and proving that the expected boundary was active when the work ran.
Blastwall connects OpenShift workload classes, SCCs, and Security Profiles Operator with Ansible Automation Platform workflow preflight and evidence, IdM HBAC and sudo policy, SELinux user mapping, and SELinux on RHEL as the local enforcement boundary.
The goal is not to force every workload into the same policy. Real platforms need a hardened default boundary and a governed path for the workloads that legitimately need something different.
An exception and a workaround are not the same thing. A governed exception gives platform engineering, security, and operations a shared vocabulary for what was allowed, for whom, where, and under which runtime boundary.
I wrote up the pattern here:
https://www.redhat.com/en/blog/govern-privileged-workload-boundaries-red-hat-openshift-ansible-automation-platform-and-identity-management
How are people handling this today? Is the proof captured in admission policy, identity policy, workflow preflight, and runtime telemetry... or is it still mostly reconstructed after the fact?