Products & Technology

Managing Ansible Automation Platform (AAP) credentials at scale with Vault

Learn how to automate SSH certificate retrieval and management through AAP, using Vault to issue signed SSH certificates on demand.

Aug 07 2025Pablo Diaz

A previous HashiCorp blog post explored how Vault eliminates static SSH keys by dynamically generating short-lived credentials. This shift in approach removed many of the operational burdens of traditional SSH key management, making access more secure and scalable. But issuing ephemeral credentials is only part of the equation — these credentials must integrate seamlessly into existing automation workflows.

This post builds on that foundation, showing how HashiCorp Vault and Red Hat Ansible Automation Platform (AAP) work together to simplify secure SSH access to remote hosts.

»The challenge: SSH in automated pipelines

Working with various organizations, I’ve seen firsthand how AAP has become a key part of automation strategies, orchestrating everything from cloud provisioning to software deployments. Behind the scenes, it relies on SSH to connect to remote systems, leaving teams with an important challenge: How do you manage credentials securely and at scale?

Traditional SSH key management presents significant hurdles:

Static SSH keys are a liability: If a key is leaked, it can grant unauthorized access to the hosts until the key is rotated.
Rotating keys is a painful process: Updating and distributing SSH keys across a fleet of machines is time-consuming and error-prone.
Enforcing access controls is complicated: Teams struggle to implement least-privilege policies without creating operational bottlenecks.

Traditional SSH key management wasn’t designed for the speed and scale of modern automation. There needs to be a better way. And there is.

»Ansible credential types and Vault integration

AAP supports dynamic credential management through plugins, and HashiCorp Vault provides a dedicated SSH secrets engine that enables AAP to request short-lived SSH certificates on demand.

»Behind the scenes: How Ansible retrieves short-lived certificates

In AAP, credential types define how authentication is handled when connecting to external systems. Before a playbook runs, AAP retrieves and applies the necessary credentials, ensuring Ansible has the right access to execute tasks on remote hosts.

Most AAP users today rely on the built-in machine credentials type, which uses a static private SSH key to authenticate to remote hosts during playbook execution. While this is functional, it comes with inherent risks. Private keys are long-lived, hard to rotate, and difficult to revoke if compromised.

This is where HashiCorp Vault transforms the process. The Vault SSH signed credentials plugin enables a dynamic authentication model, allowing AAP to fetch a short-lived SSH-signed certificate from Vault at the moment of playbook execution. So instead of relying on long-lived keys, each session receives a unique, time-bound credential (in Vault these are called dynamic secrets).

»Overview of the solution

The goal is to automate SSH certificate retrieval and management through Ansible, using Vault to issue signed SSH certificates on demand.

When an Ansible job runs in AAP and requires SSH access to a host, the AAP controller identifies the associated machine credential.
If the machine credential is configured to use a Vault-signed SSH certificate, AAP initiates a request to HashiCorp Vault.
AAP authenticates to Vault using pre-configured credentials (e.g. AppRole role ID and secret ID).
Vault verifies AAP's identity and issues a Vault token.
Using this token, AAP sends a request to the Vault SSH secrets engine endpoint (specifically, a configured role path) to sign a client public key. AAP generates this client key pair locally for the session.
Vault verifies the request against the configured role and the requesting entity's policies. If authorized, Vault acts as the certificate authority (CA) and signs the provided client public key, creating a short-lived SSH certificate.
Vault returns the signed SSH certificate (which includes validity period, allowed users, etc.) to AAP.
AAP now has the necessary credentials for the SSH session: the locally generated private key and the Vault-signed public key certificate.
AAP uses this key-certificate pair to establish SSH connections to target machines.
The target machines trust the Vault-signed certificate because their SSH daemon (sshd) has been configured to recognize Vault's CA public key as a valid signer.

This dynamic process eliminates the need to store sensitive, long-lived SSH private keys for target machines directly within AAP, providing a central, policy-driven mechanism for managing SSH access.

Diagram shows the workflow for managing AAP credentials at scale with Vault

In this example, we will:

Enable and configure the Vault SSH secrets engine to act as a CA.
Define Vault policies and an SSH signing role.
Set up a Vault AppRole for AAP authentication.
Configure AAP credentials to authenticate with Vault and dynamically retrieve SSH certificates for playbook execution.
Show how target machines trust Vault-issued SSH certificates.

»Prerequisites

For the configurations below, you will need:

HashiCorp Vault running and unsealed. For Vault installation instructions, read the Getting started with Vault guide.
Red Hat Ansible Automation Platform
Target machines: Remote hosts configured to trust Vault's SSH CA public key
- Note: This configuration step for the target machines is crucial but often outside the scope of this specific Ansible/Vault integration guide, though necessary for the solution to work end-to-end. It involves adding Vault's CA public key to /etc/ssh/trusted-user-ca-keys.pub or similar on the target Linux system).

»Configuring Vault

First, you need to enable Vault’s SSH secrets engine, which will issue SSH certificates. Then you’ll create a Vault role and policy.

»Enable the Vault SSH secrets engine

This command mounts the SSH secrets engine at the default path (ssh/):

vault secrets enable ssh

Next, configure the SSH secrets engine to allow Vault to generate certificates:

vault write ssh/config/ca generate_signing_key=true

»Define Vault roles and policies

Vault uses policies to control access and roles to define how clients can request secrets — in this case, SSH certificates. Together, they determine what AAP (or any other authenticated client) is allowed to do within the SSH secrets engine.

The first step is to create a policy that grants the necessary permissions.

»Create a policy

This policy defines the permissions required for AAP to interact with Vault’s SSH secrets engine.

The example below creates a policy named ssh-signer, which grants access to sign SSH public keys and read both the CA configuration and the CA’s public key. Optionally, it also allows the client to ask Vault to generate the SSH key pair.

Apply it using the following command:

vault policy write ssh-signer - <<EOF
 
# SSH signing policy
path "ssh/sign/ssh-signer" {
 capabilities = ["create", "update"]
}
 
# SSH key pair generation
path "ssh/issue/ssh-signer" {
 capabilities = ["create", "update"]
}
 
path "ssh/public_key" {
 capabilities = ["read"]
}
 
path "ssh/config/ca" {
 capabilities = ["read"]
}
 
EOF

»Create a role

Now that the policy is in place to define what AAP is allowed to do, the next step is to create a role that determines how SSH certificates are issued.

Create an ssh-signer-role that tells Vault what kind of certificates it can issue, for which users and domains, and how long they're valid.

Use the following command to create the role:

vault write ssh/roles/ssh-signer-role -<< "EOH \
       key_type=ca \
       algorithm_signer=rsa-sha2-256 \
       allow_user_certificates=true \
       allow_host_certificates=true \
       allowed_users="rhel" \
       allowed_domains="*" \
       default_user=rhel \
       ttl=30m \
       max_ttl=1h
EOH

In this example, the role permits issuing both user and host certificates for rhel username, which are valid for 30 minutes.

You can refer to the SSH engine API documentation to adjust settings such as allowed usernames, domains, TTLs, and certificate types to match your security requirements.

»Configuring AAP to authenticate with Vault

Now that Vault is configured to issue SSH certificates, the next step is to enable an auth method to allow AAP to authenticate with Vault and retrieve those certificates during playbook execution.

»AppRole

You will use the AppRole auth for this example, so let’s enable it:

vault auth enable approle

Then, create a role for AAP called ssh-client and bind it to the previously created ssh-signer policy.

vault write auth/approle/role/ssh-client \
        token_policies=ssh-signer \
        token_ttl=1h \
        token_max_ttl=4h \
        bind_secret_id=true

Retrieve the role_id and secret_id:

vault read -field=role_id auth/approle/role/ssh-client/role-id
 
vault write -f -field=secret_id auth/approle/role/ssh-client/secret-id

Save these values for use in the AAP credential configuration.

»AAP configuration

Now it’s time to integrate this with AAP.

»Create a Vault SSH Credential :

1. Navigate to Credentials → Automation Execution → Infrastructure → Credentials.

2. Create a new HashiCorp Vault Signed SSH credential type.

3. Enter the following:

Vault server URL
Role ID (from the previous step)
Secret ID (from the previous step)

4. Click Create credential

»Create a Vault machine credential

1. Go back to Credentials and create a new machine type credential.

2. Fill in the credential details.

Username: Must match one of the valid_principals in the Vault role (e.g. rhel).
SSH Private Key: The private key AAP you will use to authenticate to target VMs. It must match the public key you’ll register with Vault.
Signed SSH Certificate: Click the 🔑key icon to open the Secret Management System dialog.

3. Configure the secret management system

Unsigned Public Key: Paste the public key corresponding to the SSH private key.
Path to Secret: The Vault path where SSH secrets are managed (e.g. ssh).
Path to Auth: The authentication mount path in Vault (commonly approle).
Role Name: The Vault role that allows AAP to request a signed certificate (e.g. ssh-signer).
Valid Principals: The comma-separated usernames allowed to log in to the VM (e.g., rhel)

4. Save and test

Click Test to verify your configuration. If everything is set up correctly, you will see a confirmation message that the test passed.

Then click Finish to save the credential.

»Testing it all out

With your Vault and AAP configurations in place, it’s time to validate the full workflow.

»Create an Ansible Playbook

Create an inventory and a basic playbook to connect to a test VM and install Vault using the signed SSH certificate. Place this playbook in your source control repository.

---
- name: Install HashiCorp Vault on RHEL
  hosts: all
  become: yes
  gather_facts: yes
 
  tasks:
 
    - name: Get required packages
      ansible.builtin.dnf:
        name:
          - yum-utils
 
    - name: Add HashiCorp repository
      ansible.builtin.yum_repository:
        name: hashicorp
        description: "HashiCorp Stable - $basearch"
        baseurl: "https://rpm.releases.hashicorp.com/RHEL/$releasever/$basearch/stable"
        gpgkey: "https://rpm.releases.hashicorp.com/gpg"
        gpgcheck: true
        enabled: true
        state: present
 
    - name: Install vault
      ansible.builtin.yum:
        name:
          - vault
 
    - name: Verify vault installation
      ansible.builtin.command:
        cmd: vault --version
      register: vault_version
 
    - name: Print vault version
      ansible.builtin.debug:
        msg: "Vault version: {{ vault_version.stdout }}"

This playbook connects to a test RHEL-based VM using the signed SSH certificate issued by Vault. It performs the following tasks:

Installs required system packages (yum-utils).
Adds the official HashiCorp YUM repository.
Installs the latest version of Vault.
Verifies the installation by running vault --version and prints the result.

»Create a project in AAP

In the AAP UI, go to Projects → Create Project and add a Source Control Type

»Run the job

Once the job template is launched:

AAP authenticates to Vault using the configured AppRole credentials.
AAP requests a signed SSH certificate from Vault’s SSH secrets engine.
AAP uses the signed certificate along with the private key to establish an SSH connection to the target VM.
Once connected, the Ansible task (e.g. installing Vault) runs on the target host as expected.

»Security advantages of Vault-signed SSH access

This approach delivers several security and operational benefits:

Ephemeral access: SSH certificates have short lifespans, eliminating the need to rotate or revoke long-lived static keys manually.
No host-to-Vault communication: Target machines only need to trust the SSH CA public key — Vault is never directly exposed to the hosts.
Credential scoping via roles: Vault roles define which principals can request signed keys and which usernames they can impersonate, enforcing least privilege.
Granular authorization: Using AuthorizedPrincipalsFile on the VMs allows fine-grained control over who can log in, based on the signed certificate contents.
Separation of concerns: Authentication to Vault is handled by AAP through a Vault credential, decoupling identity validation from the host and the user.
Central audit trail: All interactions — Vault authentication and key signing —are re-logged centrally, improving traceability and compliance.
No additional agents or PAM systems: The solution works with native OpenSSH and doesn't require any host-level changes beyond trusting the CA public key.
Supports multiple environments: You can create isolated SSH CA backends in Vault for dev, staging, and prod — each with distinct roles and policies.

»Try it out

If you don’t already have the products for this tutorial, you can start a trial of Red Hat Ansible Automation Platform here, and you can also test out the HashiCorp-managed cloud offering of HashiCorp Vault here.

»References

Secrets & identity management