Optus turns RHEL provisioning into a governed factory from image build to patching

Optus and Red Hat have described a RHEL “factory” that treats virtual-machine delivery as a governed pipeline rather than a collection of templates. The pattern is notable because it assigns a different control point to each lifecycle stage: GitLab and image builder create the artifact, Ansible provisions and hardens it, and Red Hat Satellite takes over content and patch management.

The three-stage factory

At Day 0, a version-selectable GitLab CI/CD pipeline calls Red Hat Enterprise Linux image builder to produce an Open Virtual Appliance. An approved thin OVA is then published to Optus’s VMware vCenter Content Library.

At Day 1, an Ansible Automation Platform survey collects deployment inputs and starts provisioning to VMware. Cloud-init handles first-boot configuration, after which Ansible roles apply runtime hardening and the standard baseline. The approach uses one thin image for each RHEL version rather than maintaining many workload-specific templates; Ansible sets workload sizing at deployment time.

At Day 2, the virtual machine registers with Red Hat Satellite for content, patch and lifecycle controls. Optus uses role-based access controls, standardized activation keys, consistent host groups and layered content views to share a base while separating teams.

This split matters. Image creation remains reproducible, workload-specific choices stay out of the golden image, and ongoing compliance has an owner after the machine enters production.

Compliance is measured in the pipeline

Red Hat says the factory applies CIS Level 1 controls during provisioning and gathers evidence through Ansible roles and OpenSCAP validation. The published results are 97.42% compliance for RHEL 8 and 97.10% for RHEL 9 against OS-conditional controls. Both exceed Optus’s 95% target; the remaining controls are described as documented Optus exceptions.

Those figures come from the project participants rather than an independent audit, so they should be read as implementation results, not a general benchmark. The more transferable practice is the explicit exception model. A platform cannot honestly promise 100% compliance if required workload behavior conflicts with a control. It can make the deviation visible, approved and repeatable.

What other platform teams can copy

The design offers a practical path away from image sprawl. Keep the base artifact thin, version it by operating-system release, and move variable configuration into surveyed automation. Separate build approval from publication, attach metadata to approved images and preserve evidence from hardening runs.

Teams should also test the awkward infrastructure details early. Optus added a sanitization step on the image-builder host to work around a known upstream networking limitation and keep first boot predictable. That is a reminder that a golden-path diagram is not enough; the factory needs tests around identity, networking, registration and failure recovery.

The AI angle is secondary but credible. Red Hat argues that standardized inventory, repeatable playbooks and approval paths create a safer substrate for future agent-assisted operations. That is the right order: agents should invoke governed workflows that already exist, not improvise changes directly against inconsistent servers.