Patch Note for CTE for Kubernetes Operator

| CTE for Kubernetes | Date | Version | |----------------------|------| |1.5.9 | 2025-04-14| v1 |

New and Enhanced Features

CTE for Kubernetes Operator Deployment requirement

There has been a change in how the Kubernetes Operator Controller Manager downloads images. The kube-rbac-proxy used by the operator-controller-manager pod now sources its image from registry.redhat.io instead of the previously used gcr.io. Unlike gcr.io, which is a public registry and does not require authentication, registry.redhat.io requires authentication to pull images.

Even if you do not initiate an update to the CTE for Kubernetes Operator version, this change impacts all deployments because the operator is designed to automatically update. As a result, ensuring the creation of the rh-kube-proxy-secret is essential for the continued smooth operation of the CTE for Kubernetes Operator across all CTE for Kubernetes versions.

• See Creating the Required Kubernetes Secret for more information.

Implementation of CTE for Kubernetes deployment customization with Kubernetes Operator

When deploying CTE for Kubernetes using Helm, you can customize the deployment by changing parameter values in the values.yaml file, or by editing the manifest files, cte-csi-controller.yaml/cte-csi-nodeserver.yaml, directly. However, when deploying using operator, you can only modify the parameters which are available in the crd.yaml file. If you need to modify any other parameter, then a new build of operator that supports that parameter is required.

The change in this patch allows a K8s cluster administrator to customize the deployment of CTE for Kubernetes, using operator, by modifying the manifest files and uploading them as a configmap. The operator code has been updated to look for manifest files packaged as a configmap with the specific name, ctecustomconfig. To customize, set up a kubeclient and query the Kube Server API for a list of configmaps.

To customize the deployment, the Operator sets up a kubeclient and queries the Kube Server API for a list of configmaps in the namespace in which the Operator is installed. It then searches for a configmap with the name ctecustomconfig.

Once the operator finds this configmap, it extracts the manifests from it and uses them to deploy CTE for Kubernetes. If the configmap is not found, or the operator is not able to successfully extract the manifests, then it falls back to the manifests packaged at the time of build.

• See Using the CTE for Kubernetes Operator resource for more information.

Documentation Reorganization

Now that the default deployment method has changed from Helm to Kubernetes Operator, the documentation needed to be restructured and reorganized to support the Kubernetes Operator.

• All of the mandatory information for installing CTE for Kubernetes with Kubernetes Operator, preparing and deploying volumes, and performing data encryption, is now in the Getting Started with CTE for K8s

• The Volume Management information has been moved into the newly created Volume Management section. This section contains specialized, but optional, information for managing volumes.

• All of the Helm information has been moved to the Helm Deployment in the reference section.

Deploying CTE for Kubernetes from a local repo/Air gapped Environment

Security-intensive customers who do not want to access their applications through the internet, or download from the docker hub, can now deploy CTE for Kubernetes from their private network or private repository.

• See Deploying CTE for Kubernetes Storage Classes for more information.

Known Issues

No Known Issues for CTE for Kubernetes Operator