controller_credentials.yml

In these files we configure the credentials for automation controller.
we will probably do this on the global configuration (ALL).
You will see a small difference in the lookup credentials (namespace), this determines if the value is read for production or development.

The infra.aap_configuration collection expects the vaules in the variable: controller_credentials. 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 credentials defined, do not add this file. If you do, ensure the file is present in all branches, with the correct content, described below.

group_vars/all/controller_credentials.yml

Here we see an example of the configuration for a credential to access gitlab. All secrets are read from the external vault, so the inputs are not defined here.
As the team may have some devices/apps that require additional users/passwords, they can be configured here for the organization, these are not shareable to other teams.

---
controller_credentials_all:

  - name: ORG_NEW_gitlab
    description:
    credential_type: Source Control
    organization: ORG_NEW

  - name: ORG_NEW_extra_user
    credential_type: OS user
    organization: ORG_NEW

  - name: ORG_vault
    description: Org Specific Vault Secret Lookup
    organization: ORG
    credential_type: HashiCorp Vault Secret Lookup
    inputs:
      url: "{{ vault_url }}"
      token: "{{ vault_token }}"
      namespace: "{{ branch_name }}/{{ org_name }}"
      api_version: v1
      default_auth_path: token

Using the variables branch_name, org_name , vault_url and vault_token from main.yml wil dynamicly create the ORG_vault credential differently in each environment, this helps to prevent configuration drift, by defining this once and not in each enviironment separately.

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_credentials.yml

As we do configure a lookup credential in development, this credential is used in the controller_credential_input_sources.yml. If there is no vault, you can omit this.

---
controller_credentials_dev: []

...

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

group_vars/prod/controller_credentials.yml

---
controller_credentials_prod: []

...

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_credentials_all
- controller_credentials_

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

Back