There is a growing movement to encrypt everything. I prefer encrypting specific data, not everything. However, modern CPU chipset features have sped up encryption so much that encrypting everything is a valid option. Encryption requires one to have access to the keys or the related encryption secrets. Those secrets need to be at the fingertips of your applications or management tools. Encryption secrets should be readily available to an application. How do we achieve this? The February 9, 2017 Virtualization and Cloud Security Podcast addresses this issue. In this podcast, Virtuozzo’s Chief Software Architect, Pavel Emelyanov, joins us to discuss container encryption.

First, we need to understand the requirements of container encryption. In the podcast, we discuss two forms of container encryption. The following figure shows both forms: container and virtualized. We are talking about volume encryption provided by Virtuozzo (in blue) and VMware (in orange). Container persistent storage encryption is the same regardless of the underlying host.
KMS For Encryption Secrets
The concept is that the container or virtualization host is doing the encrypting and decrypting of some persistent storage. We could also encrypt transient storage so that any artifacts left behind are no longer visible. Due to the large number of containers (or VMs) we are discussing, we need to add in a way to never forget a key. This is often referred to as a key management system (KMS), which is in red in the diagram. To do any encryption at scale, a KMS is a must. There is also a set of requirements to consider for any KMS.

Requirements: KMS for Encryption Secrets

The set of requirements for a KMS is not a very long list. However, it is an important list to scale up as needed.

  • Be FIPS 140-1 or 140-2 certified. This certification gives a minimum level of a cryptographic standard.
  • Be highly available/redundant so as to never lose a key. When a KMS is in use, it must be as available as DNS. A good KMS is very close to being a form of DNS that holds cryptographic material—not just encryption keys, but all other forms of secrets.
  • Speak to either a hardware security module (HSM) or make use of the Intel DRNG chipset features. KMSes running within a cloud need a good source of entropy if they are also creating keys. Intel DRNG will provide that entropy. If the entropy is not there, then make use of an HSM to create keys. Virtualized systems are notorious for not having enough entropy, which is why Intel built the DRNG chipset features.
  • Speak Key Management Interoperability Protocol (KMIP) v1.3 or later. KMIP provides a standard mechanism for communication from the encryptor to the KMS.

Using a KMS for Encryption Secrets

Regardless of the form of volume encryption taken, the encryptor (hypervisor or container host) talks to the KMS via KMIP to first create a key. The KMS either speaks to an HSM, or uses the Intel DRNG chipset features to generate a key. Once the key is retrieved, it is placed in a cache area within each host. This cache is usually within kernel memory. Then the encryption mechanisms are used to either encrypt or decrypt the volume.
This method has several items to consider:

  • Keys will hang out in each container host until removed. Often until rebooted.
  • Keys can be revoked in the KMS but may not be removed from the host until forced to do so (a primitive in KMIP will soon include this). At the moment, scripting is required, although this will change within a short period of time.
  • Keys removed from the KMS will no longer be queryable. This is the same as throwing away the key so that the data can no longer be decrypted. This could be useful for transient data.
  • Rekeying takes place within the container host, not the key manager. As such, if your KMS supports rekeying, it needs to be able to feed the rekey commands back into the container host. Rekeying from the KMS also would require a reverse lookup functionality that does not exist today.
  • The attack point will either be the container host or the KMS. You need to harden both. Admin Escape is the major concern.

Once we start encrypting volumes at scale, we open ourselves to the ability to manage secrets for networks, applications, APIs, and many other needs. As our systems grow, so will our need to do encryption and manage secrets. Docker just announced Docker Secrets Management in its latest version of Docker Datacenter. HashiCorp has Vault for vaulting any form of secret. Thales (formerly Vormetric) has its Data Security Manager, which comes in hardware and software versions. HyTrust has its KeyControl product, which is designed to manage encryption secrets.
Update: Intel RND is really Intel DRNG which is NIST SP800-90A, B, and C, FIPS-140-2, and ANSI X9.82 compliant.

Closing Thoughts

No matter where you look, encryption is a big deal. Managing encryption keys is changing day by day. The basic functionality required to manage encryption keys and other secrets is pretty well defined. If  you are looking at encryption, specifically in the hybrid cloud, you need a KMS. If you are looking at using containers at scale, you need a KMS. No matter how you look at IT today, a KMS is a requirement. We present the requirements for a KMS, considerations, and use cases, as well as some existing KMS products. How are you integrating encryption and API security into your hybrid cloud today?
Have a listen to the podcast for more actionable advice.
Panel members from:
VirtuozzoVMwareTVP Strategy