Optus's RHEL factory treats image sprawl as a pipeline defect, not an engineer's lapse

Optus, working with Red Hat Consulting in Australia and New Zealand, has built what Red Hat calls an automated RHEL factory: a governed pipeline that delivers consistent RHEL 8 and RHEL 9 virtual machines with Center for Internet Security (CIS) Level 1 controls applied at provision time ^[1]. The useful part for infrastructure teams is not the tool list but the framing, because the account treats image sprawl and post-hoc hardening as defects in a provisioning pipeline rather than as lapses in engineer discipline ^[3].

The failure mode Red Hat describes will be familiar. A team requests a server, someone picks an outdated template, edits config files by hand, skips a security setting to make the date, and months later an audit flag forces a manual retrofit of controls onto a live production machine ^[4]. Underneath that, per Red Hat, images multiply, hardening becomes inconsistent, and patching and compliance become manual follow-up work after the machine is already running ^[3].

The response splits the lifecycle into three stages with different owners. Day 0 is a version-selectable GitLab CI/CD pipeline that works with RHEL image builder to produce a governed open virtual appliance, published as a thin OVA to the enterprise VMware vCenter Content Library ^[6]. Day 1 is an Ansible workflow running a survey-driven deployment to VMware, with cloud-init handling first-boot configuration and Ansible Automation Platform applying runtime hardening and baseline configuration through repeatable roles ^[7]. Day 2 starts when the VM registers to Red Hat Satellite for content, patching, and lifecycle control ^[8]. The whole thing runs on Satellite, Ansible Automation Platform, and GitLab inside Optus's own environment ^[2].

Three design decisions are the ones worth copying, and they map to the three hurdles Red Hat names: image sprawl, unpredictable networking, and a Satellite model that gets hard to manage ^[9]. First, one thin OVA per RHEL version instead of a large template library, with Ansible Automation Platform sizing the workload at deploy time ^[10]. Second, a sanitization step on the image builder host to work around a known upstream limitation, so networking stays consistent from first boot ^[11]. Third, Satellite scaled through role-based access control, standardized activation keys, uniform host groups, and layered content views ^[12]. Build and publish stages are also separated, so approved images carry clear metadata into provisioning ^[13].

The evidence comes from Ansible roles and OpenSCAP validation collecting results during deployment ^[14]. Red Hat reports 97.42% compliance for CIS Level 1 OS-conditional controls on RHEL 8 and 97.10% on RHEL 9 ^[15][16], against an Optus internal target of 95%, with the remainder logged as known Optus exceptions ^[17]. That is a margin of 2.42 and 2.10 points over target ^[18], and a residual 2.58% and 2.90% of scored controls left open ^[19].

Read the numbers with the source in mind. This is Red Hat's account on Red Hat's blog ^[1], and it carries no before-and-after compliance figure, no server counts, and no cost or time saved. So what transfers is the operating model, not the business case.

Two things will test it. Red Hat says the natural next step is Day 2 governed patching and lifecycle management ^[20], which is where the pipeline stops being a build story and starts being an operations one. And the claim that the factory extends to future RHEL versions without redesigning the operating model ^[2] is only checkable when the next RHEL version lands and someone has to add it to the version selector.