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.

Encryption Options for 3 Document Stages
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.

2. Configure the drive (/dev/sdb) and create a new primary partition to use LVM.

3. Configure LVM to use /dev/sdb1 as a physical volume.

4. Create a volume group in which the physical volume will reside. We will name this couchbase.

5. Create a 500MB logical volume named cbdata in the couchbase volume group.

6. Use the cryptsetup utility to encrypt the cbdata logical volume.

7. Unlock the encrypted cbdata logical volume and make this accessible as a device named cbdata-luks.

8. Write a filesystem on top of the cbdata-luks device.

9. Create a directory at /couchbase-data to mount the filesystem, which will be used for the Couchbase data directory, then mount the filesystem.

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:

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

How Scopes & Collections Simplify Multi-Tenant App Deployments on Couchbase

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

 

Author

Posted by Ian McCloy, Director Product Management

Ian McCloy is the Director of the Platform and Security Product Management Group for Couchbase and lives in the United Kingdom. His dedicated team is responsible for the Reliability, Availability, Serviceability and Security architecture of Couchbase Server and the SaaS Database, Capella. This team also own cloud-native platforms like the Couchbase Kubernetes Autonomous Operator. Ian has a vast range of experience as a Software Engineer, Technical Support Engineer, Quality Assurance Engineer and Systems Administrator. Ian has led global technical teams for the majority of his 20 year professional career and holds several patents in the areas of information security, virtualisation and hardware design. https://www.linkedin.com/in/ianmccloy/

Leave a reply