Red Hat Summit Red Hat SummitSupportConsoleDevelopersStart a trialContact

Chapter 3. Credential types

Event-Driven Ansible controller comes with several built-in credential types that you can use for syncing projects, running rulebook activations, executing job templates through Automation Execution (automation controller), fetching images from container registries, and processing data through event streams.

These built-in credential types are not editable. So if you want credential types that support authentication with other systems, you can create your own credential types that can be used in your source plugins. Each credential type contains an input configuration and an injector configuration that can be passed to an Ansible rulebook to configure your sources. For more information, see Custom credential types.

If you will be executing job templates through automation controller, you can retrieve credential values from external secret management systems listed in External secret management credential types.

3.1. External secret management credential types
Copy link

In addition to the built-in credential types, Event-Driven Ansible supports a variety of external secret management credential types. These credential types allow rulebooks to securely retrieve sensitive information, such as API keys and passwords, directly from your organization’s centralized secret vault.

The following external credential types are available for use in Event-Driven Ansible controller:

  • AWS Secrets Manager
  • Azure Key Vault
  • Centrify Vault Credential Provider
  • CyberArk Central Credential Provider
  • CyberArk Conjur Secrets Manager
  • HashiCorp Vault Secret
  • HashiCorp Vault Signed SSH
  • Thycotic DevOps Secrets Vault
  • Thycotic Secret Server
  • GitHub App Installation Access Token

The process for using these credentials in a rulebook activation is consistent with how they are used in automation controller. For more information, see Secret management system.

Additional references

3.2. Custom credential types
Copy link

As a system administrator, you can define a custom credential type that works in ways similar to existing credential types in a standard format using a YAML or JSON-like definition.

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.

3.2.1. Input Configuration
Copy link

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 3.1. Input Configuration Field Properties
FieldsDescriptionMandatory (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

3.2.2. Injector Configuration
Copy link

You can use Injector configuration to extract information from Input configuration fields and map them into injector types that can be sent to ansible-rulebook when running a rulebook activation. 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.

To view a sample injector and input, see the following GitHub gists, respectively:

3.3. Creating a new credential type
Copy link

You can create a credential type to use with a source plugin that you select based on the supported, default credential types. You can make your credential type available to a team or individuals.

Procedure

  1. Log in to the Ansible Automation Platform Dashboard.
  2. From the navigation panel, select Automation Decisions Infrastructure Credential Types.
  3. Click Create credential type.

  4. Insert the following:

    Name
    Insert the name.
    Description
    This field is optional.

  5. 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
    Copy to Clipboard Toggle word wrap

    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"]
}
    Copy to Clipboard Toggle word wrap

    View more JSON examples at The JSON website.

  6. 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: 

    {
    "extra_vars": {
      "some_extra_var": "{{ username }}:{{ password }}"
  }
}
    Copy to Clipboard Toggle word wrap

  7. Click Create credential type.

    Your newly created credential type is displayed in the list of credential types.

  8. Click the Edit credential type Edit icon to modify the credential type options.

Verification

  • Verify that the newly created credential type can be selected from the Credential Type list when creating a new credential.

Next steps

  • On the Edit page, 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.

Additional resources

Setting up credentials.

Back to top
Red Hat logoGithubredditYoutubeTwitter

Learn

Try, buy, & sell

Communities

About Red Hat Documentation

We help Red Hat users innovate and achieve their goals with our products and services with content they can trust. Explore our recent updates.

Making open source more inclusive

Red Hat is committed to replacing problematic language in our code, documentation, and web properties. For more details, see the Red Hat Blog.

About Red Hat

We deliver hardened solutions that make it easier for enterprises to work across platforms and environments, from the core datacenter to the network edge.

Theme

© 2025 Red Hat