Your suggested change has been received. Thank you.

close

Suggest A Change

https://thales.na.market.dpondemand.io/docs/dpod/services/kmo….

Thales Logo

All

  • All
back

CTE for Kubernetes Administration

Introduction to CipherTrust Transparent Encryption for Kubernetes

search

Introduction to CipherTrust Transparent Encryption for Kubernetes

Kubernetes is an open-source container-orchestration system that aims to provide a "platform for automating deployment, scaling, and operations of container workloads".

CTE for Kubernetes is an implementation of the CipherTrust Transparent Encryption with native support for Kubernetes through the implementation of a CSI (Container Storage Interface) driver. Unlike traditional CTE, product installation and Guard Policy management is done through Kubernetes. This means that as the cluster scales up with more nodes, CTE for Kubernetes scales with it. CTE for Kubernetes is designed to protect Kubernetes Persistent Storage Claims that are backed by storage with filesystem semantics.

In order to support customers with diverse workloads, registration to CipherTrust Manager has been decentralized from the cluster nodes/ hosts operating system. Registration now happens through the use of Storage Classes which allows for a single cluster, and even a single node, to register different CTE for Kubernetes groups, each with a different set of policies and keys.

CTE Agent and CSI driver are deployed as container images. CTE devices are exposed as Persistent Storage volumes and Customer application containers do not need to be modified.

This document shows some examples on how a customer can protect their pod’s persistent storage data through the use of CTE for Kubernetes.

Prerequisites

The CTE for Kubernetes solution requires the following:

  • Kubernetes v1.22 or subsequent versions Kubernetes IO releases

  • Available Persistent Storage for protecting with CTE for Kubernetes

  • CipherTrust Manager v2.8 and subsequent versions

  • Kubernetes nodes with access to the Internet to fetch CTE for Kubernetes images from Docker Hub

  • Public Docker Hub credentials for pulling the images

  • Working Kubernetes Cluster that can communicate with the cluster using kubectl

Required Privileges

Administrators can use security context constraints (SCCs) to control permissions for pods with an OpenShift Cluster. These permissions include actions that a pod can perform and what resources it can access. You can use SCCs to define a set of conditions that a pod must run with to be accepted into the system. You can also use the Security Context Constraints to provide additional privileges to the Service Accounts that are used by the CTE for Kubernetes driver in an OpenShift Cluster. A subset of these permissions are specified in the Pod specification for use in Kubernetes where SCC is not available.

For a container to exploit the System Administrator permissions, the container must run as a privileged container.

System Administrator Permissions Value Definition Resources Used
allowedCapabilities SYS_ADMIN The CSI Controller component performs tasks like create, publish, unpublish, delete, snapshot, and restore volumes, on any node in the Kubernetes cluster. Without the SYS_ADMIN capability, the driver does not work and CTE functionality is lost.
allowPrivilegedContainer true For a container to have SYS_ADMIN capability, the container must run as a privileged container.
allowHostDirVolumePlugin



volumes		 true

  • emptyDir
  • hostPath
  • projected
 The CTE for Kubernetes driver mounts the directories from the host node into the containers. These two permissions allow for the CTE driver to mount these directories as volumes inside the container. Directory examples:
/etc/kubernetes/
/var/lib/kubelet/plugins_registry/
/var/lib/kubelet/pods

It also mounts one of the following directories, depending on which CRI is configured:
/run/crio/crio.sock
/run/cri-dockerd.sock
/run/containerd/containerd.sock
allowHostPID True The CTE for Kubernetes driver requires the process PID to track and authorize application processes accessing protected data.
runAsUser type: RunAsAny Controls which user ID containers can use. RunAsAny allows processes inside the container to run with any user ID, including root, in that container's context.
seLinuxContext type: RunAsAny Controls which SeLinux context the container can use. RunAsAny allows changes to the SELinux Context assigned to the namespace in which the container is running.
fsGroup type: RunAsAny Controls which fsGroup owns the volumes created by the container. RunAsAny allows users to own any files/directories created by the container.

Minimum System Requirements

Pod Type Memory (RAM) CPU
CTE CSI Controller 512Mb 1
CTE CSI Node Server 512Mb + 100Mb per Guard Policy 2
CTE CSI Staging pod 5Mb 0.1

Note

  • Encryption CPU requirements on the node server are highly dependent on the workload that is accessing the CTE for Kubernetes encrypted volume. Additional CPU resources may be required depending on the expected number of IOPS for the application
  • Applying hard memory limits on the CTE for Kubernetes node server pods can result in the pod being evicted. This will cause a service interruption to the CTE for Kubernetes volume. Hard memory limits are not recommended for the CTE node server.
  • Staging pods do not consume any CPU resources after starting and very minimal memory resources after starting.

Audience

This document is intended for personnel responsible for maintaining your organization's security infrastructure. This includes security officers, key manager administrators, and network administrators.

All products manufactured and distributed by Thales Group are designed to be installed, operated, and maintained by personnel who have the knowledge, training, and qualifications required to safely perform the tasks assigned to them. The information, processes, and procedures contained in this document are intended for use by trained and qualified personnel only.

Thales expects that the users of this product are proficient with security concepts and knowledgeable in all aspects of Kubernetes cluster administration and management.

Users must be able to:

  • Install the CTE for Kubernetes CSI driver

  • Create RBAC (role-based access control) rules

  • Add Persistent Storage Claims to a namespace within the Kubernetes cluster

Limitations

  • Killing CTE CSI pods can leave a pod with protected volumes in an unusable state. User should terminate all pods using a CTE protected volume before attempting to stop the CTE for Kubernetes service pods.

Support for Managed Clouds

CTE for Kubernetes can be deployed in the following Cloud environments:

  • Amazon Elastic Kubernetes Service (AWS)
  • Azure Kubernetes Service (Azure)
  • Google Kubernetes Engine (GKE)
  • Red Hat OpenShift

On this page