Add organization

Now we have a base configuration, want to start adding additional organizations to this to be able to utilize the platform as it is intended.
Adding an organization to this configuration will need changes to the base configuration as described earlier.
Before we can automate the addition of a new team, we must know how to do this by hand.
In this part of the configuration description, we will be adding the NEW organization, so anywhere you see NEW, this points to the organization name.

Analyse changes

The first thing we have to do is analyse which files arer changed to add a team. The second step is to describe what changes we made to every file in the complete configuration (for base- and controller). These changes will be crucial to implement a new team.

Base gateway config changes

This configuration part is in a separate repository(rhaap_config_part_1), so it must be handled as such.
There are organization specific changes in the following files in alphabetical order:

• gateway_authenticator_maps.yml
• gateway_organizations.yml
• gateway_role_user_assignments.yml
• gateway_teams.yml
• gateway_users.yml

As the automation hub is managed by the automation team, no roles have to be mapped here.

Base controller config changes

This cofiguration is in a separate repository(rhaap_config_part_2), so it must be handled as such.
In this configuration we need to make certain changes to give the new organization access to some credentials, therefore the following files need to be changed:

• controller_credentials.yml

Here the pull secrets for the automation hub are configured centrally, so if they are changed, the change can be managed centrally, whithout changing the configuration of all organizations.

Changes to base config by files

Now we know which files were modified, we need to know what the changes are.

gateway_authenticator_maps.yml

As the configuration of most AD/LDAP servers is global to the entire environment, the most likely place to add this is in the "ALL" branch.
For the NEW organization, the following must be added to the file:

We standardized the naming of the groups in AD/LDAP, so we can generate the group names from the team name in automation platform. This reduces the need for extra parameters added to the survey of the play later on.

# # BEGIN BLOCK ORG_NEW ANSIBLE MANAGED BLOCK ORG_NEW
  - name: ORG_NEW-members
    authenticator: Auth LDAP container
    revoke: true
    map_type: organization
    organization: ORG_NEW
    role: Organization Member
    triggers:
      always: {}
      never: {}
      groups:
        has_and:
          - cn=ug-new,ou=groups,dc=homelab,dc=wf

  - name: ORG_NEW-admins
    authenticator: Auth LDAP container
    revoke: true
    map_type: organization
    organization: ORG_NEW
    role: Organization Admin
    triggers:
      always: {}
      never: {}
      groups:
        has_and:
          - cn=g-aap-new-a,ou=groups,dc=homelab,dc=wf

  - name: ORG_NEW-admin-team
    authenticator: Auth LDAP container
    revoke: true
    map_type: role
    organization: ORG_NEW
    team: LDAP_NEW_Admins
    role: Team Member
    triggers:
      always: {}
      never: {}
      groups:
        has_and:
          - cn=g-aap-new-a,ou=groups,dc=homelab,dc=wf

  - name: ORG_NEW-D
    authenticator: Auth LDAP container
    revoke: true
    map_type: team
    organization: ORG_NEW
    team: LDAP_NEW_Developers
    role: Team Member
    triggers:
      always: {}
      never: {}
      groups:
        has_and:
          - cn=g-aap-new-d,ou=groups,dc=homelab,dc=wf

  - name: ORG_NEW-O
    authenticator: Auth LDAP container
    revoke: true
    map_type: team
    organization: ORG_NEW
    team: LDAP_NEW_Operators
    role: Team Member
    triggers:
      always: {}
      never: {}
      groups:
        has_and:
          - cn=g-aap-new-o,ou=groups,dc=homelab,dc=wf
# # END BLOCK ORG_NEW ANSIBLE MANAGED BLOCK ORG_NEW
...

This whole section can be simply generated using the team_name as input.

gateway_organizations.yml

The 'NEW' organization needs to be created, so we add it to the file.
We add ORG_ to every organization (convention) so we know it is automaticly generated and ansible managed.
Not at this point yet, but it will be soon.

---
aap_organizations_all:
  - name: MGT
    description: 'Automation platform managent'
# # BEGIN BLOCK ORG_NEW ANSIBLE MANAGED BLOCK ORG_NEW
  - name: ORG_NEW
    description: 'Organization for team NEW'
# # END BLOCK ORG_NEW ANSIBLE MANAGED BLOCK ORG_NEW
...

gateway_teams.yml

The teams for the organization are created by us, and not through the mapping on the AD, however this can be done, but this way we can be sure that roles assigned to these groups are correctly in place as we run this code. As the teams are only created through the mapping as the user authenticates.

  # START ansible managed ORG_NEW teams
  - name: LDAP_NEW_Admins
    organization: ORG_NEW
    description: Organization Admins (LDAP)
  - name: LDAP_NEW_Developers
    organization: ORG_NEW
    description: Organization Developers (LDAP)
  - name: LDAP_NEW_Operators
    organization: ORG_NEW
    description: Organization Operators (LDAP)
  # END ansible managed ORG_NEW teams
...

gateway_users.yml

Just one (local)user is added here, this is the organization admin that runs the configuration as code pipeline and can access rhaap even if the AD/LDAP is unreachable. Every organization has its own organization admin, so there is no way to grant access to another organization through manipulation of the configuration as code. Do not use system admin here

# # BEGIN BLOCK ORG_NEW ANSIBLE MANAGED BLOCK ORG_NEW
  - username: CaC_admin_NEW
    password: <password>
    email:
    first_name: admin
    last_name: admin for NEW
    is_superuser: false
# # END BLOCK ORG_NEW ANSIBLE MANAGED BLOCK ORG_NEW

gateway_role_user_assignments.yml

Here we match the organization admin with his organization and grant him the access he needs to configure his own organization.

# # BEGIN BLOCK ORG_NEW ANSIBLE MANAGED BLOCK ORG_NEW
  - role_definition: Organization Admin
    user: CaC_admin_NEW
    org_name: ORG_NEW
# # END BLOCK ORG_NEW ANSIBLE MANAGED BLOCK ORG_NEW

controller_credentials.yml

The secrets that will be used by this organization for fetching collections and excution_environments, are not created for each organization.
These secrets are already defined for the default organization and will be shared among all organizations.
This way we only have to update them once when the token expires for some reason.

controller_organization.yml

In this file we add a section for each organization that maps the hub secrets of the default organization to the new organization.

---

aap_organizations_dev:
  - name: ORG_NEW
    galaxy_credentials:
      - Default_automation_hub_token_community
      - Default_automation_hub_token_rh_certified
      - Default_automation_hub_token_published

controller_roles.yml

In this file we add the new organization to the section that enables the organization to use the secrets for the hub. Add the organization_name under the organizations: key.

  - organizations:
      - ORG_NEW
      - ORG_INFRA
      - ORG_WEB
    credentials:
      - Default_automation_hub_token_published
      - Deafult_automation_hub_token_community
      - Default_automation_hub_token_rh_certified
    role: use

These are the changes we need to be able to start a team with its own repository. At this point we need to run the pipelines for both repositories in the correct sequence.
If this is done, we can start filling in the new organization from a fresh repository.

Once this is done and you see the organization in automation platform with a CaC_admin_NEW organization admin, we can create the repository for the organization. This repository will hold the configuration for the team content in all rhaap environments.

For any new team, we create a repository with base content like described in the following page:

Organization repository

Back