Your submission was sent successfully! Close

You have successfully unsubscribed! Close

Thank you for signing up for our newsletter!
In these regular emails you will find the latest updates about Ubuntu and upcoming events where you can meet our team.Close

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-encrypted.yaml:

  customize-failure-domain: true
  osd-devices: /dev/sdb /dev/sdc
  osd-encrypt: true
  osd-encrypt-keymanager: vault
  source: cloud:bionic-ussuri

  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.

Eventually, the 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                Unit is ready and clustered
ceph-mon/1*    active    idle   1/lxd/0                Unit is ready and clustered
ceph-mon/2     active    idle   2/lxd/0                Unit is ready and clustered
ceph-osd/0     active    idle   0                Unit is ready (1 OSD)
ceph-osd/1*    active    idle   1                Unit is ready (1 OSD)
ceph-osd/2     active    idle   2                Unit is ready (1 OSD)
postgresql/0*  active    idle   3/lxd/0      5432/tcp  Live master (12.2)
vault/0*       active    idle   3/lxd/1      8200/tcp  Unit is ready (active: true, mlock: disabled)

Machine  State    DNS         Inst id              Series  AZ       Message
0        started  node1                focal   default  Deployed
0/lxd/0  started  juju-66369d-0-lxd-0  focal   default  Container started
1        started  node2                focal   default  Deployed
1/lxd/0  started  juju-66369d-1-lxd-0  focal   default  Container started
2        started  node3                focal   default  Deployed
2/lxd/0  started  juju-66369d-2-lxd-0  focal   default  Container started
3        started  node4                focal   default  Deployed
3/lxd/0  started  juju-66369d-3-lxd-0  focal   default  Container started
3/lxd/1  started  juju-66369d-3-lxd-1  focal   default  Container started

This page was last modified 1 year, 22 days ago. Help improve this document in the forum.