- Blog post • 8 min read
Ansible Secrets: A Practical Guide to Secure Automation at Scale
- Published on
Ansible is an open-source automation tool, and Red Hat offers it as part of Red Hat Ansible Automation Platform. It has become one of the leading choices for configuration management and application deployment across countless servers worldwide. Its agentless architecture and human-readable YAML playbooks make it accessible to teams of all sizes. But like any other tool in your stack, it needs access to sensitive credentials, your secrets.
Secrets are like keys that unlock different parts of your technology stack. These credentials range from API keys to SSH certificates to cloud provider tokens. Managing them properly is critical for maintaining security without introducing unnecessary hurdles at scale.
The challenge is keeping these secrets secure while preserving the simplicity that makes Ansible effective. This is where proper secrets management becomes essential, especially as frameworks and regulations like SOC 2, GDPR, and HIPAA often require strong controls such as encryption, access controls, and auditability.
Ansible provides its own native solution called Ansible Vault for encrypting sensitive data. However, modern secret management platforms like Infisical offer more advanced capabilities, including automatic rotation, centralized management, and detailed audit trails.
In this guide, we’ll explore both approaches, their trade-offs, and help you choose the right solution for your automation needs.
Understanding Ansible Vault
Ansible Vault is Ansible’s built-in encryption feature that allows you to protect sensitive data within your projects. Rather than storing passwords, keys, and other secrets in plain text, Vault encrypts this information using the AES256 cipher (AES-256). This makes it reasonable to store encrypted secret files in version control, as long as vault passwords are protected and rotated appropriately.
Ansible Vault operates at two levels:
- File-level encryption: Encrypts entire YAML files
- Variable-level encryption: Encrypts individual strings (inline variables) within otherwise plain-text files
You can also use multiple vault IDs to manage different passwords for different environments or teams, providing flexibility in how you organize and protect your secrets.
Creating and Managing Encrypted Secrets
Setting Up Your First Encrypted File
Start by creating an encrypted variables file for your sensitive data:
# Create a new encrypted file with interactive password prompt ansible-vault create group_vars/production/secrets.yml # Or encrypt an existing file ansible-vault encrypt group_vars/production/database.yml
When you run these commands, Ansible will prompt you for a vault password. This password becomes the key to decrypting your secrets, so store it securely.
Encrypting Individual Variables
Sometimes you only need to protect specific values rather than entire files. With Ansible Vault, you can encrypt individual strings:
# Encrypt a single value
ansible-vault encrypt_string 'P@ssw0rd123!' --name 'database_password'
# This outputs YAML you can paste directly into your playbooks:
database_password: !vault |
$ANSIBLE_VAULT;1.1;AES256
66386439653236336...
Working with Encrypted Content
Once files are encrypted, you’ll need the vault password to view or modify them. Add this by using the rekey, decrypt, and edit features of Ansible’s CLI.
# Edit an encrypted file (opens in your default editor) ansible-vault edit secrets.yml # View contents without editing ansible-vault view secrets.yml # Decrypt a file permanently (use with caution!) ansible-vault decrypt secrets.yml # Change the encryption password ansible-vault rekey secrets.yml
Integrating Secrets into Ansible Playbooks
Basic Usage
Next, we need to explore how to use vault-encrypted variables in a typical playbook. First, we need to configure the vars_files.
---
- name: Configure web application
hosts: webservers
vars_files:
- vars/common.yml
- vars/secrets.yml # This file is encrypted
tasks:
- name: Deploy database configuration
template:
src: database.conf.j2
dest: /etc/app/database.conf
mode: '0600'
no_log: true # Prevents secrets from appearing in logs
Environment-Specific Secrets
Then, we must organize secrets by environment using Ansible’s directory structure. This looks like:
ansible-project/ ├── group_vars/ │ ├── all/ │ │ └── common.yml │ ├── production/ │ │ ├── vars.yml │ │ └── secrets.yml # Encrypted │ └── staging/ │ ├── vars.yml │ └── secrets.yml # Encrypted with different password
Executing Playbooks with Encrypted Data
After, several options exist for providing vault passwords during execution. There are three main strategies:
- Using
--ask-vault-passto prompt a password - Using
--vault-password-fileto feed a password file - Using
--vault-idto provide different IDs for different environments with a password file.
# Interactive password prompt ansible-playbook deploy.yml --ask-vault-pass # Password file (keep this file secure and out of version control!) echo 'your_vault_password' > .vault_pass chmod 600 .vault_pass ansible-playbook deploy.yml --vault-password-file .vault_pass # Multiple vault IDs for different environments ansible-playbook deploy.yml \\ --vault-id production@.vault_pass_prod \\ --vault-id staging@.vault_pass_stage
Security Best Practices
There are two critical practices when handling Ansible secrets.
Set no_log: true on tasks that touch secrets to reduce the chance of leaking sensitive values in output and logs (with the caveat that some debugging modes and edge cases can still reveal data).
- name: Task handling sensitive data
mysql_user:
name: appuser
password: "{{ mysql_password }}"
priv: '*.*:ALL'
no_log: true # Critical: prevents password from appearing in output
Second, using the shell command, you can pass environmental variables to external tools:
- name: Use environment variables for external tools
shell: |
export API_KEY="{{ api_secret }}"
./deploy-script.sh
environment:
API_KEY: "{{ api_secret }}"
no_log: true
Limitations and Challenges
While Ansible Vault solves the immediate problem of encrypting secrets, it comes with significant operational challenges:
- Manual Rotation Burden: Vault provides no automated way to rotate credentials. When you need to update a password, you must manually edit each encrypted file, update the value, and ensure all systems receive the new credential.
- Team Collaboration Friction: Sharing vault passwords securely across team members is surprisingly difficult. Teams often resort to insecure practices, such as sharing passwords through chat or email, undermining the security Vault provides.
- No Audit Trail: Vault doesn’t track who accessed or modified secrets. For compliance requirements or security investigations, you’re left without crucial visibility into secret usage.
- Static Secrets Only: Unlike modern secrets management systems, Vault cannot generate temporary, auto-expiring credentials. Every secret is long-lived until manually changed.
- Scale Complexity: Managing multiple vault passwords across different environments, projects, and teams quickly becomes a logistical nightmare.
However, these can easily be solved by integrating Ansible with a more robust solution like Infisical.
A Modern Alternative: Infisical Integration
For teams requiring more robust secrets management, Infisical offers a native Ansible integration that addresses Vault’s limitations while maintaining ease of use.
Key Advantages
Using a dedicated secrets manager like Infisical with Ansible solves the core challenges. Specifically, it provides:
- Automatic rotation with zero downtime
- Centralized management across all your tools and platforms
- Complete audit logs for compliance and security
- Dynamic secrets that expire automatically
- Fine-grained access control with role-based permissions
To set-up Infisical and Ansible, there are two easy steps.
Step 1: Installing the Infisical Collection
Install the Infisical collection from Ansible Galaxy, Ansible’s package manager.
# Install the collection $ ansible-galaxy collection install infisical.vault # Install required Python package $ pip install infisicalsdk
Step 2: Dynamic Secret Retrieval
Then, replace static encrypted files with dynamic secret fetching from Infisical. And just like that, secrets can be managed from Infisical.
- name: Deploy with Infisical secrets
hosts: webservers
gather_facts: false
tasks:
- name: Login to Infisical (cache auth once)
infisical.vault.login:
url: "https://app.infisical.com"
auth_method: universal_auth
universal_auth_client_id: "{{ vault_client_id }}"
universal_auth_client_secret: "{{ vault_client_secret }}"
register: infisical_login
no_log: true
- name: Read secrets as a dictionary
infisical.vault.read_secrets:
login_data: "{{ infisical_login.login_data }}"
project_id: "proj_abc123"
env_slug: "production"
path: "/database"
as_dict: true
register: db_secrets
no_log: true
- name: Use the secret
debug:
msg: "DB password is set (redacted)"
vars:
db_password: "{{ db_secrets.secrets.PRIMARY_PASSWORD }}"
Making the Right Choice
For really small teams or simple projects, Ansible Vault may be sufficient. It’s built-in, straightforward, and requires no additional infrastructure. Start there if you’re just beginning to secure your playbooks.
However, for production environments, consider a dedicated secrets management solution like Infisical. A dedicated solution provides:
- Automatic credential rotation
- Audit trails for compliance
- Centralized secrets across multiple tools
- Dynamic, temporary credentials
- Team-based access controls
The transition from Vault to a dedicated secrets manager doesn’t have to be all-or-nothing. Many teams start with Vault for development environments while using enterprise solutions for production, gradually migrating as their needs grow.
Your Next Step: Standardize Secrets Management
Securing secrets when using Ansible is not optional. It's a fundamental requirement for responsible infrastructure automation. Book easy wins like eliminating hardcoded credentials in your application today. Use Ansible Vault as your baseline protection, ensuring all sensitive data is encrypted before it hits version control.
As your automation practice matures, evaluate whether Vault’s limitations are holding you back. Modern secrets management platforms like Infisical can eliminate the manual burden of secret rotation while providing the audit trails and access controls that enterprise environments demand.
Remember: the best secrets management strategy is the one your team will actually use. Choose tools that enhance rather than hinder your automation workflows, and make security a seamless part of your development process.
