Configuring automation platform 2.5
Updated: 16-10-2025
Rework is done, happy reading
This part of the site will tell you how I configured redhat automation platform version 2.5 using configuration as code. As there are stil a number of issues with the configuration, I will describe the way around these issues when possible.
But first things first, I need to describe how the configuration that I am making is setup.
Disclaimer:
The configuration code I'll show you is created and functional for my homelab, servernames, credentials and so on are changed for security. There will be no warranty that it will run as is on your system. Do change those parameters accodingly.
This configuration is developed on my homelab and is actually used in an Enterprise, after the development was done and documented here.
I am not allowed to disclose the name of the organization here.
Using automation in an Enterprise
rhaap in the organization
As the rhaap (redhat ansible automation plaform) is the heart of your (automation)business, you want it to be secure, and the credentials not being shared by everyone in the organization. You want to be able to separate credentials and other configuration items from teams that do not have a use for them.
Configuration as code is basicly done on a per organization basis, so for each organization there is exactly 1 configuration as code repository.
There are two ways to accomplish this:
Departments configuration and rbac
One way to implement a configuration is to give each department a "Team" in rhaap and set access rights for everything through the rbac model rights.
This means in practice that all the configuration is in one repository and the automation team is responsible for it all. This also means that changes are error prone, through communication errors and so on.
This also means that teams cannot be responsible for their own work and how it is configured in rhaap.
This configuration repository will become very large (thousands of templates and projects) finding errors in a configuration that has thousands of lines is not easy with managers behind you screeming "why is the automation service down?".
It also has a number of advantages, but I will not go into this way of configuring rhaap.
Departments will be organizations
The other choice is to give each department its own organization, this implies that nothing is shared between the teams and this is exactly why these "teams" can be in control of their own configuration.
To be in control over your configuration, You need a separate repository for your configuration as code and a separate pileline to configure this into rhaap.
On the other hand, we want the base configuration to be controlled by the automation team and not polluted by user config.
This is exactly what we are going to build in these pages.
We made the following split in the configuration as code:
- The rhaap instance is the base configuration
- Each 'Organization' is a configuration repository
- The teams are managed inside the organization, but mapped from LDAP/AD
- RBAC is only needed inside each organization
- In version 2.5, it is possible to configure usage rights(RBAC) over organizations for objects
Users are part of Organization teams
Almost every user is mapped through AD/LDAP groups, there are a few exceptions we will discuss later. Access rights are granted through group membership (RBAC).
There are a few usertypes we will see here:
- SystemAdmins (superusers), these are the platform admins they can see and change everything.
- Organization Admins, they can change everything inside the organization they live in.
- Developers, they are granted rights by the organization admin to do their work on projects, templates, inventories and workflows within an organization.
- Operators, they are granted rights by the organization admin to run certain templates.
This is implemented in the documentation you'll find here. When you fully understand how this works, you can implement your own schema of users, or even combine roles to make things even simpler. Be my guest in doing so, it is your configuration.
So if You're interrested, keep on reading.
Access to rhaap
Access to the rhaap platform should always be configured in Active Directory or LDAP.
As we want to configure everything automated, there should be a standard structure in either tool to configure the groups in. The easiest is a standard location in AD/LDAP where the groups for access to rhaap are created, like:
ou=rhaap,ou=groups,dc=homelab,dc=wf
So the groups giving acces to the rhaap environments should be created under the above organizational unit. This way we can use this path in the automation as the default path to find the groups in the AD/LDAP.
For the group names themselves, they should be part of a naming convention to be able to map the groups correctly inside the rhaap platform.
The team 'short' name should alway be incorporated into the groupname, like the following example:
- g-rhaap-lnx-a # Admins
- g-rhaap-lnx-d # Developers
- g-rhaap-lnx-o # Operators
So each organization is uniquely named and within this organization there are (in this case) 3 LDAP groups to add users to for this organization. Each group will receive different access levels within the rhaap platform.
Each of these AD/LDAP groups will be mapped to corresponding user groups within the rhaap organization.
g-rhaap-lnx-a is mapped to the group LDAP_LNX_Admins and will recieve organization admin rights
The group names need to have a standard structure, so we can automate the mappings.
Security
For every organization security is important, therefore, we try to design the configuration iun such a way that the teams can be as autonomous as possible, while adding the security we need.
Challenge
The most secure server, is a server no human ever logs onto....
As such a production (linux)server has:
- no need for LDAP or AD setup, making it even more secure.
- The only user present is the ansible with sudo rights and key authentication(with passphrase)
- root can't login through ssh (no known passwd, no key_auth, just sudo from local ansible user)
- system accounts can be present when needed.
All changes are made through automation platform!
For this to work properly, the ansible account must be properly secured and the key must be secured in a way that if its extracted, it is still of no use to the user that extracted it.
Securing the ansible key
If an application needs authentication, then the application must handle LDAP/AD.
For most organizations, this is not directly reachable, but it should be this dot on the horizon to reach, as takes away a lot of attack points for hackers.
Steps and separation
We wil expain the steps in which the configuration is build, applied and managed.
First we will build and apply:
- base configuration of gateway and automation hub
- base configuration of controller
- automation team configuration (is the basis for team configs)
- other teams
And last we will automate:
- recovery
- team creation
- team deletion
- execution environment creation
- execution environment deletion
- collection creation
- collection deletion
This is a bold plan, and a lot of work, but since I have allready created the same things for automation platform 2.4, this is merely adapting the same to a new platform structure. The vast changes to the platform do not make this an easy task.
I will try to update this regularly, as I am doing this beside my work.
Advantages of the organizations setup
Configuring rhaap where each team has its own organization has some direct advantages in security:
- Credentials are never shared
- Instance groups must be assigned
- Teams have almost full control over their environment in rhaap
- Teams have their own config as code repository for rhaap
- Teams can be end-to-end responsible
Credentials are (almost) never shared
For some credentials you might want them "just being present" and not managed by the team, these are defined in the base_config. Other credentials can be added by the team themselves to be used in their templated and wokflows. The team has full control over credentials in their own repositories.
Instance group must be assigned
Instance groups are part of the global configuration and are owned by the controller. For added security, you can create an execution nodes/pods for a team that can only access the machines that are under the control of this team. Then assign this instance_group to the team in that organization with the use role like:
First create the instance_group through the file group_vars/dev/controller_instance_groups.yml You should do this in the controller_base_config, keeping the control over the instance groups centralized as this is part of security.
---
controller_instance_groups_dev:
- name: ig_lnx
instances:
- rhaap25.homelab
state: present
Then create a role for each team in that organization to be able to "use" the instance_group.
This is done is the file group_vars/dev/controller_roles.yml in controller_base_config.
---
controller_roles_dev:
- instance_groups:
- ig_lnx
teams:
- LDAP_LNX_Admins
- LDAP_LNX_Developers
- LDAP_LNX_Operators
organization: ORG_LNX
role: use
Now users in the organization can see the instance group and add this to their job templates.
And by implementing the configuration specified in these pages, you are on your way to a problem free and secure by design installation.
Security can be tightend more by adding external credential management tools, but that is not the scope of these pages, read the product documentation for this.
EDA controller configuration
The EDA default configuration is created on installation. For usage of Event Driven Ansible, please read the documentation.
I will not cover the configuration as code for EDA just yet, I must first work with it some more and understand the ins- and outs of the product.
Additionally, there are a number of issues that prevent a full config as code solution:
- At first glance it looks like it will be hard to recover from code, as it uses tokens that can only be created from the UI, this is not implemented to be in config as code, so I will not try for this moment.
- The infra.aap_configuration collection needs to implement the user/role management roles for EDA, which are not in there at the moment, if these are implemented, I will try to create something like config as code, but this will require manual steps, to create tokens and adding them to the gitlab repository.
I will check the collection regularly for updates.
Using EDA is ssomething entirely different, when configured correctly, it will work, but be sure to document what you configured and how you did it!
When the configuration as code is possible, you can simply follow you documentation to create the configuration.
Gitlab organization
To make full use of the gitlab features we need to use it as the source of thruth for our canfiguration as code, we have to explain how we organized things to make this work.
It all starts with organizing things and structuring it in a way that it is easy to understand, but also to be able to make use af the variable features gitlab gives us. I'll
show you the structure we use in gitlab and why, this is essential for our piplines to run.
The structure of groups and repo's
From the gitlab root we created the following structure:
.
├── common_code
│ ├── cac
│ │ └── pipeline.yml
│ ├── code_dev
│ │ └── pipeline.yml
│ ├── coll
│ │ └── pipeline.yml
│ └── ee
│ └── pipeline.yml
├── configascode
│ ├── base_rhaap
│ └── rhaap_cac_new
└── new_team_group
├── project1
└── project2
The common_code group holds all pipeline scripts that are used in gitlab to keep them central and easily managed, no need to edit 20 repositories to make a minor change to the pipeline. And as the teams do not have acces to the pipeline scripting, some enhanced security against malicius code. This is a public repository where everyone has read access.
The configascode group holds all repositories where the configuration as code is managed, here all the repositories are created for the teams to create their content in automation platform. The reason for this is, that we use variables in the pipeline code to fil-in some blanks we want to manage centrally, so we don't have to edit files in each repository to update the same value. Some of these values are:
- The token to fetch collections from automation hub
- The vault secret to decrypt vaulted values
The new_team_group is essentially the gitlab group where a team has full control to create content like playbooks, roles and other content to run. This might be a already existing repository in gitlab that we do not create, it is listed here for completeness.
variables
vault_password
As every team has its own vault password, this is added as a CICD variable on each configascode subrepository. These passwords are (in our situation) 15 characters long, base64 encodable strings. All secrets in the reppository, must be encrypted with this vault password for the pipleine to run succesfully.
The base64 requirement is chosen, because the CICD variable can be masked in the pipeline logging, so it is not exposed through the pipeline logs.
token
When you want to get collections from your local automation hub, you need a token to access automation hub. To get the token initially, you had to login to automation hub and generate this token in the UI. This token does not expire, but when you use the same user on automation hub to login on the API, this token gets invalid, because the API will regenerate the token for the API session.
We use a separate account in automation hub for this and we do not use this account for anything else, so the token will no longer expire. But we need to configure the same token in all repositories, so we pass it as a variable to the pipeline. This vaiable is the same for all repositories/teams. so we add the variable on the group level (configascode).
The token is generated in the config as code and stored in the credential, no more actions needed.
It is advieable to create another separate account, to create a token ti use in your ansible.cfg, where needed, this token must be created after installation.
Chapters
Directory structure for config as code
Pipeline code for config as code
Base configuration for Automation Platform
Building execution environments
Building custom collections
At this point, the base configuration is complete.
This should enable you to configure the base configuration of a automation platform 2.5 installation.
The chapter for EDA is still missing, we will address this later, for now I will focus on creating organizations en their configuration.
Adding additional organizations
Adding additional organizations automated
Deleting organizations automated
Configuration is complete for now, we will go to our next focuspoint and this will be recovery, what use is configuration as code when there is no automated recovery process?
Almost Automated Recovery
Keep Private Hub in sync with Galaxy
Grant access rights and create workflow over organizations
Screenshots
After applying all the configuration steps described in this document, your rhaap environment could look something like this after login:
Dashboard:
Organizations overview:
Private hub repositories:
Private hub collections:
Rhaap controller credentials:
