Modern environments, especially edge computing and 5G, are complex, highly distributed, highly multi-tenant. Such environments push enterprise data close to the edge and create numerous exposure points and attack surfaces that did not exist in legacy monolithic deployments. 

In the previous article, we outlined five security considerations for edge deployments. The key component that will be addressed in this post is data. Let’s walk through how Red Hat OpenShift and Zettaset XCrypt for OpenShift customers can take advantage of a platform for microservices deployments with the granular and high performance data protection and management capabilities that modern architectures require.

Security threats to sensitive data

As high speed mobile networks and edge solutions continue to proliferate, there is an emerging set of security challenges and concerns. Prime among them are:

  • A reduced level of physical security due to either remote location, or increased level of physical access, or operating in dangerous locations.

  • Intermittent communication between the endpoint devices and the enterprise edge may require edge solutions to have localized data storage.

  • An increased level of multi-tenancy and shared responsibility.

Retail locations or remote oil rig operations also offer reduced levels of data protection due to their increased level of exposure and reduced physical security. Furthermore, in telecommunications applications, as the network offers higher speeds and the enterprise data is processed at the edge by both providers and third parties, it is highly susceptible to attacks due to reduced level of protection offered by the far edge.

Red Hat OpenShift provides data protection at the edge

Red Hat OpenShift provides a platform for running different containerized workloads. Now that these workloads are moving to the edge, Red Hat OpenShift now can bring the security features afforded datacenter deployments to the edge. Because data is being captured at the edge, protecting that data becomes even more important than ever. Red Hat OpenShift provides a number of built-in security features: 

  • Red Hat Enterprise Linux CoreOS, a container-optimized OS, delivers controlled immutability, transactional updates, and uses SELinux in enforcing mode to provide container isolation.

  • Out of the box, Red Hat OpenShift provides fine-grained access control, auditing, logging and monitoring capabilities.

  • Data in motion and communication between platform components is encrypted by default. Red Hat OpenShift can be also booted in FIPS mode so that cryptographic tools use FIPS-compliant cryptographic modules.

  • Ingress and egress controls help with network security, as well as micro-segmentation for management of east-west traffic.

Red Hat OpenShift also keeps applications isolated from each other to protect from malicious code and viruses disrupting workloads and crossing access boundaries.  Data is key to many edge deployments, and it can't be overstated that data encryption is paramount. 

These platforms provide encryption such as LUKS disk encryption for persistent volumes for the data at rest. However, there are certain use cases that require elevated data protections. For that, Red Hat partners with Zettaset to help provide those additional capabilities.

Protecting data with Zettaset

Zettaset XCrypt for OpenShift provides high performance transparent data encryption services to containers and pods while establishing key granularity of a unique encryption key per persistent volume. 

This allows for granular protection: no two persistent volumes share the same encryption key. In addition, this level of key granularity helps ensure that, in the event of a compromised pod or container, a persistent volume can be decommissioned without compromising cluster availability and other persistent volumes.

 

Figure 1 illustration of the XCrypt Operator in action

Figure 1: Illustration of the XCrypt Operator in action

Application containers take advantage of encrypted persistent volumes by requesting XCrypt Encrypted Volume storage class when allocating persistent volumes. This storage class will invoke XCrypt services to automatically allocate storage of requested type and size and deploy encryption on top of that storage. 

The storage is then automatically attached to the requesting container and can be used as any regular container-attached storage. It does not require special provisioning and the requestor is completely abstracted away from having to provide secrets, keys, certificates or any other encryption-related information.

Key management capabilities are implicitly designed into a Zettaset XCrypt for OpenShift encryption. The key management functions are provided by the KMIP-compatible software key manager running in a Kubernetes pod and exposing a Kubernetes service.

The key management service implements standard KMIP protocol functions for key creation, key state management, and key retrieval.

Authentication to the key management services is based on the standard KMIP authentication mechanism, which uses client-side SSL certificates. These certificates are issued by the Certificate Authority service that runs as another Kubernetes Pod. This service is responsible for protecting communication between various components of Zettaset XCrypt for OpenShift encryption.

Zettaset XCrypt for OpenShift uses Zettaset Key Management and Certificate Authority services automatically and does not require user or administrator intervention. The services are deployed by Zettaset XCrypt Red Hat Certified Operator as standard Kubernetes Pods and services and are automatically configured during deployment.

 

Figure 2 how XCrypt works

Figure 2: How XCrypt works

Internally, XCrypt for OpenShift uses kernel crypto to encrypt data traveling through the stackable file system in the shared kernel space of the worker node. This architecture provides the following benefits:

Minimal performance overhead 

Using AES_NI helps keep the overhead for encryption and decryption is at a minimum. In internal performance tests performed by Zettaset, the overhead was reported to be between 3% and 7%. In addition, SSL-based communication with the key management service that runs in the user space is kept to a minimum, so the encryption services are not network bound and do not require frequent switching from kernel space to user space and back.

Complete application and workflow transparency

Because the crypto takes place in the kernel, it is transparent to higher level services and applications such as data services and other 5G network services. Additionally, the developer, admin, and user processes in deploying and managing applications and services do not need to change after XCrypt for OpenShift is deployed.

No change to application footprint or packaging

The unique architecture means that user applications, pods, and containers do not need any special or additional software to be able to create and access encrypted persistent volumes.

Automatic and transparent policy management

XCrypt for OpenShift takes care of mapping cryptographic keys to encrypted volumes and mapping encrypted volumes to partitions or devices they are provisioned over. Users are not required to keep track of any metadata related to data protection.

Automated storage provisioning with native storage support

XCrypt for OpenShift includes a storage management component that enables it to automatically assemble volumes of required size from one or more physical volumes attached to the worker node. Additionally, the storage management component offers direct integration and automated storage provisioning of Ceph storage from a pool that is accessible to the cluster.

Advanced Key Management integration

XCrypt for OpenShift includes software KMIP-compatible key manager and PKCS#11-compatible software security module. These two services work in tandem to protect data encryption keys, key encryption keys (wrapping keys), and master and hash keys. 

In addition, XCrypt for OpenShift can be integrated in existing KMIP-compatible and PKCS#11-compatible key management key management and HSM systems. For non-KMIP key management systems, such as AWS KMS, XCrypt for OpenShift Key Manager can serve as a KMIP-compatible “façade” or KMIP proxy in front of the AWS KMS.

Enterprise-grade certificate management 

XCrypt for OpenShift uses SSL certificates so that communications between its components and services are protected. Each worker node is issued a unique certificate issued by the internal Certificate Authority server. There is also an option to “root” the Certificate Authority (CA) certificate in a higher-level CA, such as corporate, operator, or provider CA.

While XCrypt for OpenShift includes a number of services, it has been tested on small footprint installations and is completely functional in environments as small as a single node Kubernetes cluster, where all services run on a single server or even a single VM.

Summary

Building on top of the Red Hat OpenShift platform, XCrypt for OpenShift provides data protection, management and monitoring of data and crypto-related activity with the ability to reduce compromise detection windows and respond to compromises quickly and in precise manner, without compromising the rest of the cluster.

Complex environments require a modern approach to data protection; legacy methods of protecting data that rely on infrastructure-level or storage-level data protection will not satisfy the rapid growth and multi-tenant nature of these environments. These environments require granular high performance data protection that maintains complete application transparency, but is granular enough to understand the nature of objects it is protecting.

With Red Hat OpenShift and Zettaset XCrypt for OpenShift, customers can take advantage of a platform for microservices deployments with the granular and high performance data protection and management capabilities that the modern architectures require.

Thanks to Maksim Yankovskiy, CTO and VP of Engineering of Zettaset, for his insights in writing this post.
Learn more about Red Hat’s edge vision here.


About the author

John Senegal is an ecosystem solution architect who works with strategic global partners to build joint and ecosystem solutions. His technology focus is around the AI/Ml and edge/ IoT partner ecosystems.

Read full bio