Standardized, secure, and scalable: The Optus blueprint for Red Hat Enterprise Linux automation factory

Telecom infrastructure teams often face the same bottleneck: Every new Red Hat Enterprise Linux (RHEL) server is a custom job. Images multiply. Hardening is inconsistent. Patching and compliance become manual follow-up work after the machine is already live.

If you've ever managed enterprise Linux infrastructure at scale, you know the routine. A team requests a new server, and what should be a straightforward task turns into a manual, custom build. Someone picks an outdated template, tweaks a few config files by hand, and skips a security setting to get it live on time. Months later, an audit flag pops up, and you're stuck manually retrofitting security controls on a production machine.

As custom configurations drift and template libraries balloon, keeping servers secure and patched becomes a constant fight. That was the exact bottleneck Optus set out to solve. Optus wanted a better model, one standard way to build, provision, and secure RHEL at scale, without relying on console work or one-off templates.

Working with Red Hat Consulting in Australia and New Zealand, Optus built an automated RHEL factory: A governed pipeline that delivers consistent RHEL 8 and RHEL 9 virtual machines (VMs), with Center for Internet Security (CIS) Level 1 controls applied at provision time. The factory runs on Red Hat Satellite, Red Hat Ansible Automation Platform, and GitLab in Optus’s environment. It's designed to extend to future RHEL versions without redesigning the operating model.

How the factory works

To move away from manual builds, the factory focuses on three guiding principles:

• Standardize: A repeatable model defines how RHEL images are created, versioned, and deployed.
• Automate: Self-service VM delivery replaces manual steps using Ansible Automation Platform for provisioning, and GitLab CI/CD to build the golden images.
• Secure: CIS Level 1 compliance is built into every VM at provision time, not added later as an audit exercise.

From Day 0 to Day 2

The factory separates image creation from provisioning and ongoing operations:

Day 0 (Image build factory): A version-selectable GitLab CI/CD pipeline works with Red Hat Enterprise Linux image builder to produce a governed open virtual appliance (OVA). The approved thin OVA is published to the enterprise VMware vCenter Content Library.

Day 1 (Provisioning and security hardening): When a team needs a new workload, an Ansible workflow runs a survey-driven deployment to VMware. Cloud-init handles first-boot configuration. Ansible Automation Platform then applies runtime hardening and baseline configuration through repeatable roles.

Day 2 and beyond (Operations and compliance): After provisioning, the VM registers to Red Hat Satellite, which provides content, patching, and lifecycle control so that compliance doesn't depend on ad hoc maintenance.

Built for real constraints

When RHEL deployments scale, infrastructure teams often face the same 3 hurdles: Image sprawl, unpredictable networking, and a Satellite model that becomes hard to manage. Optus tackled those issues directly:

• One image per RHEL version: Instead of maintaining a large template library, Optus uses one thin OVA per RHEL version. Ansible Automation Platform sizes the workload at deploy time.
• Predictable networking: A sanitization step on the image builder host addresses a known upstream limitation so networking stays consistent from first boot.
• A scalable Satellite model: Role-based access control (RBAC), standardized activation keys, uniform host groups, and layered content views keep shared base content consistent while giving teams clean separation.

Security and compliance results

Security sits in the pipeline, not after go-live. Build and publish stages are separated so approved images carry clear metadata into provisioning.

Ansible Roles and OpenSCAP validation collect evidence during deployment. Measured results for CIS Level 1 OS-conditional controls:

• RHEL 8: 97.42% compliance
• RHEL 9: 97.10% compliance

Both scores meet Optus’s 95% compliance target. The remaining items are known Optus exceptions.

The outcome

Optus now operates the full factory: GitLab pipelines for golden images, an Ansible workflow for Day 1 provisioning and hardening, and Satellite for ongoing lifecycle control, all running in Optus's own environment.

Built for what's next

With Day 0 image builds and Day 1 provisioning in place, the natural next step is Day 2 operations: Governed patching and lifecycle management through the same Satellite and Ansible Automation Platform stack.

That foundation also matters for the longer term. AI-assisted operations work best when the infrastructure underneath them is standardized: Known inventory, repeatable playbooks, approval paths, and measurable compliance. Agentic AI can sit on top of that governed automation layer so future AI-assisted capabilities direct existing workflows rather than inventing unmanaged change.