Merge "spec: encryption at rest"
This commit is contained in:
Zuul
Gerrit Code Review
commit
2d93253242
338
specs/rocky/approved/encryption-at-rest.rst
Normal file
338
specs/rocky/approved/encryption-at-rest.rst
Normal file
@ -0,0 +1,338 @@
|
||||
..
|
||||
Copyright 2018, Canonical Ltd.
|
||||
|
||||
This work is licensed under a Creative Commons Attribution 3.0
|
||||
Unported License.
|
||||
http://creativecommons.org/licenses/by/3.0/legalcode
|
||||
|
||||
..
|
||||
This template should be in ReSTructured text. Please do not delete
|
||||
any of the sections in this template. If you have nothing to say
|
||||
for a whole section, just write: "None". For help with syntax, see
|
||||
http://sphinx-doc.org/rest.html To test out your formatting, see
|
||||
http://www.tele3.cz/jbar/rest/rest.html
|
||||
|
||||
======================
|
||||
Encrypted Data at Rest
|
||||
======================
|
||||
|
||||
Problem Description
|
||||
===================
|
||||
|
||||
OpenStack Clouds provide a number of different types of storage to Cloud users,
|
||||
including instance ephemeral disks (typically attached to hypervisors), Cinder
|
||||
block devices (typically backed by some sort of storage solution such as Ceph)
|
||||
and Swift object storage.
|
||||
|
||||
By default the data residing on such virtual devices is unencrypted; regulation
|
||||
such as PCI-DSS and GPDR+ require that data at rest is stored encrypted,
|
||||
so that if devices are removed from the data center, the data on them cannot
|
||||
be recovered without access to the appropriate encryption keys.
|
||||
|
||||
Proposed Change
|
||||
===============
|
||||
|
||||
Underlying storage devices will be protected using dm-crypt/LUKS with encryption
|
||||
keys stored directly in Hashicorp Vault. No local copy of the key is made during
|
||||
the encryption process or the decryption process on boot.
|
||||
|
||||
A new tool 'vaultlocker' will be used to LUKS format block devices, directly
|
||||
storing encryption keys in Vault. Keys are referenced using the UUID of the
|
||||
underlying block device (which is generated as the disk is prepared for use).
|
||||
|
||||
On (re)boot, a vaultlocker-decrypt systemd unit will execute for each encrypted
|
||||
block device, retrieving the encryption key from Vault and opening the LUKS
|
||||
formatted block device ready for use.
|
||||
|
||||
vaultlocker will access vault over https using an approle issued as part of the
|
||||
deployment process; the approle will be passed from vault to the consuming
|
||||
service via a charm relation and will be scoped for access from units
|
||||
participating in the relation to vault.
|
||||
|
||||
The approle will be specific to each unit participating in the relation, with
|
||||
a policy that only permits read/write/delete/update/list to:
|
||||
|
||||
<kv-backend>/<hostname>/*
|
||||
|
||||
from the provided network address of the unit. Approles for other units will
|
||||
be visible in the relation data, but will not be usable as the CIDR ACL will
|
||||
not permit access.
|
||||
|
||||
In addition to the unit specific approle, and limitation of access to the /32
|
||||
of the unit, a secret_id will also be used to authenticate use of the approle.
|
||||
|
||||
The secret_id will not be passed over the relation from the vault charm to the
|
||||
consuming application. Instead the vault charm will generate a secret_id and
|
||||
wrap it using Vault's response wrapping feature. The resulting one-shot token
|
||||
will be passed over the relation to the consuming application unit, which can
|
||||
then use the token to pull the secret_id directly from Vault. This ensures
|
||||
that the secret_id is only known to Vault and the consuming application unit.
|
||||
|
||||
The one-shot token has a ttl of 1h (allowing for complex deployment with large
|
||||
numbers of hook executions to complete on converged hypervisor/storage
|
||||
machines).
|
||||
|
||||
The initial scope of support will include:
|
||||
|
||||
- ceph-osd: OSD device encryption.
|
||||
- swift-storage: Block device encryption.
|
||||
- nova-compute: Ephemeral storage block device encryption; note that this
|
||||
requires that hypervisors are configured with a specific set of storage
|
||||
devices for use by Nova for ephemeral block devices for instances.
|
||||
|
||||
block device preparation
|
||||
------------------------
|
||||
|
||||
The encrypted block device will be labelled with a UUID generated by the
|
||||
charmhelper. This UUID will be used during encryption and during decryption
|
||||
during server reboots.
|
||||
|
||||
The device will be encrypted with key storage in Vault using:
|
||||
|
||||
.. code-block:: bash
|
||||
|
||||
vaultlocker encrypt --uuid $UUID $BLOCK_DEVICE
|
||||
|
||||
The resulting dm-crypt block device will be opened ready for use.
|
||||
|
||||
swift-storage and nova-compute
|
||||
------------------------------
|
||||
|
||||
Block devices will be prepared inline with "block device preparation"; existing
|
||||
fstab management by the charm will be updated to use `/dev/mapper/crypt-<UUID>`
|
||||
entries with a x-systemd.requires option - for example:
|
||||
|
||||
.. code-block:: bash
|
||||
|
||||
/dev/mapper/crypt-$UUID /mnt auto defaults,x-systemd.requires=vaultlocker-decrypt@$UUID.service,comment=vaultlocker 0 2
|
||||
|
||||
This ensures that the vaultlocker-decrypt task has completed prior to the mount
|
||||
of the mapper device being attempted.
|
||||
|
||||
ceph-osd/ceph-volume
|
||||
--------------------
|
||||
|
||||
Integration into the ceph-osd charm requires the charm to switch to using the
|
||||
new ceph-volume tool to manage the creation and activation of OSD's. This
|
||||
requires that the block device be prepared with LVM volumes before passing to
|
||||
ceph-volume; to mirror existing ceph-disk functionality:
|
||||
|
||||
filestore
|
||||
~~~~~~~~~
|
||||
|
||||
Use block device for journal and data; journal lv (osd-journal-<OSD-FSID>)
|
||||
created on vg ceph-<OSD-FSID> using configured journal size, data lv
|
||||
(osd-data-<OSD-FSID) created on vg ceph-<OSD-FSID> using remaining capacity.
|
||||
|
||||
.. code-block:: bash
|
||||
|
||||
pv /dev/sdb
|
||||
vg /dev/ceph-<OSD-FSID>
|
||||
lv /dev/ceph-<OSD-FSID/osd-journal-<OSD-FSID>
|
||||
lv /dev/ceph-<OSD-FSID/osd-data-<OSD-FSID>
|
||||
|
||||
Use separate device for journal; journal lv (osd-journal-<OSD-FSID>) created
|
||||
on vg ceph-journal-<UUID> of a journal device using configured journal size;
|
||||
data lv (osd-data-<OSD-FSID) created on ceph-<OSD-FSID> of data device
|
||||
using 100% of capacity.
|
||||
|
||||
.. code-block:: bash
|
||||
|
||||
pv /dev/sdb
|
||||
vg /dev/ceph-<OSD-FSID>
|
||||
lv /dev/ceph-<OSD-FSID/osd-data-<OSD-FSID>
|
||||
pv /dev/sdg
|
||||
vg /dev/ceph-journal-<UUID>
|
||||
lv /dev/ceph-journal-<UUID>/osd-journal-<OSD-FSID>
|
||||
|
||||
bluestore
|
||||
~~~~~~~~~
|
||||
|
||||
Bluestore is simpler in that there is no journal so a single logical volume
|
||||
will be created on ceph-<OSD-FSID> of the provided disk:
|
||||
|
||||
.. code-block:: bash
|
||||
|
||||
pv /dev/sdb
|
||||
vg /dev/ceph-<OSD-FSID>
|
||||
lv /dev/ceph-<OSD-FSID/osd-block-<OSD-FSID>
|
||||
|
||||
The Bluestore DB and WAL volumes may be optionally stored on separate
|
||||
devices again using a logical volume of the configured/default size on vg
|
||||
ceph-{db,wal}-<UUID>.
|
||||
|
||||
.. code-block:: bash
|
||||
|
||||
pv /dev/sdb
|
||||
vg /dev/ceph-<OSD-FSID>
|
||||
lv /dev/ceph-<OSD-FSID/osd-block-<OSD-FSID>
|
||||
pv /dev/sdg
|
||||
vg /dev/ceph-db-<UUID>
|
||||
lv /dev/ceph-db-<UUID>/osd-db-<OSD-FSID>
|
||||
pv /dev/sdh
|
||||
vg /dev/ceph-wal-<UUID>
|
||||
lv /dev/ceph-wal-<UUID>/osd-wal-<OSD-FSID>
|
||||
|
||||
Note that ceph-volume is only provided with Ceph Luminous or later releases;
|
||||
as a result encryption under Ceph Jewel is explicitly excluded from the scope
|
||||
of this specification.
|
||||
|
||||
Alternatives
|
||||
------------
|
||||
|
||||
ceph
|
||||
~~~~
|
||||
|
||||
Use of native suppport in Ceph for OSD encryption; discounted as it makes use
|
||||
of the ceph-mon cluster for key storage - keys are not sharded and deployments
|
||||
typically place ceph-mon units alongside ceph-osd units so its possible that
|
||||
the encryption keys might directly reside on the same server as encrypted
|
||||
Ceph OSD block devices.
|
||||
|
||||
.. note::
|
||||
|
||||
The ceph-osd charm already supports native Ceph block device
|
||||
encryption using ceph-disk/ceph-volume via the osd-encrypt option.
|
||||
|
||||
Support for use of vault could be added to ceph-volume; however due to the
|
||||
requirement to support existing Ceph releases (>= Luminous) this option
|
||||
is discounted in the short term but may be considered in the long term if
|
||||
support lands into Ceph upstream.
|
||||
|
||||
cinder
|
||||
~~~~~~
|
||||
|
||||
Cinder has native support for block device encryption using LUKS; keys are
|
||||
stored using Barbican which relies on HSM's implementing PKCS#11 of KMIP to
|
||||
be considered secure. This would provide the required level of encryption
|
||||
support for Cinder block devices however does require use of a hardware
|
||||
based security module (Barbican does not have Vault support).
|
||||
|
||||
nova
|
||||
~~~~
|
||||
|
||||
Nova has native support for encryption of ephemeral disks if using an LVM
|
||||
backend for storage; again keys are stored in barbican, requiring use of a
|
||||
HSM or implementation of support for a suitable Software Security Module in
|
||||
Barbican. Use of this option is also limited to LVM storage only.
|
||||
|
||||
swift
|
||||
~~~~~
|
||||
|
||||
Swift has no native encryption support so no alternatives considered for this
|
||||
part of the problem domain.
|
||||
|
||||
Implementation
|
||||
==============
|
||||
|
||||
Assignee(s)
|
||||
-----------
|
||||
|
||||
Primary assignee:
|
||||
|
||||
james-page
|
||||
|
||||
Gerrit Topic
|
||||
------------
|
||||
|
||||
Use Gerrit topic "vaultlocker" for all patches related to this spec.
|
||||
|
||||
.. code-block:: bash
|
||||
|
||||
git-review -t vaultlocker
|
||||
|
||||
Work Items
|
||||
----------
|
||||
|
||||
vaultlocker
|
||||
~~~~~~~~~~~
|
||||
|
||||
- base codebase (support for encrypt/decrypt)
|
||||
- unit tests
|
||||
- functional tests
|
||||
|
||||
QA
|
||||
~~
|
||||
|
||||
- mojo specification to validate encryption-at-rest support
|
||||
|
||||
Docs
|
||||
~~~~
|
||||
|
||||
- example bundle + documentation for encryption-at-rest
|
||||
- appendix for deployment guide on usage and security considerations
|
||||
|
||||
charmhelpers
|
||||
~~~~~~~~~~~~
|
||||
|
||||
- block device encryption helper
|
||||
|
||||
ceph-osd
|
||||
~~~~~~~~
|
||||
|
||||
- add support for use of ceph-volume >= Luminous
|
||||
- enable support for block device encryption using vaultlocker
|
||||
- add relation to vault
|
||||
|
||||
swift-storage
|
||||
~~~~~~~~~~~~~
|
||||
|
||||
- enable support for block device encryption using vaultlocker
|
||||
- add relation to vault
|
||||
|
||||
nova-compute
|
||||
~~~~~~~~~~~~
|
||||
|
||||
- enable support for block device encryption using vaultlocker
|
||||
- add relation to vault
|
||||
|
||||
Repositories
|
||||
------------
|
||||
|
||||
A new repository will be required for vaultlocker.
|
||||
|
||||
Documentation
|
||||
-------------
|
||||
|
||||
Documentation will be provided as part of the ceph-osd, swift-storage
|
||||
and nova-compute charms.
|
||||
|
||||
An additional appendix will be added to the charm deployment guide to
|
||||
cover encryption at rest.
|
||||
|
||||
Security
|
||||
--------
|
||||
|
||||
As this solution covers the security of encryption keys used to secure
|
||||
block devices from unauthorized removal there are multiple security
|
||||
concerns to address.
|
||||
|
||||
Communication with Vault will be done over a TLS encrypted connection
|
||||
using an AppRole (without a secret_id) for authentication which will be
|
||||
delivered to the consuming charm over a charm relation; connectivity with
|
||||
Juju also TLS encrypted so the potential for interception of the AppRole
|
||||
is limited.
|
||||
|
||||
The secret_id for the unit to use with the AppRole is passed out-of-band
|
||||
of Juju - a one-shot token is passed over the vault-kv relation, which
|
||||
can only be used by the consuming unit to retrieve the generated
|
||||
secret_id for the AppRole. The token has a 1hr TTL and is CIDR limited
|
||||
in the same way as the AppRole.
|
||||
|
||||
Encryption keys will be stored under a Vault path specific to the AppRole.
|
||||
The Vault AppRole will limit access to the secrets backend based on the
|
||||
CIDR of the accessing servers.
|
||||
|
||||
Testing
|
||||
-------
|
||||
|
||||
Functionality will be validated by unit and functional tests within
|
||||
each component.
|
||||
|
||||
Overall solution function will be validated using a Mojo spec.
|
||||
|
||||
Dependencies
|
||||
============
|
||||
|
||||
- Production grade vault charm.
|
||||
- AppRole interface to vault charm.
|
||||
Loading…
Reference in New Issue
Block a user