nbde_client

Ansible role for configuring Network-Bound Disk Encryption clients (e.g. clevis).

This role currently supports clevis as a provider and it uses it for operations like encryption and decryption.

Supported Distributions

• RHEL-7+, CentOS-7+
• Fedora

Limitations

This role can currently create tang bindings. TPM2 is not supported as of now.

Role Variables

These are the variables that can be passed to the role:

Variable	Default/Choices	Description
nbde_client_provider	clevis	identifies the provider for the nbde_client role. We currently support clevis.
nbde_client_bindings		a list containing binding configurations, which include e.g. devices and slots.

nbde_client_bindings

nbde_client_bindings is a list of dictionaries that support the following keys:

Name	Default/Choices	Description
device		specifies the path of the backing device of an encrypted device on the managed host. This device must be already configured as a LUKS device before using the role (REQUIRED).
passphrase		a valid passphrase for opening/unlocking the specified device. Recommend vault encrypting the passphrase. See https://docs.ansible.com/ansible/latest/user_guide/vault.html
key_file		either the absolute or relative path, on the control node, of a key file valid for opening/unlocking the specified device.
state	present / absent	specifies whether a binding with the configuration described should be added or removed. Setting state to present (the default) means a binding will be added; setting state to absent means a binding will be removed from the device/slot.
slot	1	specifies the slot to use for the binding.
servers		specifies a list of servers to bind to. To enable high availability, specify more than one server here.
threshold	1	specifies the threshold for the Shamir Secret Sharing (SSS) scheme that is put in place when using more than one server. When using multiple servers, threshold indicates how many of those servers should succeed, in terms of decryption, in order to complete the process of recovering the LUKS passphrase to open the device.
passphrase_temporary	no	If yes, the passphrase that was provided via the passphrase or key_file arguments will be used to unlock the device and then it will be removed from the LUKS device after the binding operation completes, i.e. it will not be valid anymore. To be used if device has been previously created with a dummy passphrase (for example by an automated install like kickstart that set up some sort of "default" password), which the role should replace by a stronger one.

Example:

nbde_client_bindings:
  - device: /dev/sda1
    key_file: /vault/keyfile
    state: present
    slot: 2
    threshold: 1
    passphrase_temporary: no
    servers:
      - http://server1.example.com
      - http://server2.example.com

Example Playbooks

Example 1: high availability

---
- hosts: all
  vars:
    nbde_client_bindings:
      - device: /dev/sda1
        # recommend vault encrypting the passphrase
        # see https://docs.ansible.com/ansible/latest/user_guide/vault.html
        passphrase: password
        servers:
          - http://server1.example.com
          - http://server2.example.com
  roles:
    - linux-system-roles.nbde_client

Example 2: remove binding from slot 2 in /dev/sda1

---
- hosts: all
  vars:
    nbde_client_bindings:
      - device: /dev/sda1
        # recommend vault encrypting the passphrase
        # see https://docs.ansible.com/ansible/latest/user_guide/vault.html
        passphrase: password
        slot: 2
        state: absent

  roles:
    - linux-system-roles.nbde_client

License

MIT