Couchbase now supports LUKS disk encryption to secure your data at rest. How secure is LUKS?
Couchbase 7.0 puts a big focus on security, debuting support for both role-based access control (RBAC) for Scopes and Collections, and encryption of at-rest data via Linux Unified Key Setup (LUKS).
Disk encryption is a vital part of any organization’s data security strategy and compliance with PCI DSS, FIPS, FISMA, GDPR and other regulatory standards.
So, is LUKS encryption secure? In this post we’ll start with an overview of security options for the three stages of documents in a Couchbase Server cluster – data in process, data in transit and data at rest (see the table below) – then delve into the specifics of data-at-rest security via LUKS on-disk encryption.
| Stage | Description | Use Case | Encryption Options in Couchbase |
| Data in Process | Active data, in-system memory | Documents that are in use | Field-level encryption at the application layer |
| Data in Transit | Data that is moving between systems | Replication, cross data center replication (XDCR) | TLS encryption, X.509 certificates |
| Data at Rest | Data that is not in active use | Buckets on the disk of an offline machine | Various options, including LUKS and support for third-party solutions such as Thales Vormetric |
Why Use Data-at-Rest Encryption?
Data-at-rest encryption protects locked or offline storage systems and prevents the data from being read without the appropriate authority and access. Data encrypted at rest does not remain protected while a device is online, unlocked and operational. For that, you must use one of the other encryption methods mentioned in the table above.
The following are common scenarios for encryption of data at rest:
- To protect confidential or personally identifiable information against any possible data breach
- By default in devices such as smartphones (often called full-disk encryption)
- In environments such as the cloud, where multiple users access the same underlying hardware
LUKS Disk Encryption
LUKS is a fully open source tool that is the de facto standard for disk encryption in Linux environments.
It is included in all Couchbase-certified Linux operating systems and supported by the respective OS vendors. LUKS sits in the kernel layer and encrypts storage at the disk-block level, allowing users to transparently deploy any file system on top of this block-level encryption. LUKS can encrypt storage partitions, which can be presented from a single drive, multi-disk RAID arrays, Logical Volume Manager (LVM) and even file-backed partitions.
What Is LUKS Encryption Good for…
LUKS is flexible and offers a range of cipher suites.
By default in a Red Hat 8 Linux environment, LUKS uses a highly secure 512-bit AES (Advanced Encryption Standard) key. Encrypted LUKS volumes contain multiple key slots, allowing users to add backup keys or passphrases, plus use features such as key revocation and protection for bad passphrases using Argon2.
…and What Is It Not Good for?
LUKS is not a good option for Couchbase instances deployed on non-Linux platforms, such as MacOS and Windows. It is also not well-suited for customers who do not have an active operating system–vendor support contract.
Standard OS-provided encryption technologies, such as Microsoft Encrypted File System (EFS) or Couchbase’s third-party encryption-at-rest partners are a better option if your organization does not use Linux or does not have an OS-vendor support contract.
Using LUKS Security to Encrypt Your Couchbase Data at Rest
You have several ways to implement LUKS in a Linux environment – most commonly using dm-crypt(part of the kernel-level device mapper infrastructure) and the cryptsetup command-line utility to set up dm-crypt targets.
In the code sample that follows, I’ll show you an example of commands I’ve used on my Ubuntu 16 Couchbase Server cluster to set up a disk with LVM. Then I’ll show you how to deploy an LUKS encrypted logical volume and mount it as the data directory for a Couchbase Server node. This ensures that if your Couchbase Server is ever breached, the confidential data in your Couchbase Buckets will not be accessible to unauthorized users.
The steps provided here before the General Availability (GA) release of Couchbase Server 7.0 and may change at release time or with future upgrades. Always consult the Couchbase documentation on security for the most up-to-date product information.
Use the following steps on a Couchbase Server node before adding it to a cluster and loading data into the Buckets. Note: These steps will erase anything currently residing on the target disk, so use caution and ensure that you are writing to the correct device.
1. Install the lvm and cryptsetup utility.
1 | sudo apt-get install lvm2 cryptsetup |
2. 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. |
3. Configure LVM to use /dev/sdb1 as a physical volume.
1 2 | $ sudo pvcreate /dev/sdb1 Physical volume "/dev/sdb1" successfully created |
4. 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 |
5. 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. |
6. 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. |
7. 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: |
8. 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 |
9. Create a directory at /couchbase-data to mount the filesystem, which will be used for the Couchbase data directory, then mount the filesystem.
1 2 | $ sudo mkdir /couchbase-data $ sudo mount /dev/mapper/cbdata-luks /couchbase-data |
10. Now we have a LUKS encrypted storage device mounted at /couchbase-data, which we use as the target for the Couchbase Server data directory. Verify this with the mount and cryptsetup commands like so:
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 |
Learn More about Couchbase 7.0
Ready to delve deeper into Couchbase 7.0 and all its features? Check out these resources:
Documentation
What’s new in version 7.0
Couchbase 7.0 release notes
Related blog posts
The N1QL Query Language Now Supports Distributed ACID Transactions
Downloads and Support
Enterprise Edition customer support is available via your regular support channels. Community support is available through the Couchbase Forums
Test the security of Couchbase for yourself<br/ >Give Couchbase 7 a test drive
