Chapter 10. Configure disk encryption

10.1. Configuring Network-Bound Disk Encryption key servers

Prerequisites

Procedure

  1. Start and enable the tangd service:

    Run the following command on each Network-Bound Disk Encryption (NBDE) key server.

    # systemctl enable tangd.socket --now
  2. Verify that hyperconverged hosts have access to the key server.

    1. Log in to a hyperconverged host.
    2. Request a decryption key from the key server.

      # curl key-server.example.com/adv

      If you see output like the following, the key server is accessible and advertising keys correctly.

      {"payload":"eyJrZXlzIjpbeyJhbGciOiJFQ01SIiwiY3J2IjoiUC01MjEiLCJrZXlfb3BzIjpbImRlcml2ZUtleSJdLCJrdHkiOiJFQyIsIngiOiJBQ2ZjNVFwVmlhal9wNWcwUlE4VW52dmdNN1AyRTRqa21XUEpSM3VRUkFsVWp0eWlfZ0Y5WEV3WmU5TmhIdHhDaG53OXhMSkphajRieVk1ZVFGNGxhcXQ2IiwieSI6IkFOMmhpcmNpU2tnWG5HV2VHeGN1Nzk3N3B3empCTzZjZWt5TFJZdlh4SkNvb3BfNmdZdnR2bEpJUk4wS211Y1g3WHUwMlNVWlpqTVVxU3EtdGwyeEQ1SGcifSx7ImFsZyI6IkVTNTEyIiwiY3J2IjoiUC01MjEiLCJrZXlfb3BzIjpbInZlcmlmeSJdLCJrdHkiOiJFQyIsIngiOiJBQXlXeU8zTTFEWEdIaS1PZ04tRFhHU29yNl9BcUlJdzQ5OHhRTzdMam1kMnJ5bDN2WUFXTUVyR1l2MVhKdzdvbEhxdEdDQnhqV0I4RzZZV09vLWRpTUxwIiwieSI6IkFVWkNXUTAxd3lVMXlYR2R0SUMtOHJhVUVadWM5V3JyekFVbUIyQVF5VTRsWDcxd1RUWTJEeDlMMzliQU9tVk5oRGstS2lQNFZfYUlsZDFqVl9zdHRuVGoifV19","protected":"eyJhbGciOiJFUzUxMiIsImN0eSI6Imp3ay1zZXQranNvbiJ9","signature":"ARiMIYnCj7-1C-ZAQ_CKee676s_vYpi9J94WBibroou5MRsO6ZhRohqh_SCbW1jWWJr8btymTfQgBF_RwzVNCnllAXt_D5KSu8UDc4LnKU-egiV-02b61aiWB0udiEfYkF66krIajzA9y5j7qTdZpWsBObYVvuoJvlRo_jpzXJv0qEMi"}

10.2. Configuring hyperconverged hosts as Network-Bound Disk Encryption clients

10.2.1. Defining disk encryption configuration details

  1. Log in to the first hyperconverged host.
  2. Change into the hc-ansible-deployment directory:

    # cd /etc/ansible/roles/gluster.ansible/playbooks/hc-ansible-deployment
  3. Make a copy of the luks_tang_inventory.yml file for future reference.

    cp luks_tang_inventory.yml luks_tang_inventory.yml.backup
  4. Define your configuration in the luks_tang_inventory.yml file.

    Use the example luks_tang_inventory.yml file to define the details of disk encryption on each host. A complete outline of this file is available in Understanding the luks_tang_inventory.yml file.

  5. Encrypt the luks_tang_inventory.yml file and specify a password using ansible-vault.

    The required variables in luks_tang_inventory.yml include password values, so it is important to encrypt the file to protect the password values.

    # ansible-vault encrypt luks_tang_inventory.yml

    Enter and confirm a new vault password when prompted.

10.2.2. Executing the disk encryption configuration playbook

Prerequisites

Procedure

  1. Log in to the first hyperconverged host.
  2. Change into the hc-ansible-deployment directory.

    # cd /etc/ansible/roles/gluster.ansible/playbooks/hc-ansible-deployment
  3. Run the following command as the root user to start the configuration process.

    # ansible-playbook -i luks_tang_inventory.yml tasks/luks_tang_setup.yml --tags=blacklistdevices,luksencrypt,bindtang --ask-vault-pass

    Enter the vault password for this file when prompted to start disk encryption configuration.

Verify

  • Reboot each host and verify that they are able to boot to a login prompt without requiring manual entry of the decryption passphrase.
  • Note that the devices that use disk encryption have a path of /dev/mapper/luks_sdX when you continue with Red Hat Hyperconverged Infrastructure for Virtualization setup.

Troubleshooting

  • The given boot device /dev/sda2 is not encrypted.

    TASK [Check if root device is encrypted] 
    fatal: [server1.example.com]: FAILED! => {"changed": false, "msg": "The given boot device /dev/sda2 is not encrypted."}

    Solution: Reinstall the hyperconverged hosts using the process outlined in Section 6.1, “Installing hyperconverged hosts”, ensuring that you select Encrypt my data during the installation process and follow all directives related to disk encryption.

  • The output has been hidden due to the fact that no_log: true was specified for this result.

    TASK [gluster.infra/roles/backend_setup : Encrypt devices using key file] 
    failed: [host1.example.com] (item=None) => {"censored": "the output has been hidden due to the fact that no_log: true was specified for this result", "changed": true}

    This output has been censored in order to not expose a passphrase. If you see this output for the Encrypt devices using key file task, the device failed to encrypt. You may have provided the incorrect disk in the inventory file.

    Solution: Clean up the deployment attempt using Cleaning up Network-Bound Disk Encryption after a failed deployment. Then correct the disk names in the inventory file.

  • Non-zero return code from Tang server

    TASK [gluster.infra/roles/backend_setup : Download the advertisement from tang server for IPv4] * failed: [host1.example.com] (item={url: http://tang-server.example.com}) => {"ansible_index_var": "index", "ansible_loop_var": "item", "changed": true, "cmd": "curl -sfg \"http://tang-server.example.com/adv\" -o /etc/adv0.jws", "delta": "0:02:08.703711", "end": "2020-06-10 18:18:09.853701", "index": 0, "item": {"url": "http://tang-server.example.com"}, "msg": "non-zero return code*", "rc": 7, "start": "2020-06-10 18:16:01.149990", "stderr": "", "stderr_lines": [], "stdout": "", "stdout_lines": []}

    This error indicates that the server cannot access the url provided, either because the FQDN provided is incorrect or because it cannot be found from the host.

    Solution: Correct the url value provided for the NBDE key server or ensure that the url value is accessible from the host. Then run the playbook again with the bindtang tag:

    # ansible-playbook -i luks_tang_inventory.yml tasks/luks_tang_setup.yml --ask-vault-pass --tags=bindtang
  • For any other playbook failures, use the instructions in Cleaning up Network-Bound Disk Encryption after a failed deployment to clean up your deployment. Review the playbook and inventory files for incorrect values and test access to all servers before executing the configuration playbook again.