controller_credential_input_sources.yml

In these files we configure the credential input fields for credentials in the automation controller, when using a external vault.
we will probably do this on the global configuration (ALL).

group_vars/all/controller_credential_input_sources.yml

Here we see an example of the configuration for a credential to access gitlab. The fields for this credential are read from the vault when needed and the credential has no secret information in rhaap.
As the team may have some devices/apps that require additional users/passwords, they can be configured in the controller_credentials.yml and the input fields here for the organization, these are not shareable to other teams. This requires the credential to be present in the vault.

Below an example for the "extra_user" which has two input fields in the credential, these will be read from the vault at runtime.

---
controller_credential_input_sources_all:

  - source_credential: ORG_vault
    target_credential: ORG_NEW_extra_user
    input_field_name: username
    description: Fill the username from Vault
    metadata:
      secret_backend: kv
      secret_path: data/extra_user
      secret_key: username

  - source_credential: ORG_vault
    target_credential: ORG_NEW_extra_user
    input_field_name: password
    description: Fill the password from Vault
    metadata:
      secret_backend: kv
      secret_path: data/extra_user
      secret_key: password

  - source_credential: ORG_vault
    target_credential: ORG_NEW_gitlab
    input_field_name: username
    description: Fill the username from Vault
    metadata:
      secret_backend: kv
      secret_path: data/gitlab
      secret_key: username

  - source_credential: ORG_vault
    target_credential: ORG_NEW_gitlab
    input_field_name: ssh_key_data
    description: Fill the password from Vault
    metadata:
      secret_backend: kv
      secret_path: data/gitlab
      secret_key: ssh_key

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

As we do not configure extra credentials in development, this file is an empty set.

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

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

group_vars/prod/controller_credential_input_sources.yml

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

---
controller_credential_input_sources_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_credential_input_sources_all
- controller_credential_input_sources_

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

Back