--- title: "Ansible Secrets: A Practical Guide to Secure Automation at Scale" canonical: "https://infisical.com/blog/ansible-secrets" published: "2026-02-05" last-updated: "2026-02-08" source-index: https://infisical.com/llms.txt --- # Ansible Secrets: A Practical Guide to Secure Automation at Scale [Ansible](https://www.redhat.com/en/ansible-collaborative) 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](https://infisical.com/blog/api-key-management) to [SSH certificates](https://infisical.com/blog/ssh-certificates-guide) 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](https://www.aicpa-cima.com/topic/audit-assurance/audit-and-assurance-greater-than-soc-2), [GDPR](https://gdpr.eu/what-is-gdpr/), and [HIPAA](https://www.hhs.gov/hipaa/for-professionals/privacy/laws-regulations/index.html) often require strong controls such as encryption, access controls, and auditability. Ansible provides its own native solution called [Ansible Vault](https://docs.ansible.com/ansible/latest/vault_guide/index.html) 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](https://docs.ansible.com/ansible/latest/vault_guide/vault_encrypting_content.html) * **Variable-level encryption**: [Encrypts individual strings (inline variables)](https://docs.ansible.com/ansible/latest/vault_guide/vault_encrypting_content.html#advantages-and-disadvantages-of-encrypting-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:
```shell # 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:
```shell # 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.
```shell # 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-pass` to prompt a password * Using `--vault-password-file` to feed a password file * Using `--vault-id` to 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 [email protected]_pass_prod \\ --vault-id [email protected]_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](https://infisical.com/docs/integrations/platforms/ansible) 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**](https://infisical.com/blog/secret-rotation-vs-dynamic-secrets) with zero downtime * **Centralized management** across all your tools and platforms * **Complete [audit logs](https://infisical.com/docs/documentation/getting-started/concepts/audit-logs)** for compliance and security * [**Dynamic secrets**](https://infisical.com/blog/secret-rotation-vs-dynamic-secrets) that expire automatically * **Fine-grained access control** with [role-based permissions](https://infisical.com/docs/documentation/platform/access-controls/role-based-access-controls) To set-up Infisical and Ansible, there are two easy steps. ### Step 1: Installing the Infisical Collection Install the Infisical collection from [Ansible Galaxy](https://galaxy.ansible.com/ui/), 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](https://infisical.com/docs/documentation/platform/dynamic-secrets/overview) 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](https://docs.ansible.com/ansible/2.9/user_guide/vault.html) 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](https://infisical.com/blog/secrets-management-best-practices) 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.
/blog/ansible-secrets.md · raw source