Encryption at Rest
Encryption at Rest is a form of encryption that is designed to prevent an attacker from accessing data by ensuring it is encrypted when stored on a persistent device (see Encryption at rest with Ceph for more information). The encryption keys can be held within Ceph itself (a Monitor) or managed by a separate key manager.
The deployment steps for the encryption feature (with the Vault key manager) will be shown next.
The configuration will be contained within a YAML file. Let it be called
ceph-osd: customize-failure-domain: true osd-devices: /dev/sdb /dev/sdc osd-encrypt: true osd-encrypt-keymanager: vault source: cloud:bionic-ussuri ceph-mon: customize-failure-domain: true monitor-count: 3 expected-osd-count: 3 source: cloud:bionic-ussuri
The required configuration options to enable encryption are:
This option enables full disk encryption for newly added storage devices via Ceph’s Ceph’s dm-crypt support. It protects data-at-rest from unauthorised usage.
This option specifies the encryption key management software to use. The default is ‘ceph’ and the alternative is ‘vault’. For the latter, the OSD encryption keys will be stored within Vault.
Example deploy commands would look like this:
juju deploy -n 3 --config ./ceph-encrypted.yaml ceph-osd juju deploy -n 3 --to lxd:0,lxd:1,lxd:2 --config ./ceph-encrypted.yaml ceph-mon juju add-relation ceph-osd:mon ceph-mon:osd
As before, a containerised Monitor is located on each storage node and the assumption has been made that the machines spawned in the first command are assigned the IDs of 0, 1, and 2.
Additional commands will be required for the encryption aspect of the deployment. We will need to deploy Vault for managing the encryption keys and PostgreSQL to act as a database backend. Both applications will be containerised on a new host and neither of them will require configuration options.
juju deploy --to lxd vault juju deploy --to lxd:3 postgresql
Two relations will be needed. One between Vault and PostgreSQL and one between Vault and the OSDs:
juju add-relation vault:db postgresql:db juju add-relation vault:secrets ceph-osd:secrets-storage
Once the deployment settles down Vault will be in a sealed state. The last task before the cluster is ready for usage is to Initialise and unseal Vault. This is achieved by following these instructions.
juju status output for this deployment will look very similar to this:
Model Controller Cloud/Region Version SLA Timestamp ceph-encrypted my-controller my-maas/default 2.8.1 unsupported 00:41:14Z App Version Status Scale Charm Store Rev OS Notes ceph-mon 15.2.3 active 3 ceph-mon jujucharms 48 ubuntu ceph-osd 15.2.3 active 3 ceph-osd jujucharms 303 ubuntu postgresql 12.2 active 1 postgresql jujucharms 208 ubuntu vault 1.1.1 active 1 vault jujucharms 39 ubuntu Unit Workload Agent Machine Public address Ports Message ceph-mon/0 active idle 0/lxd/0 10.0.0.140 Unit is ready and clustered ceph-mon/1* active idle 1/lxd/0 10.0.0.139 Unit is ready and clustered ceph-mon/2 active idle 2/lxd/0 10.0.0.141 Unit is ready and clustered ceph-osd/0 active idle 0 10.0.0.133 Unit is ready (1 OSD) ceph-osd/1* active idle 1 10.0.0.134 Unit is ready (1 OSD) ceph-osd/2 active idle 2 10.0.0.135 Unit is ready (1 OSD) postgresql/0* active idle 3/lxd/0 10.0.0.138 5432/tcp Live master (12.2) vault/0* active idle 3/lxd/1 10.0.0.137 8200/tcp Unit is ready (active: true, mlock: disabled) Machine State DNS Inst id Series AZ Message 0 started 10.0.0.133 node1 focal default Deployed 0/lxd/0 started 10.0.0.140 juju-66369d-0-lxd-0 focal default Container started 1 started 10.0.0.134 node2 focal default Deployed 1/lxd/0 started 10.0.0.139 juju-66369d-1-lxd-0 focal default Container started 2 started 10.0.0.135 node3 focal default Deployed 2/lxd/0 started 10.0.0.141 juju-66369d-2-lxd-0 focal default Container started 3 started 10.0.0.136 node4 focal default Deployed 3/lxd/0 started 10.0.0.138 juju-66369d-3-lxd-0 focal default Container started 3/lxd/1 started 10.0.0.137 juju-66369d-3-lxd-1 focal default Container started