Kubernetes has undoubtedly become the de facto container orchestration platform. In fact, in the latest CNCF survey, 78% of respondents said they were using Kubernetes in production. With the rise in adoption of Kubernetes in production, securing application data has become ever more critical. The CNCF community has established a defense-in-depth model with the 4Cs of cloud native security: Cloud/Co-Lo/Corporate Data Center, Cluster, Container and Code. In this blog, we will focus on the security aspects of the Cloud/Co-Lo/Corporate Data Center layer which maps to the infrastructure.

Kubernetes provides few built-in application data security measures, leaving it to the underlying infrastructure or platform to provide holistic security for application data. Even though application data security is table stakes, it is typically done at the cost of reducing application performance and increasing infrastructure footprint.

Encryption is one of the key means to keep data secure. Unencrypted application data is not acceptable for production deployments, especially in industries such as finance and healthcare. Encryption needs to be applied to both data at rest and data in transit. Data in transit encryption can be provided through multiple ways such as TLS, HTTPS, SSL, etc. Diamanti platform facilitates the encryption of data in transit using these capabilities. With Diamanti Spektra 2.4, we have added support for data at rest encryption via volume encryption and self-encrypting drives (SEDs).

Volume Encryption on the Diamanti platform

Application data resides on the volume before it is written to physical drives. Volume encryption plays a key role in securing application data. Diamanti Spektra follows the LUKS specification for enabling volume encryption and the data is encrypted using the extremely secure AES-256 standard i.e.using a 256-bit key.

Key Management for Volume Encryption

Keys are an important component of encryption and should be stored securely. Two types of keys are used in this process:

• Data Encryption Key (DEK): This key is unique to a volume and is used to encrypt the data on the volume
• Key Encryption Key (KEK): This key is unique to the cluster and is used to encrypt the DEKs

DEKs are stored as a cipher on the particular volume as shown in Figure 2 below. The KEK is stored in etcd using a Kubernetes secret. This process ensures that both the keys are securely stored.

Encrypting a volume also encrypts its snapshots and mirrors. As nodes are moved from one cluster to another, the corresponding volumes also migrate. A temporary transit key is used for the migration of secure volumes. This transit key is used instead of the KEK to encrypt the DEK so that the cluster administrator need not exchange its KEK with others.

Enabling the secure volumes feature is as simple as clicking a mouse button. Figure 3 shows the Diamanti Spektra management console through which secure volumes can be enabled and the cluster administrator can manage keys. The KEK can either be automatically generated or supplied by the cluster administrator.

Self-Encrypting Drives (SED)

SEDs are a type of physical drives that, when configured on a platform, continuously encrypt data without user inputs. SEDs offer significant benefits as data on the drive is encrypted all the time and the data on the drive becomes inaccessible in case of drive or node theft.

The Diamanti platform supports SEDs which are OPAL 2.0 compliant. The data is encrypted via the AES-256 standard using a cluster-wide unique master encryption key (MEK). Enabling SEDs on the Diamanti platform has zero impact on the application performance. Figure 4 shows how data is encrypted using MEK.

In the case of drive migration, a temporary transit key is used to encrypt the data on one cluster and decrypt it on the other. This process enables the cluster administrator to keep the cluster-wide MEK as a unique key without exposing it to other clusters. Just like the Volume Encryption KEK, the MEK is stored as a Kubernetes secret. If present, SEDs are enabled on the Diamanti platform automatically. The user can manage keys via the Diamanti Spektra console as shown in Figure 5. The MEK can either be automatically generated or supplied by the cluster administrator.

Volume Encryption or SED?

Volume encryption and SED are not dependent on each other i.e. they can be enabled or disabled independently. There are some use cases that affect the choices. For example, if a volume is mirrored on a node that does not have SEDs, then volume encryption is the way to go. On the other hand, for regulatory purposes, financial, healthcare and government organizations, may require SEDs. The table below shows a comparison between the two options.

Here is a demo on how to secure your application data using Volume Encryption and SEDs on the Diamanti platform.

Secure Your Application Data With Diamanti

Data security is a fundamental requirement for enterprise applications and a key requirement for CSOs and CISOs. Volume encryption and Self-Encrypting Drives provide excellent ways to secure application data. With the Diamanti platform, these security measures are in-built and are implemented without any significant performance penalties or without an increase in infrastructure footprint. With Diamanti Spektra 2.4, security is not just as a feature, but organically integrated into the platform ensuring that the application data is always secure.

To learn more about securing cloud native workloads, attend the Security Considerations for Containerized Applications Webinar on May 7th and explore how Diamanti is the platform of choice to run modern applications.