The Couchbase Server 7.0 Beta is now available with some additional enhancements to strengthen the security of the platform. Couchbase has always recommended that customers utilize disk encryption technologies to ensure that their data is secure as part of an overall security strategy. A new important announcement is the introduction of Couchbase Certification of LUKS On-Disk Encryption.
Before we look at encryption and how it fits into the overall picture, let’s start with looking at the 3 stages where documents reside in a Couchbase Server cluster.
Stage | Description | Example in Couchbase |
Data in Process | Active data, in system memory. | Documents which are in-use. |
Data in Transit | Data which is moving between systems. | Replication, XDCR |
Data at Rest | Data which is currently not in active use. | Buckets on the disk of an offline machine. |
Many security and regulatory standards such as PCI-DSS, FIPS, FISMA and GDPR require confidential information to be encrypted in these various stages. Data in process can be secured with Couchbase’s Field Level Encryption technology at the application layer. Couchbase components secure data in transit, also known as data on-the-wire, with TLS Encryption and X.509 Certificates. There are many ways to encrypt data-at-rest, one option that is commonly used by our customers in a Linux environment is LUKS or the Linux Unified Key Setup, we also support 3rd party providers such as Thales Vormetric.
Data at rest encryption.
It is important to understand what data-at-rest encryption is for and what it provides. The technology is used to protect storage systems which are in an offline or locked state and prevents the media being read without the appropriate authority and access. Data which is encrypted-at-rest does not remain protected while a device is online, unlocked and operational.
Encryption for data-at-rest is commonly used to protect confidential information in the event of loss or theft of assets. Most modern smartphones will use encryption at rest by default without any user configuration, sometimes this is referred to as Full-Disk Encryption. It is also used in environments where multiple users re-use the same underlying hardware such as in a cloud environment.
LUKS Disk Encryption
LUKS is a fully open-source tool that has been the de-facto standard for disk encryption in Linux environments for many years. It is included in all of our certified Linux Operating Systems and supported by those vendors. LUKS sits in the kernel layer and encrypts storage at a disk block level, allowing users to transparently deploy any file system of their choosing on top of this block level encryption. LUKS is able to encrypt storage partitions which can be presented from a single drive, multi-disk RAID arrays, Logical Volume Manager (LVM) or even file-backed partitions.
LUKS is very flexible and offers a range of cipher suites. By default in a Red Hat 8 Linux environment, LUKS will use a highly secure 512 bit AES (Advanced Encryption Standard) key. Encrypted LUKS volumes contain multiple key slots, allowing users to add backup keys or pass-phrases. There are also additional security features such as key revocation and protection for bad pass-phrases using Argon2.
LUKS is not a good option for customers deployed on non-Linux platforms, such as MacOS and Windows. It is also not recommended for customers who do not have an active Operating System vendor support contract. Standard Operating System provided encryption technologies, such as Microsoft Encrypted Filesystem (EFS) or our 3rd party encryption at rest partners are a better option for these customers.
How do I use LUKS to securely encrypt my Couchbase Server data at rest ?
There are several different ways to implement LUKS in a Linux environment, most commonly it is implemented using dm-crypt, part of the kernel level device mapper infrastructure and using the cryptsetup command line utility to set up dm-crypt targets.
I’ll give you an example of some commands I’ve used on my Ubuntu 16 Couchbase Server Cluster to set up a disk with Logical Volume Management (LVM). I will then deploy an LUKS encrypted Logical Volume and mount this as the data directory for my Couchbase Server Node. This will ensure that if my Couchbase Server is ever stolen, the confidential data in my Couchbase buckets will not be accessible to unauthorised users.
The steps provided here are useful as guidance for the Couchbase Server 7.0 Beta. The documented and supported steps to implement LUKS may change at Couchbase Server 7.0 General Availability (GA) time. The steps should be used on a Couchbase Server Node before it is added to a cluster and data is loaded into the buckets. Please also note that these steps will erase anything that is currently residing on the target disk, so please use caution and ensure that you are writing to the correct device.
The first thing I will do is install the lvm and cryptsetup utility.
1 |
sudo apt-get install lvm2 cryptsetup |
Next I will configure the drive (/dev/sdb) and create a new primary partition to use LVM.
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 |
$ sudo fdisk /dev/sdb Command (m for help): n Partition type p primary (0 primary, 0 extended, 4 free) e extended (container for logical partitions) Select (default p): p Partition number (1-4, default 1): 1 First sector (2048-2097151, default 2048): Last sector, +sectors or +size{K,M,G,T,P} (2048-2097151, default 2097151): Created a new partition 1 of type 'Linux' and of size 1023 MiB. Command (m for help): t Selected partition 1 Partition type (type L to list all types): 8e Changed type of partition 'Linux' to 'Linux LVM'. Command (m for help): p Disk /dev/sdb: 1 GiB, 1073741824 bytes, 2097152 sectors Units: sectors of 1 * 512 = 512 bytes Sector size (logical/physical): 512 bytes / 512 bytes I/O size (minimum/optimal): 512 bytes / 512 bytes Disklabel type: dos Disk identifier: 0x980c1049 Device Boot Start End Sectors Size Id Type /dev/sdb1 2048 2097151 2095104 1023M 8e Linux LVM Command (m for help): w The partition table has been altered. Calling ioctl() to re-read partition table. Syncing disks. |
Next we will configure LVM to use /dev/sdb1 as a “Physical Volume”
1 2 |
$ sudo pvcreate /dev/sdb1 Physical volume "/dev/sdb1" successfully created |
After that, we need to create a “Volume Group” in which the Physical Volume will reside. We will name this couchbase.
1 2 |
$ sudo vgcreate couchbase /dev/sdb1 Volume group "couchbase" successfully created |
Next we will create a 500Mb Logical Volume named cbdata, in the couchbase Volume Group.
1 2 |
$ sudo lvcreate -L 500M -n cbdata /dev/couchbase Logical volume "cbdata" created. |
Now we will use the cryptsetup utility to encrypt the cbdata Logical Volume.
1 2 3 4 5 6 7 8 9 10 |
$ sudo cryptsetup --verbose --verify-passphrase luksFormat /dev/couchbase/cbdata WARNING! ======== This will overwrite data on /dev/couchbase/cbdata irrevocably. Are you sure? (Type uppercase yes): YES Enter passphrase: Verify passphrase: Command successful. |
The next step is to unlock the encrypted cbdata Logical Volume and make this accessible as a device named cbdata-luks
1 2 |
$ sudo cryptsetup luksOpen /dev/couchbase/cbdata cbdata-luks Enter passphrase for /dev/couchbase/cbdata: |
Now we will write a filesystem on top of the cbdata-luks device.
1 2 3 4 5 6 7 8 9 10 11 |
$ sudo mkfs.ext4 /dev/mapper/cbdata-luks mke2fs 1.42.13 (17-May-2015) Creating filesystem with 509952 1k blocks and 127512 inodes Filesystem UUID: a26d318b-afdd-45ca-857a-063899183ffd Superblock backups stored on blocks: 8193, 24577, 40961, 57345, 73729, 204801, 221185, 401409 Allocating group tables: done Writing inode tables: done Creating journal (8192 blocks): done Writing superblocks and filesystem accounting information: done |
Now we will create a directory at /couchbase-data to mount the filesystem, which will be used for the Couchbase Data Directory. And mount it.
1 2 |
$ sudo mkdir /couchbase-data $ sudo mount /dev/mapper/cbdata-luks /couchbase-data |
Now we have a LUKS encrypted storage device mounted at /couchbase-data which can be used as the target for the Couchbase Server Data Directory.
You can verify this with the mount and cryptsetup command.
1 2 3 |
$ mount … /dev/mapper/cbdata-luks on /couchbase-data type ext4 (rw,relatime,data=ordered) |
1 2 3 4 5 6 7 8 9 |
$ sudo cryptsetup status /dev/mapper/cbdata-luks /dev/mapper/cbdata-luks is active and is in use. type: LUKS1 cipher: aes-xts-plain64 keysize: 256 bits device: /dev/mapper/couchbase-cbdata offset: 4096 sectors size: 1019904 sectors mode: read/write |
Give Couchbase Server 7.0 Beta a try today, and use some of our new security features.
Availability and Duration of Beta
Documentation
Additional Blogs
Scopes and Collections for Modern Multi-Tenant Applications: Couchbase 7.0
Couchbase Transactions with N1QL
Get the Beta of Community Edition and Enterprise Edition
Couchbase 7 Beta is available for both Enterprise and Community Editions. Everyone can download the software from https://www.couchbase.com/downloads
Customer support is available via your regular support channels, while Community support is available through the Couchbase forums at https://forums.couchbase.com/