controller_roles.yml

In these files we configure the roles for automation controller.
We will probably do this on each environment separately, as the hostnames differ.

The infra.aap_configuration collection expects the vaules in the variable: controller_roles. As we intend to configure everything just once, we spit the set of vars into the environments and join the lists in the main.yml, before calling the collection. If there are no roles defined, do not add this file. If you do, ensure the file is present in all branches, with the correct content, described below.

WARNING be very sure everything you define here, exists in the specified environment, or else your configuretion will fail! Check, check...double check.

group_vars/all/controller_roles.yml

Here we see an empty set for all.

---
controller_roles_all: []
...

But you can already see that the variable name used here has the "_all" extension, so the variable will not be overridden as this is not quite a inventory.
Why we do this, will become clear in a moment.

group_vars/dev/controller_roles.yml

In this file we give teams within the organization access to certain resources.
Only organization admin members (LDAP_NEW_Admins team) have default access to all resources, for the developers and operators groups, you must grant access here.

---
controller_roles_dev:
# This is one way to do access management, secure, but labour intensive
- job_templates:
      - ORG_NEW_job_template_1
      - ORG_NEW_job_template_2
      - ORG_NEW_job_template_3
      - ORG_NEW_job_template_4
      - ORG_NEW_job_template_5
      - ORG_NEW_job_template_6
    team: LDAP_NEW_Developers
    role: admin

  - projects:
      - ORG_NEW_project_1
      - ORG_NEW_project_2
      - ORG_NEW_project_3
      - ORG_NEW_project_4
      - ORG_NEW_project_5
      - ORG_NEW_project_6
      - ORG_NEW_project_7
    team: LDAP_NEW_Developers
    role: admin

# The sorter way for developers:
- organization: ORG_NEW
  teams:
    - LDAP_NEW_Developers
  roles:
    - job_template_admin
    - project_admin
    - inventory_admin
    - notification_admin
    - workflow_admin
# the above gives admin rights to all user objects in the organization to the teams mentioned  
# no need to update for new objects, just remove the item they don't need before running this.  
# No organization admin rights are granted. 
# The above shorter way could also be written as follows:  
- team: LDAP_NEW_Developers
  role: job_template_admin
  lookup_organization: ORG_NEW

- team: LDAP_NEW_Developers
  role: project_admin
  lookup_organization: ORG_NEW

- team: LDAP_NEW_Developers
  role: inventory_admin
  lookup_organization: ORG_NEW

- team: LDAP_NEW_Developers
  role: notification_admin
  lookup_organization: NEW

- team: LDAP_NEW_Developers
  role: workflow_admin
  lookup_organization: ORG_NEW
# Which is essentially the same, but you can easy diffentiate between separate rights.  
# Note the use of lookup_organization, sometimes rhaap will give error 500, then use this.  


- job_templates:
    - ORG_NEW_job_template_1
    - ORG_NEW_job_template_2
  team: LDAP_NEW_Operators
  role: execute

- workflows:
    - ORG_NEW_Workflow_1
  team: LDAP_NEW_Operators
  role: execute

...

Here the variable has the "_dev" extension, so the variable will not be overridden.

group_vars/prod/controller_roles.yml

As we do not configure extra roles in prod yet, this file is an empty set.

---
controller_roles_prod: []
  # No extra config exists
...

Here the variable has the "_prod" extension, so the variable will not be overridden.

When we run a pipeline for a certain environment, the inventory structure will provide us with 2 variables: - controller_roles_all
- controller_roles_

We will merge these 2 variables into 1: controller_roles and feed this to the infra.aap_configuration.controller_roles role.

Back