Lessons from Modernizing Highly-Regulated Clients with Red Hat® Ansible Automation Platform® and Satellite®
In Level Up’s experience, enterprise automation projects rarely stall because of Ansible or any similar technology solution.
Instead, many are delayed because organizations must first understand and then address the evolving complexity and unavoidable security requirements of the environments they’re trying to automate, especially in highly-regulated industries.
Case in point: Over the past year, our team has been working alongside a regulated public utility as it modernizes its infrastructure automation strategy end to end.
The phase one engagement objectives sounded straightforward at first glance: replace legacy automation, improve RHEL patching, standardize operations, and establish a sustainable automation platform. The reality of infrastructure automation in the face of hard security/compliance requirements proved to be considerably more nuanced.
Rather than simply deploying Red Hat Ansible Automation Platform (AAP), the first phase of the project centered on designing an enterprise-grade and secure architecture capable of supporting both traditional enterprise IT systems and highly-controlled Operational Technology (OT) environments while maintaining strict separation between the two.
This post shares a few of the engineering takeaways from phase one.
The Phase One Environment
The client’s infrastructure combined several technologies common across large enterprises:
- RHEL
- Red Hat AAP
- Red Hat Satellite
- VMware® vSphere
- Azure® DevOps source control
- Active Directory / LDAPS authentication
- Multiple security zones with strict firewall controls
- Separate IT and Operational Technology (OT) environments
Like many organizations these days, some automation already existed. However, it had grown organically over several years through a combination of legacy tooling, manual processes, and isolated scripts maintained by different teams.
Our goal wasn’t simply to automate more tasks. It was to create an automation platform that multiple teams could trust and operate for years to come.
The Real Challenge Wasn’t Installing AAP
Regardless of any security requirements, topology complexities or network connectivity constraints, and even in 100% air-gapped environments, installing AAP is relatively straightforward for a strong Red Hat partner to assist in deploying in any client’s environment these days.
The more interesting engineering problem is actually deciding how automation should flow through the organization, from thought to action, and from action to verification.
Key questions that surfaced included:
- How should automation be orchestrated between the relatively-permissive IT and nearly-isolated OT environments?
- Who owns which resource credentials?
- How “can vs. should” RBAC be structured?
- How should content be promoted between environments?
- What belongs in Git versus the automation platform itself?
- How should disconnected infrastructure receive updates?
These architectural decisions almost always have a much larger long-term impact, “beyond the deployment” so to speak, than the installation details themselves.
Designing Around IT and OT Separation
One of the defining characteristics of the first phase of the project was the need to preserve strict separation between enterprise IT systems and operational environments.
Rather than attempting to flatten everything into a single automation domain, the architecture intentionally maintained environment separation while allowing approved automation content to move in a controlled manner.
Key design principles included:
- 100% separate automation execution paths for IT and OT
- Independent lifecycle management
- Controlled content synchronization
- Distinct RBAC models
- Version-controlled automation through Azure DevOps
- Satellite-managed content promotion
This approach reduced operational risk while still allowing automation standards to be shared across the organization.
The Moment When Satellite Finally Became More Than a Patching Tool
Entering phase one and like many organizations, our client might have viewed Red Hat Satellite primarily as a repository and patch management solution. Because that would totally make sense if that’s all you’re using it for. But by the end of phase one, the impression our team got was that Satellite was now being regarded as more of a foundational and even strategic component of our client’s wider automation capabilities.
Careful planning around content views, lifecycle environments, synchronization strategy, and repository management proved essential for maintaining consistency across isolated environments.
Notably, our phase one design discussions focused less on “how do we patch new RHEL systems in other network segments?” and more on “how do we guarantee that the same trusted content reaches every host in every environment consistently?”
Execution Environments Matter Earlier Than Some Regulated Clients Might Expect
Planning for custom Ansible Execution Environments (EE’s) can happen anytime in an engagement, but EE’s often won’t come up until later, as more of an intermediate to advanced implementation discussion. During this engagement though, they became a mission-critical consideration almost immediately.
As automation use cases expanded across Linux administration, VMware provisioning, and other infrastructure domains, managing Ansible collection dependencies through custom EE’s quickly and repeatedly proved their value, as they dramatically simplified reproducibility and reduced operational drift.
Treating EE’s as versioned software artifacts (not just containers) proved to be an important mindset shift internally.
Solving Identity and Access Management Sometimes Takes Longer Than Solving Automation
Another recurring theme across the phase one engagement was identity.
In any client environment, integrating enterprise authentication, managing certificates, handling service accounts, defining RBAC, and coordinating ownership across internal stakeholder teams can end up requiring more planning than writing Ansible playbooks. And in regulated industry clients, doubly so.
Automation succeeds when engineers trust it and when management has realtime visibility into the outcomes. And that trust and visibility really begin with authentication, authorization, and governance.
Training Is Always Part of Level Up’s Deliverables
Every deployment phase ends eventually. Operational ownership does not.
Throughout the phase one engagement, we conducted realtime architecture reviews, ongoing working sessions, platform feature demonstrations, and administrator knowledge-sharing across topics such as:
- Satellite lifecycle management
- Host registration
- Patch automation
- Git workflows
- Execution Environments
- Operational best practices
At phase one completion time, the outcome wasn’t simply having delivered a working automation platform. Equally important was ensuring that the client’s engineering teams could now confidently extend and maintain AAP x Satellite themselves going forward.
Phase One Lessons Learned
A few key observations that stood out during the first phase of our AAP x Satellite project:
1. Automation architecture matters more than automation quantity.
Organizations often measure success by the number of playbooks written. However, long-term success is often determined more by governance, ownership, and maintainability standards. (And this is where vendor selection is absolutely crucial.)
2. Source control standards should be established early.
Clear and consistent Git workflows reduce confusion and simplify collaboration (especially in complex secure networking scenarios) long before automation reaches production scale.
3. Satellite and Ansible are complementary, not competitive, technologies.
Satellite provides trusted patching, lifecycle and content management. Ansible provides orchestration and execution of Satellite and much more. Both are world-class at what they do, but together they create an even stronger operational platform than either product offers by itself.
4. Security boundaries may influence your design, but they don’t have to block automation… unless you let them.
Well-designed automation can absolutely respect modern security and operational boundaries, even in highly-regulated industries, without fundamentally weakening or sacrificing the speed and consistency promised by solutions like AAP.
Final Thoughts
Enterprise automation is rarely about replacing manual commands with playbooks. It is usually much more about operationalizing a platform that multiple teams can trust, govern, and continuously improve.
Every organization’s design will differ, but the same pattern appears repeatedly: the technical installation is only the beginning. The real engineering work lies in building automation that remains reliable, secure, and maintainable long after the initial deployment is complete.
That’s where thoughtful architecture, and the experience that a strategic automation partner offers, can begin creating lasting value for your organization.