Release Note
Product Description
CTE 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 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.
CTE for Kubernetes Operator
The CTE for Kubernetes Operator is an OpenShift operator that Thales created for CTE for Kubernetes. The Kubernetes Operator can deploy, monitor, upgrade and delete CTE for Kubernetes. When the Operator is deployed, its controller deploys the CTE for Kubernetes driver in the OpenShift cluster. The manifests required to deploy the CTE-K8s driver are bundled with the operator.
Release Description
This release contains enhancements and new features for staging container resource settings, support for K8s service accounts and an update to the CTE Sign tool, as well as fixes for issues.
Container Image Digest
CTE for Kubernetes and Kubernetes Operator are deployed as container images. CTE devices are exposed as Persistent Storage volumes with customer application containers do not need to be modified.
- Verify that the Container Image Digest matches the version that you are installing.
Compatibility
Check the Compatibility Portal for compatibility between CTE for Kubernetes versions and Kubernetes versions.
New Features and Enhancements
CTE for Kubernetes 1.7.0.32
| Product | Version | Feature | Description |
|---|---|---|---|
| CTE for Kubernetes | 1.7.0.32 | Support for CTE Staging Container Resource Settings | This feature allows you to configure container resource settings for the CTE staging pod. This is useful if, for example, a default policy for resource settings is enabled for the container, but is not configured with CPU and memory resource limits, because this could cause the staging pod to terminate. |
| CTE for Kubernetes | 1.7.0.32 | Support for K8s service accounts to allow access to protected volumes | A service account is a type of Kubernetes account that provides a distinct identity, in a Kubernetes cluster, so that you can allow or restrict access based on this service account. Application Pods, system components, and entities inside and outside the cluster can use a specific Service Account's credentials to identify as that Service Account. This is needed because the UID inside a K8s pod is not persistent, and changes frequently in OpenShift deployments. Therefore, access control based on user IDs is not feasible for such workloads. |
| CTE for Kubernetes | 1.7.0.32 | CTE Sign Tool | Updated arguments for the tool. |
| Kubernetes Operator | 1.7.5 | Changes to the custom ConfigMap file | Before upgrading to Kubernetes Operator v1.7.5, you must regenerate the ctecustomconfig file before running the deploy script. |
CTE for Kubernetes 1.6.x
| Product | Version | Feature | Description |
|---|---|---|---|
| CTE for Kubernetes | 1.6.0.49 | Registering to Multiple CipherTrust Manager Servers for failover in an HA Cluster | For a cluster for CipherTrust Manager servers, you can now configure multiple IP addresses with cte-storageclass.yaml to allow for seamless failover to the next available CipherTrust Manager if a CipherTrust Manager server fails. See Registering to Multiple CipherTrust Manager Servers for failover in an HA Cluster for more information. |
| CTE for Kubernetes | 1.6.0.49 | Support for Expanding Persistent Volumes Claims | You can now resize an existing volume by editing the PersistentVolumeClaim (PVC) object. You no longer have to manually interact with the storage backend, or delete and recreate PV and PVC objects, to increase the size of a volume. Kubernetes will automatically expand the volume, using storage backend, and it will also expand the underlying file system in-use by the Pod, without requiring any downtime if the underlying storage provisioner can support it.See Volume Resizing and Expansion |
| CTE for Kubernetes | 1.6.0.49 | Document Restructure for CTE for Kubernetes and CTE for Kubernetes Operator | For CTE for Kubernetes and CTE for Kubernetes Operator for the v1.5 release, the two applications released together. However, in the future, they may release independently. Therefore, the patch notes and release notes section have been separated. On the initial landing pages, you will see a bullet list which contains two entries: CTE for Kubernetes and CTE for Kubernetes Operator. Select the one that navigates to the appropriate release note. |
| CTE for Kubernetes | 1.6.0.49 | Alternative mounting for /etc/kubernetes for kubeclient access |
CTE for Kubernetes no longer requires mounting the nodes host /etc/kubernetes. |
| Kubernetes Operator | 1.6.5 | Update the Driver log during Runtime | You can now update the CTE-K8s driver log level during runtime. Previously, log levels were set at container startup and were not changeable during runtime. The log level parameter is set at deployment time which means that the customer cannot increase loglevel without redeploying. Now you can use a config map with the loglevel parameter and automatically change the log levels when the config map is modified. * See Using user-defined Configuration Parameters with RedHat OpenShift for more information. |
| Kubernetes Operator | 1.6.5 | Document Restructure for CTE for Kubernetes and CTE for Kubernetes Operator | For CTE for Kubernetes and CTE for Kubernetes Operator for the v1.5 release, the two applications released together. However, in the future, they may release independently. Therefore, the patch notes and release notes section have been separated. On the initial landing pages, you will see a bullet list which contains two entries: CTE for Kubernetes and CTE for Kubernetes Operator. Select the one that navigates to the appropriate patch or release note. |
| Kubernetes Operator | 1.6.5 | Document Improvement | The Deploying CTE for Kubernetes in an Air-Gapped OpenShift Container Platform Cluster topic has been re-written for added clarity. * See Deploying CTE for Kubernetes in an Air-Gapped OpenShift Container Platform Cluster using CTE for Kubernetes Operator for more information. |
Issues
Comprehensive Table of Issues
Note
-
All issues affect CTE for Kubernetes from the Initial Reported version to the Resolved version.
-
If an issue does not contain a Resolved version, then it is not yet fixed. It is a Known Issue.
| Issue | Product | Description | Initial Reported version | Resolved version |
|---|---|---|---|---|
| AGT-39000 | CTE for Kubernetes | CTE PVCs failed to report to CipherTrust Manager all of the pods that were using the same volume on the same node This anomaly was due to how Kubernetes handled a single volume used across multiple pods in the same node. |
1.4.0.37 | 1.7.0.32 |
| AGT-61578 | CTE for Kubernetes | Getting permission denied while creating files in a pod CTE does not support the use case where Key rule is "clear_key" and the security rule is "apply_key". |
1.5.0.27 | 1.7.0.32 |
| AGT-61654 | CTE for Kubernetes | Azure passing node information to CipherTrust Manager Upgrading nodes in Azure created problems with CTE for Kubernetes due to licenses. When nodes in a cluster were running an older version of the Kubernetes stack, the upgrade process in Azure did not upgrade the node in place. Instead, Azure deployed a new node with the latest version of the Kubernetes stack. Once that node was in the "Ready" condition, an out-of-date node was evicted from the customer's Kubernetes cluster. This issue has been fixed. |
1.6.0.49 | 1.6.0.49 |
| AGT-61761 [CS1580017] | CTE for Kubernetes | CTE for Kubernetes pods throwing error MountDevice failed for volumeThe combination of Debian 12 Linux OS with Kubernetes CRI-O container runtime interface, is not supported in CTE for Kubernetes. |
1.3.0.33 | Won't fix. Combination not supported. |
| AGT-62766 | CTE for Kubernetes | Agentinfo was unable to provide Kubernetes information when run from nodes with the ARM architectureThis has been fixed. |
1.5.0.27 | 1.6.0.49 |
| AGT-62926 | CTE for Kubernetes | Removed mounting /etc/kubernetes as a requirement.Some customers did not want to have the CSI driver mount the /etc/kubernetes directory because it violated their company security policy. This directory was originally mounted by the container so that the CSI driver could access the Kubernetes API. |
1.5.0.27 | 1.6.0.49 |
| AGT-64707 | CTE for Kubernetes | CipherTrust Manager not releasing license when node deleted Previously, when a node was deleted, CTE for Kubernetes did not inform CipherTrust Manager so licenses were not freed. Now, it sends a list of available nodes to CipherTrust Manager so that CipherTrust Manager will clean up any stale clients and free up the licenses. |
1.3.0.33 | 1.6.0.49 |
| AGT-64989 | CTE for Kubernetes | Agent not using next available CipherTrust Manager in cluster when registration fails with the first CipherTrust Manager The CTE-K8s agent feature that permits multiple IP addresses when registering to a CipherTrust Manager cluster, with a silent registration file, works if the file only has IP or Host addresses, but fails if the list also specifies a port number. |
1.6.0.49 | |
| AGT-65459 | Kubernetes Operator | During installation default log for operator is set to 1 The default logLevel for CTE-K8s when deployed using Helm is 1. For deployment with CTE-K8s Operator, it was inadvertently set to 5. This causes Operator to generate a large amount of logs that is not normally required. To reduce unnecessary logging and to be consistent with the deployment using Helm, starting this release, the default logLevel is set to 1 for deployment with the CTE-K8s Operator. For customers who want to deploy CTE for Kubernetes Operator with the logging level set to 5, see Updating CTE-K8s Log level on a live CTE deployment. |
1.6.5 | 1.6.5 |
| AGT-67242 [CS2203852] | CTE for Kubernetes | Unable to get agent registration. Fixed the incompatibilities that occurred with specific versions of the Kubernetes CRI-O (Container Runtime Interface for OpenShift Container) in both Kubernetes and OpenShift. The newer versions intermittently reported error messages similar to: lstat /chroot/chroot-99c4393f-3a1b-4744-a068-de23f953eb68/rootfs/opt/vormetric/DataSecurityExpert/agent/secfs/.sec/conf/configuration: no such file or directory |
1.5.0.27 | 1.6.0.50 |
| AGT-68153 | CTE for Kubernetes | The cte_csi binary should reap all processes created by it.When a reap process runs in the background is stopped, in one of our containers, it enters a defunct state, as there is no one to wait for it to terminate. |
1.6.0.49 |