charm-deployment-guide/deploy-guide/source/app-encryption-at-rest.rst
Liam Young 64efc26da9 Add Certificate Lifecycle Management Appendix
Add Certificate Lifecycle Management Appendix. Since setting up
Vault is common between Encryption at Rest and Certificate
Lifecycle management, it has been moved to its own appendix
which can be referenced by EaR and CLM.

Change-Id: I867f938fc9e836334469d4fc2eb102fd32bb69e6
2018-06-11 15:37:36 +01:00

3.0 KiB

Appendix D: Encryption at Rest

Overview

As of the 18.05 release, the OpenStack charms support encryption of data in three key areas - local ephemeral instance storage for Nova instances, Ceph OSD block devices and Swift Storage block devices.

The objective of this feature is to mitigate the risk of data compromise in the event that disks or full servers are removed from data center deployments.

Encryption of underlying block devices is performed using dm-crypt with LUKS; key management is provided by Vault, which provides secure encrypted storage of the keys used for each block device with automatic sealing of secrets in the event of reboot/restart of services.

The objective of this feature is to mitigate the risk of data compromise in the event that disks or full servers are removed from data center deployments.

Vault

See Appendix C Vault

Enabling Encryption

Encryption is enable via configuration options on the nova-compute, swift-storage and ceph-osd charms and a relation to the vault application:

juju config swift-storage encrypt=true
juju config nova-compute encrypt=true ephemeral-device=/dev/bcache2
juju config ceph-osd osd-encrypt=true osd-encrypt-keymanager=vault
juju add-relation swift-storage:secrets-storage vault:secrets
juju add-relation nova-compute:secrets-storage vault:secrets
juju add-relation ceph-osd:secrets-storage vault:secrets

Note

Encryption is only enabled during the initial preparation of the underlying block devices by the charms; enabling these options post deployment will not enable encryption on existing in-use devices. As a result its best to enable this options as part of an overlay bundle for during initial deployment.

Security Design Notes

Consuming application units access Vault using a Vault AppRole and associated policy which is specific to each machine in the deployment; The AppRole enforces uses of a secret id and access is only permitted from the configured network address of the consuming unit. The associated policy only allows the consuming unit to store and retrieve secrets from a specific secrets back-end under a specific sub path (in this case the hostname of the unit).

The secret id for the AppRole is retrieved out-of-band from Juju by the consuming charm; a one-shot retrieval token is provided over the relation from vault to each consuming application which is specific to each unit which can be used to retrieve the actual secret id; the token also has a limited ttl (2 hours) and the call must originate from the configured network address of the consuming unit. The secret id is only ever visible to the consuming unit and vault itself, providing an additional layer of protection for deployments.

LUKS encryption keys are never store on local disk; vaultlocker is used to encrypt and store the key in vault, and to retrieve the key and open encrypted block devices during boot. Keys are only ever held in memory.