Skip to main content

What is a Credential?

A Credential in AWX contains authentication information required to connect to remote systems, cloud providers, or external services. Credentials securely store passwords, SSH keys, API tokens, and other sensitive data, making them available to jobs without exposing them to users.
Credentials are AWX’s secure vault for authentication data - they enable automation to access systems while maintaining security best practices.

Core Concepts

Credential Types

AWX supports multiple credential types (awx/main/models/credential.py:429-442):

Credential Structure

From the Credential model (awx/main/models/credential.py:122-175):
Key fields:
  • name: Credential name (unique per organization and type)
  • credential_type: Type defining what fields are available
  • organization: Optional organization for scoping
  • inputs: Dictionary of credential-specific values
  • managed: System-managed credentials (not user-editable)

Credential Inputs

Each credential type defines its own input fields. For example, SSH credentials:

Secret Fields

Secret fields are automatically encrypted:
Users see $encrypted$ instead of actual values when viewing credentials.

Retrieving Input Values

Credentials provide a secure interface for accessing values:

Ask at Runtime

Certain credential fields can be marked for prompting:
When launching a job with credentials that need passwords, users must provide them.

Credential Types

Credential types define the schema and behavior of credentials (awx/main/models/credential.py:414-576):

Input Schema

Defines what fields a credential has:

Injector Schema

Defines how credentials are injected into jobs:
Injectors can provide:
  • Environment variables: Set in job execution environment
  • Files: Written to temporary files
  • Extra variables: Passed as Ansible extra vars

Managed vs Custom Types

AWX includes managed credential types that cannot be modified:
Users can create custom credential types for specific needs:

External Credentials

AWX supports external credential plugins for fetching secrets from external vaults:

Credential Input Sources

From awx/main/models/credential.py:603-680:
Example: Fetch SSH password from CyberArk:
  1. Create CyberArk credential (external type)
  2. Create SSH credential with input source:
    • Target field: password
    • Source: CyberArk credential
    • Metadata: {"object_query": "Safe=MySafe;Object=ssh-password"}
At runtime, AWX fetches the password from CyberArk:

Multiple Credentials

Jobs can use multiple credentials simultaneously:
Rules:
  • One SSH/machine credential
  • Multiple vault credentials (for different vault IDs)
  • Multiple cloud credentials
  • Multiple network credentials
Some credential types are mutually exclusive (e.g., only one SSH credential per job). AWX validates this during job launch.

Vault Credentials

Vault credentials support multiple vault IDs:
Multiple vault credentials with different IDs can be used together.

API Endpoints

List Credentials

Create SSH Credential

Create AWS Credential

Create Vault Credential

Test Credential (External)

Permissions

Credentials have the following roles (credential.py:157-175):
  • Admin Role: Full control over the credential
  • Use Role: Can use credential in jobs
  • Read Role: Can view credential metadata (not secrets)
Credential permissions are scoped to organizations. Users can only assign credentials to resources in the same organization.

Role Validation

AWX validates role assignments:

Security Best Practices

Integrate with CyberArk, HashiCorp Vault, or other external vaults to avoid storing sensitive credentials in AWX.
For highly sensitive passwords, use “ASK” to prompt at runtime rather than storing them.
Always set the organization field to limit credential access to organization members.
Grant only “use” role to users who need to run jobs. Reserve “admin” for credential managers.
Establish a process for rotating credentials, especially SSH keys and API tokens.
Instead of storing sensitive variables in plain text, use Ansible Vault and vault credentials.

Credential Injection

During job execution, AWX injects credentials using the injector schema:
This ensures credentials are:
  • Decrypted only during job execution
  • Injected into the isolated execution environment
  • Never exposed in logs or output
  • Cleaned up after job completion