AAP 2.6 Credential Management: Vaults, External Secrets, and Machine Credentials
By Luca Berton · Published 2024-01-01 · Category: events
Master credential management in AAP 2.6: machine credentials, vault passwords, cloud credentials, custom credential types, external secret backends (HashiCorp Vault, CyberArk, Azure Key Vault), and credential rotation best practices.
Why Credential Management Matters in AAP
Automation at enterprise scale means managing hundreds of credentials: SSH keys, API tokens, cloud provider secrets, database passwords, and vault passwords. AAP 2.6's credential system provides: • Centralized storage — one place for all automation credentials • RBAC-controlled access — teams see only the credentials they need • External secret backends — pull secrets at runtime from HashiCorp Vault, CyberArk, AWS Secrets Manager • Audit logging — track who used which credential and when • No plaintext exposure — credentials never appear in job output or logs
Built-in Credential Types
AAP 2.6 ships with credential types for common use cases:
| Credential Type | Purpose | Key Fields | |----------------|---------|------------| | Machine | SSH/WinRM access to managed hosts | username, password, SSH key, privilege escalation | | Source Control | Git/SVN repository access | username, password/token, SSH key | | Vault | Ansible Vault decryption | vault password | | Amazon Web Services | AWS API access | access key, secret key, STS token | | Microsoft Azure Resource Manager | Azure API access | subscription, client ID, secret, tenant | | Google Compute Engine | GCP API access | service account JSON, project | | VMware vCenter | vSphere API access | host, username, password | | Red Hat Satellite | Satellite 6 API access | host, username, password | | Container Registry | Pull EE images | host, username, password | | Galaxy/Automation Hub API Token | Collection access | URL, token |
Creating Machine Credentials
Creating Cloud Credentials
External Secret Backends
Instead of storing secrets in AAP's database, pull them at runtime from external secret management systems.
HashiCorp Vault
CyberArk
AWS Secrets Manager
Azure Key Vault
Custom Credential Types
Create custom credential types for services not covered by built-in types:
Example: Database Credential Type
Injector Types
Credential injectors control how secrets are passed to playbooks:
| Injector | Method | Use Case | |----------|--------|----------| | extra_vars | Extra variables | Most common — playbook accesses as variables | | env | Environment variables | Cloud SDKs (AWS_ACCESS_KEY_ID, etc.) | | file | Temporary file | SSH keys, certificates, kubeconfig |
Multi-Credential Job Templates
AAP 2.6 supports assigning multiple credentials to a single job template:
The playbook can access all credential values through extra variables and environment variables simultaneously.
Credential RBAC
Control who can use, view, and manage credentials:
| Permission | Can View | Can Use in Jobs | Can Edit | Can Admin | |-----------|---------|-----------------|---------|----------| | Read | ✅ | ❌ | ❌ | ❌ | | Use | ✅ | ✅ | ❌ | ❌ | | Admin | ✅ | ✅ | ✅ | ✅ |
Team members with Use permission can attach the credential to job templates but cannot view the actual secret values.
Credential Rotation Best Practices
Automated Rotation with External Backends
When using external secret backends (HashiCorp Vault, CyberArk), rotation happens externally: External system rotates the secret on its schedule AAP pulls the fresh secret at job runtime No credential updates needed in AAP
This is the recommended approach for production.
Manual Rotation Playbook
For credentials stored directly in AAP:
FAQ
Are credentials encrypted at rest in AAP?
Yes. Credentials are encrypted in the PostgreSQL database using Fernet symmetric encryption. The encryption key is stored separately from the database. Even database administrators cannot read credential values without the encryption key.
Can I export credentials from AAP?
No. By design, AAP does not allow exporting credential secret values. You can export credential metadata (name, type, organization) but not the actual secrets. This prevents credential exfiltration.
Which external secret backend should I use?
Use whatever your organization already has. HashiCorp Vault is the most common in Ansible environments. CyberArk is common in enterprises with existing PAM infrastructure. AWS Secrets Manager / Azure Key Vault are natural choices for cloud-heavy organizations.
Can job output expose credentials?
AAP automatically redacts credential values from job output. If a playbook prints a variable that contains a credential value, AAP replaces it with $encrypted$ in the output. However, be careful with no_log: false on tasks that handle secrets.
How many credentials can a job template use?
There is no hard limit. A job template can use multiple credentials of different types simultaneously. The only constraint is that you can have at most one Machine credential and one Vault credential per job template.
Conclusion
Credential management is the security foundation of AAP 2.6. By combining built-in credential types, external secret backends, custom credential types, and RBAC-controlled access, you can manage secrets at scale without compromising security. The key principle: secrets should be managed externally and pulled at runtime, never stored in playbooks or version control.
Related Articles • AAP 2.6 Security Best Practices • AAP 2.6 RBAC and Gateway API • HashiCorp Vault Integration with Ansible Automation Platform • AAP 2.6 HashiCorp Vault Integration with EDA • AAP 2.6 Architecture and Components: Complete Guide
Category: events