Secure Ansible Secrets Management Using External KMS

Infrastructure as Code (IaC) tools like the open-source engine Ansible have become central to modern DevOps practices. They allow teams to cross-platform automate provisioning, orchestration, configuration, and application deployment efficiently.

This helps to:

• Eliminate repetition and simplify workflows
• Easy management of system configuration
• Continuously deploy complex software
• Perform zero-downtime rolling updates

However, as automation scales, managing sensitive data such as passwords, tokens, and API keys becomes a critical security challenge.

Why Ansible Needs Secure Secrets Management

Ansible is a powerful, agentless automation tool used widely for configuration management, application deployment, and orchestration. Its simplicity lies in using YAML files (playbooks) and an extensive library of modules. However, this simplicity introduces security risks, particularly around secrets management.

The Problem Without External KMS

Out of the box, Ansible provides a few methods to handle secrets:

1. Plain-text inclusion in playbooks or inventory files.
2. Use of Ansible vault to encrypt sensitive files.

The first option is clearly very insecure and extremely hard to manage. The second option Ansible vault, though offering encryption, has several limitations:

• Secrets are not stored at a secure location and can be harvested rather easily.
• Vault passwords are often shared manually or hardcoded into scripts, which is risky.
• It doesn’t provide centralized access control or audit trails.
• Scaling secret usage across teams or environments becomes cumbersome.

In modern enterprise environments, these limitations can be problematic. Teams require a centralized, secure, and compliant way to manage secrets that supports:

• Hardware protection of secrets.
• Fine-grained access control.
• Rotation policies.
• Integration with enterprise identity systems.
• Auditing and logging.

This is where an external Key Management System (KMS) comes into play.

Integrating Ansible with an External KMS

Using an external KMS with Ansible allows secrets to be stored securely outside the playbooks and only retrieved at runtime. This improves both security and compliance, especially in regulated environments.

General Approach to KMS Integration

Ansible can retrieve secrets from external systems using lookup plugins. These plugins allow dynamic fetching of data during playbook execution. The general flow when using a KMS via a plugin is:

1. Secrets are stored in the KMS with proper access controls and protection.
2. Ansible is configured to use a custom or community-provided lookup plugin.
3. At runtime, the plugin fetches the secret securely using an API call to the KMS.
4. The secret is injected into the playbook execution context securely and temporarily.

This method provides multiple advantages:

• Secrets are not stored in source control.
• Access to secrets is logged and audited by the KMS.
• Secrets can be rotated without updating playbooks.

Secrets Management in Ansible with Fortanix DSM

Fortanix Data Security Manager (DSM), is a powerful key and secrets management platform. It offers high levels of security through hardware-backed key storage up to FIPS 140-2 Level 3, encryption-as-a-service, and robust access controls. Integrating Fortanix DSM with Ansible allows secrets to be managed centrally while being retrieved securely at runtime.

Architecture Overview

Figure 1 shows a high-level architecture diagram of an Ansible secrets management with external DSM deployment.

Figure 1: Ansible Secrets Management with DSM as External KMS

This diagram features the following entities:

1. Ansible Control Node: Ansible server, which consists of:

1. Ansible Core: Foundational engine of the Ansible framework.
2. inventory.ini: List of hosts that shall be managed by Ansible.
3. playbook.yaml: Lists of tasks that automatically execute on specified hosts, which are defined in inventory.ini.
4. lookup_plugins: Container of the Ansible plugin to retrieve secrets from DSM through REST API.

2. Managed Nodes: Nodes that are to be managed by Ansible and are defined in inventory.ini.

3. Fortanix DSM: The KMS that stores all secrets securely and makes them available on request.

Plugin Behavior

The Python lookup plugin works as follows:

1. Authentication: The plugin authenticates to Fortanix DSM using an API key or client certificate.
2. API Communication: It queries the DSM API to fetch the secret by name or UUID.
3. Secure Fetching: The secret is decrypted by DSM and returned to the plugin.
4. Usage in Playbook: The plugin injects the value directly into the playbook variable context.

Benefits of Fortanix DSM Integration

• Zero Trust: Secrets have not persisted outside of DSM.
• Secure Runtime Access: Secrets are accessed only when needed.
• Auditability: Every access is logged in a tamper-protected audit log.
• Secure Access Control: Access to the secrets is protected by Role Based Access Control (RBAC) and strong user authentication.
• Compliance: Supports FIPS 140-2 Level 3, GDPR, and other compliance standards.
• Seamless Rotation: DSM supports secret rotation without changing playbooks.

Conclusion

Ansible is a powerful automation tool, but its native secrets management capabilities can be limiting for enterprise use. Integrating Ansible with an external Key Management System like Fortanix DSM provides a scalable, secure, and compliant solution for managing secrets.

Using a lookup plugin, secrets can be dynamically retrieved from Fortanix DSM, ensuring that sensitive data never lives unsecured and is tightly controlled with audit-ready visibility. As security and compliance requirements grow, such integrations are becoming not just helpful—but essential.

For more information, please contact Fortanix.