Ansible

Ansible is an automation language and automation engine that lets you describe end-to-end IT application environments with a playbook. Ansible's simple, human-readable language allows orchestration of your application lifecycle no matter where it's deployed.

How Ansible works with DAP

Instead of all secrets moving through the Ansible Controller, each Ansible-managed remote node is responsible using its own identity to retrieve secrets from DAP.

Granting a DAP identity to Ansible hosts

The Ansible role can be used to configure a host with DAP machine identity. Using security policy, the Ansible host can be granted least-privilege access to securely retrieve only the secrets it needs. Restricting the secrets accessible to each Ansible host reduces the administrative power of each Ansible host and prevents the hosts from becoming high value targets. Integrating with DAP provides additional benefits, including storing security policy as code and simplified secret rotation.

To grant your Ansible host a DAP identity, you first must install the DAP Ansible Role in your playbook directly:

 
$ ansible-galaxy install cyberark.conjur-host-identity

Once you've done this, you can configure each Ansible node with a DAP identity by including a section like the example below in your Ansible playbook:

 
- hosts: servers
  roles:
    - role: cyberark.conjur-host-identity
      conjur_appliance_url: 'https://conjur.myorg.com/api',
      conjur_account: 'myorg',
      conjur_host_factory_token: "{{lookup('env', 'HFTOKEN')}}",
      conjur_host_name: "{{inventory_hostname}}"

This example:

  • registers the host with DAP, adding it into the layer specific to the provided host factory token

  • installs Summon with the Summon Conjur provider for secret retrieval from DAP

For more information about the supported role variables, see the GitHub documentation.

Retrieving secrets from DAP

You can retrieve secrets from DAP using Summon or the conjur_variable lookup plugin

Using Summon

When you configure the Ansible node with a DAP identity using the Ansible role, you also install Summon and the Summon-Conjur Provider on the Ansible host.

With Summon installed, using DAP with a Service Manager (like SystemD) becomes a snap. Here's an example of a SystemD file connecting to DAP:

 
[Unit]
Description=DemoApp
After=network-online.target

[Service]
User=DemoUser
ExecStart=/usr/local/bin/summon --yaml 'DB_PASSWORD: !var staging/demoapp/database/password' /usr/local/bin/myapp

The above example uses Summon to retrieve the password stored in DAP at staging/myapp/database/password, set it to an environment variable DB_PASSWORD, and provide it to the demo application process. Using Summon, the secret is kept off disk. If the service is restarted, Summon retrieves the password as the application is started.

Using the conjur_variable lookup plugin

Ansible 2.5+ comes built-in with the conjur_variable lookup plugin which can be used to retrieve secrets from DAP using the controlling host's DAP identity.

In general, lookup plugins allow Ansible to access data from outside sources. They can be used in a play, in a variables file, or in a Jinja2 template for the template module.

To use the conjur_variable lookup plugin, invoke it the same way any lookup plugin is invoked:

 
vars:
  database_url: "{{ lookup('conjur_variable', '/path/to/secret') }}"