Create custom credentials for Event-Driven Ansible

Create custom credential types (via JSON/YAML) to define unique security fields and logic, enabling support for proprietary event sources or specialized authentication.

Each credential type displays its own unique configurations in the Input Configuration and the Injector Configuration fields, if applicable. Both YAML and JSON formats are supported in the configuration fields.

Custom credentials support Ansible extra variables as a means of injecting their authentication information.

You can attach one or more cloud, vault, and Red Hat Ansible Automation Platform credential types to a rulebook activation.

Note
  • When creating a new credential type, you must avoid collisions in the extra_vars.
  • Extra variable names must not start with EDA_ because they are reserved.
  • You must have System administrator (superuser) permissions to be able to create and edit a credential type and to be able to view the Injector configuration field.

When you customize your own credential types, they display on the Credential Types page along with a list of built-in credential types.

Input configuration
Copy link

You can configure the input fields and define which parameters are required when a user creates a credential of this custom type.

The Input configuration has two attributes:

  • fields - a collection of properties for a credential type.
  • required - a list of required fields.

Fields can have multiple properties, depending on the credential type you select.

Expand
Table 1. Input Configuration Field Properties
Fields Description Mandatory (Y/N)

id

Unique id of the field; must be a string type and stores the variable name

Yes

type

Can be string or boolean type

No, default is string

label

Used by the UI when rendering the UI element

Yes

secret

Will be encrypted

No, default false

multiline

If the field contains data from a file the multiline can be set to True

No, default false

help_text

The help text associated with this field

No

Injector configuration
Copy link

You can use Injector configuration to safely transform and map credential data from input fields so that it can be correctly exposed and consumed by ansible-rulebook at runtime.

Event-Driven Ansible supports the following types of injectors:

  • Environment variables (env) - Used in source plugins for the underlying package or shared library.
  • Ansible extra variables (extra_vars) - Used for substitution in the rulebook conditions, actions or source plugin parameters.
  • File-based templating (file) - Used to create file contents from the credential inputs such as certificates and keys, which might be required by source plugins. File injectors provide a way to deliver these certificates and keys to ansible-rulebook at runtime without having to store them in decision environments. As a result, ansible-rulebook creates temporary files and the file names can be accessed using eda.filename variables, which are automatically created for you after the files have been created (for instance, "{{eda.filename.my_cert}}”).
Important

When creating extra_vars in rulebook activations and credential type injectors, avoid using eda or ansible as key names since that conflicts with internal usage and might cause failure in both rulebook activations and credential type creation.

Injectors enable you to adjust the fields so that they can be injected into a rulebook as one of the above-mentioned injector types, which cannot have duplicate keys at the top level. If you have two sources in a rulebook that both require parameters such as username and password, the injectors, along with the rulebook, help you adapt the arguments for each source.

Creating a new credential type
Copy link

Define a custom credential type by using a YAML or JSON schema. Defining these custom types helps ensure that authentication information is securely injected into automation workflows.

Procedure
Copy link

  1. From the navigation panel, select Automation Execution > Infrastructure > Credentials.
  2. In the Credential Types view, click Create credential type.
  3. Enter the appropriate details in the Name and Description field.
    Note

    When creating a new credential type, do not use reserved variable names that start with ANSIBLE_ for the INPUT and INJECTOR names and IDs, as they are invalid for custom credential types.
  4. In the Input configuration field, specify an input schema that defines a set of ordered fields for that type. The format can be in YAML or JSON:

    YAML 

    fields:
  - type: string
    id: username
    label: Username
  - type: string
    id: password
    label: Password
    secret: true
required:
  - username
  - password

    View more YAML examples at the YAML page.

    JSON 

    {
"fields": [
  {
  "type": "string",
  "id": "username",
  "label": "Username"
  },
  {
  "secret": true,
  "type": "string",
  "id": "password",
  "label": "Password"
   }
  ],
 "required": ["username", "password"]
}

    View more JSON examples at The JSON website.

    The following configuration in JSON format shows each field and how they are used:

    {
  "fields": [{
    "id": "api_token",    # required - a unique name used to reference the field value

    "label": "API Token", # required - a unique label for the field

    "help_text": "User-facing short text describing the field.",

    "type": ("string" | "boolean")   # defaults to 'string'

    "choices": ["A", "B", "C"]   # (only applicable to `type=string`)

    "format": "ssh_private_key"  # optional, can be used to enforce data format validity
                                 for SSH private key data (only applicable to `type=string`)

    "secret": true,       # if true, the field value will be encrypted

    "multiline": false    # if true, the field should be rendered as multi-line for input entry
                          # (only applicable to `type=string`)
},{
    # field 2...
},{
    # field 3...
}],

"required": ["api_token"]   # optional; one or more fields can be marked as required
},

    When type=string, fields can optionally specify multiple choice options:

    {
  "fields": [{
      "id": "api_token",    # required - a unique name used to reference the field value
      "label": "API Token", # required - a unique label for the field
      "type": "string",
      "choices": ["A", "B", "C"]
  }]
},
  5. In the Injector configuration field, enter environment variables or extra variables that specify the values a credential type can inject. The format can be in YAML or JSON (see examples in the previous step).

    The following configuration in JSON format shows each field and how they are used:

    {
  "file": {
      "template": "[mycloud]\ntoken={{ api_token }}"
  },
  "env": {
      "THIRD_PARTY_CLOUD_API_TOKEN": "{{ api_token }}"
  },
  "extra_vars": {
      "some_extra_var": "{{ username }}:{{ password }}"
  }
}

    Credential Types can also generate temporary files to support .ini files or certificate or key data:

    {
  "file": {
      "template": "[mycloud]\ntoken={{ api_token }}"
  },
  "env": {
      "MY_CLOUD_INI_FILE": "{{ tower.filename }}"
  }
}

    In this example, automation controller writes a temporary file that has:

    [mycloud]\ntoken=SOME_TOKEN_VALUE

    The absolute file path to the generated file is stored in an environment variable named MY_CLOUD_INI_FILE.

    The following is an example of referencing many files in a custom credential template:

    Inputs 

    {
  "fields": [{
    "id": "cert",
    "label": "Certificate",
    "type": "string"
  },{
    "id": "key",
    "label": "Key",
    "type": "string"
  }]
}

    Injectors 

    {
  "file": {
    "template.cert_file": "[mycert]\n{{ cert }}",
    "template.key_file": "[mykey]\n{{ key }}"
},
"env": {
    "MY_CERT_INI_FILE": "{{ tower.filename.cert_file }}",
    "MY_KEY_INI_FILE": "{{ tower.filename.key_file }}"
}
}
  6. Click Create credential type.

    Your newly created credential type is displayed on the list of credential types:

    New credential type

  7. Click the Edit Edit icon to modify the credential type options.
    Note

    In the Edit screen, you can modify the details or delete the credential. If the Delete option is disabled, this means that the credential type is being used by a credential, and you must delete the credential type from all the credentials that use it before you can delete it.

Results
Copy link

  • Verify that the newly created credential type can be selected from the Credential Type selection window when creating a new credential:

Verify new credential type