End-to-End Encryption with vVols Part I: Introduction

No that’s not a typo–VVols are now capitalized as vVols. So, FYI.

Problem solved!! And we are off! https://t.co/3VeYzy2CHo

— Lee Caswell (@leecaswell) August 5, 2019

Anywho…as you may or may not be aware, we just released our 5.3.0 version of the FlashArray Purity Operating Environment, with quite a few things in it. One of the features is part of a larger solution that I think is a really good example of the power of VMware vSphere Virtual Volumes (vVols). One of the main arguments I have been making for VVols is that they allow you to use features on your array as they were intended (snapshots is a great example there) but also allows us (the storage vendor) to do things that simply weren’t possible, or were rather difficult to do with VMFS without compromise.

This particular feature I am referring to is what we are calling EncryptReduce. Previously called (in its beta form) End-to-End Encryption, this is a solution we partnered with Thales with its Vormetric Transparent Encryption product. We initially announced it here.

In short though, the fundamental problem we are solving is that encryption and data reduction are not very friendly–specifically when applied in that order. More and more these days, we are seeing customers want to encrypt data sets inside of their VM or physical servers–for a variety of reasons: legal, policy, compliance, etc. On the FlashArray we encrypt everything at REST, which is fine for most customers, but they want to take it that additional step, encrypting it from the host to the array, over the wire. The main issue here is that one of the main architectural features of the FlashArray (and most all-flash arrays in general) is data reduction. What is data reduction? Well a combination of compression and deduplication. What is that really? Well identifying patterns and removing them. Both compression and dedupe at a basic level rely on that concept.

Encryption, on the other hand, relies on the exact opposite. Removing identifiable patterns. So basically if you encrypt first, you cannot do any data reduction. This is why we run data reduction first, then encrypt. So if you encrypt your data, your data reduction will be 1:1. If it is anything appreciably different–it means your encryption is crappy.

So a dilemma. Encryption prevents you from being able to take advantage of data reduction. Is that a trade you must take? We didn’t think so.

So here comes EncryptReduce! So my argument is that I would like it to be called enCryptKeeper, but I think it violates trademarks or something.

Okey dokes.

So what are we doing here?

Essentially, this is a four part coordination.

There is a Key Management Server from Thales: Vormetric Data Security Manager (DSM) which the FlashArray and host communicate via the Key Management Interoperability Protocol (KMIP). This enables both the FlashArray and the host with the to-be-encrypted volumes to get the appropriate keys. When the FlashArray volume is presented to the host, the user can, what Thales refers to as, “guard” the volume. The VTE agent then literally writes an identifier down to the volume during the guarding process. This enables the FlashArray to identify the volume is indeed being encrypted above and also what volume to ask the DSM for the key via its secure tunnel. The VTE agent then makes sure any data written to that volume is encrypted. It is encrypted down the stack through the network into the FlashArray. We then de-encrypt the volume after acknowledging the write, then run our data reduction and then write it down to the flash. If we get a read request from the host, we re-encrypt and surface the data back up.

Today, this is supported on Linux only (no Windows at this time, but this is being worked on). RHEL, CentOS and Ubuntu. But certainly check out support site for official and up-to-date information. For the most part, I believe, this OS type restriction is based upon what Thales supports via its agents.

What type of volumes?

Well on the FlashArray, a volume is a volume is a volume. So the question is really more about how that volume is being used. For a physical server, there is an option: a block volume with whatever FS is put on it.

For VMware however, there are quite a few options. VMFS. RDMs. vVols. This does not work for VMFS–as we do not know the boundaries of the virtual disks on it, so even if we did have the agent in the host write the key down, we don’t know what to use the key for–unless all VMs used the same key, but that isn’t a good idea for a variety of reasons. Furthermore, what if one of those VMs is moved to a different datastore? This is a fundamental issue with VMFS–the array and its features are focused on the datastore. The datastore is the first class citizen. In VVols–it is the virtual disk that is first class.

So consequently, we support this feature in VMware environments only in the case of RDMs and vVols.

Okay so now you get the idea. This is part one of this series. I will walk through the setup of this environment in the subsequent parts. Please note that this is not a definitive guide to Vormetric Transparent Encryption–this is a basic walkthrough to use this feature from scratch. It will be in four parts:

• Deploying Thales’s Vormetric Transparent Encryption
• Configuring the FlashArray
• Configuring the host
• Doing VMware stuff after the fact

The process is pretty much the same for vVols or RDMs, or volumes for physical servers, with mostly just a difference as to the provisioning of said volume.