--- title: "v4.24.20" diataxis: how-to applies_to: product: "nirmata-control-hub" audience: ["platform-engineer"] last_updated: 2026-10-07 url: https://docs.nirmata.io/docs/release-notes/control-hub/v4.24.20/ --- ## Introduction These release notes cover the Nirmata Control Hub (NCH) and Nirmata DevSecOps Platform (NDP) Private Edition v4.24.20. This release introduces Windows worker node support, AWS role-based authentication with cross-account EKS, and a certificate expiry alarm, along with bug fixes, security fixes and instructions for upgrading from an earlier 4.24.x release. ## Images ### Images Common to NDP and NCH ```text ghcr.io/nirmata/haproxy:4.24.20 ghcr.io/nirmata/activity:4.24.20 ghcr.io/nirmata/client-gateway:4.24.20 ghcr.io/nirmata/policies:4.24.20 ghcr.io/nirmata/security:4.24.20 ghcr.io/nirmata/cluster:4.24.20 ghcr.io/nirmata/users:4.24.20 ghcr.io/nirmata/webclient:4.24.20 ghcr.io/nirmata/llm-apps:v4.24.20 ghcr.io/nirmata/nirmata-tunnel-server:4.24.20 ghcr.io/nirmata/kafka:v4-4.0.0 ghcr.io/nirmata/mongodb:4.24.4 ghcr.io/nirmata/mongo-k8s-sidecar:4.24.4 ``` ### NCH Specific Images ```text ghcr.io/nirmata/gateway-service:4.24.20 ``` ### NDP Specific Images ```text ghcr.io/nirmata/catalog:4.24.20 ghcr.io/nirmata/environments:4.24.20 ghcr.io/nirmata/config:4.24.20 ghcr.io/nirmata/orchestrator:4.24.20 ghcr.io/nirmata/host-gateway:4.24.20 ghcr.io/nirmata/static-files:4.24.20 ``` ### Remote Cluster Images ```text ghcr.io/nirmata/nirmata-kyverno-operator:v0.4.13 ghcr.io/nirmata/kubectl:1.35.0 ghcr.io/nirmata/nirmata-kube-controller:v3.10.25 ghcr.io/nirmata/otel-collector:nirmata-0.133.0 ``` ### NDP Cluster Images (Nirmata-Managed Clusters) These images are required to create or upgrade Nirmata-managed clusters. Mirror them when you use a private registry. ```text ghcr.io/nirmata/nirmata-kube-installer: ghcr.io/nirmata/nirmata-cni-installer:1.10.2 ghcr.io/nirmata/kubelet: ghcr.io/nirmata/opentelemetry-collector:0.92.0 ghcr.io/nirmata/kube-rbac-proxy:v0.13.1 ``` ### Windows Worker Node Images (NDP) ```text docker.io/calico/cni-windows:v3.27.0 docker.io/calico/node-windows:v3.27.0 docker.io/sigwindowstools/kube-proxy:v.0-calico-hostprocess ``` > **Note:** The `llm-apps` image tag uses a `v` prefix (`v4.24.20`). The `policy-studio` image is no longer part of the release. ## New Features ### Windows Worker Node Support (NDP only) Nirmata-managed clusters can now include Windows Server 2022 worker nodes alongside Linux nodes. - A new cluster type option, **Support Windows Worker Nodes?**, is available for the "Other" cloud provider with Kubernetes 1.22 or later. When it is enabled, the cluster uses VXLAN-mode Calico and the Windows Calico and kube-proxy DaemonSets are deployed. Windows components are deployed only for cluster types with this option enabled. - Windows hosts are enrolled from the Host Group **Windows** tab with a one-line PowerShell command (`Prepare-WindowsWorkerNode.ps1`). It installs containerd, the kubelet as a Windows service, firewall rules and the Nirmata host agent. Kubelet settings are applied automatically once Nirmata issues the node certificates. - Air-gapped Windows enrollment: the Host Group wizard accepts private registry details, and the enrollment command supports a `-PrivateRegistry` parameter. - Windows hosts are labelled `kubernetes.io/os=windows` automatically. - On Windows-enabled clusters, catalog add-ons (including Kyverno), the Nirmata controller and other Linux-only workloads are pinned to Linux nodes with a `kubernetes.io/os: linux` node selector. - Cleanup scripts for Windows nodes (`cleanup-cluster-windows.ps1` and `cleanup-cluster-agent-windows.ps1`) are provided alongside the prepare script. ### AWS Role-Based Authentication and Cross-Account EKS (NDP only) - Nirmata can authenticate to AWS with its own platform identity (EKS Pod Identity or IRSA) instead of long-lived access keys. Existing access-key credentials continue to work. - Hub-and-spoke cross-account EKS: an EKS cluster type can specify a **Target Account Role ARN**. Nirmata assumes the cloud credential's hub role and then the spoke role, and uses the spoke account for all EKS lookups (VPCs, subnets, IAM roles, key pairs, launch templates and KMS keys). Assumable spoke roles are listed automatically from the hub role's permissions. - The AWS Account ID in the Cloud Credentials form is now configurable and editable. - EKS: additional node group AMI types are supported, and clusters are created with the STANDARD support type. ### Cluster Certificate Expiry Alarm (NDP only) A new **Certificate Expiry** cluster alarm tracks the expiry of control plane, etcd and kubelet certificates, so that certificates can be rotated before they lapse. ### Private Registry for Auto-Created Cluster Types (NDP only) When a custom image registry is configured, automatically created cluster types now use it for all Kubernetes component and add-on images. ### Policy Reporting Improvements - Policy and compliance counts in email notifications and Jira tickets now link to pre-filtered reports. - CEL-based Kyverno policy kinds (for example `ValidatingPolicy`) are shown in the UI and deployed through the `policies.kyverno.io` API. - The Kyverno Helm install command in cluster onboarding includes the Enterprise Kyverno license flags required from N4K 1.18 (NCH). ## Bugs Fixed ### Clusters (NDP) - New clusters no longer wait about 10 minutes and fail the "Deploying Default Policies" step when the default policy group was never initialized. Such policy groups are now repaired automatically. - Policy sets created from YAML stayed pending on NCH-only installations. - The Nirmata controller version offered as "new version available" did not match the upgrade YAML, and fresh controller pods could crash-loop. - EKS node group creation failures are now reported as failures instead of success. - Cluster stability fixes for cluster watch authentication, multi-document YAML handling, empty node addresses and `policies.kyverno.io` readiness. - Fixed cluster connectivity issues on Kubernetes 1.32 and later. ### User Interface - Creating a cross-account EKS cluster did nothing when the spoke account had no SSH key pairs. - Cluster onboarding shows live policy set deployment progress, waits up to 30 minutes, surfaces sync errors and no longer gets stuck on "Creating policy sets" (NCH). - "Add Cluster" for a policy set lists only ready clusters, and the add-clusters panel no longer spins after deploying policy set changes. - The Policy Set "Return to manage policies" link opened a missing page (NCH). - Schema request timeouts no longer log users out, namespace resources reload when the cluster or namespace changes, and valid HTTPS and SCP Git URLs are accepted. - Alarm counts showed zero in NCH-only deployments (NCH). - Gauge alarm filter operators did not work. - Namespaces are sorted alphabetically in drop-down lists. - The Policy Hub application switcher and the Policy Studio entry are removed from the left navigation menu. ### Users and Notifications - Alarm and report notifications always used Mailgun even when SMTP was configured. - Uploading a SAML federation XML file failed. - User, tenant and team lookups are faster. ### Policies - Policy sets deleted directly on a cluster are redeployed, and policy sets are rolled out on cluster onboarding and label changes. - Compliance control drill-down showed 0 findings for controls not backed by kube-bench. - Policy report tables could be empty. - Report storage stability, retention and performance improvements. ## Security Fixes - All service images are rebuilt on updated base images (Wolfi, Tomcat, JRE 21.0.12) with dependency CVEs remediated, including Apache Shiro, Netty, Tomcat, logback, Jackson, Spring, Quarkus (CVE-2026-50559) and Go toolchain updates. - Secrets are no longer written to the environments service logs. - The login page's Handlebars library is upgraded to 4.7.8 (Qualys AVIT0088134, rated Very High). ## Installation NDP and NCH can be deployed using the Helm charts provided in the following repository. Follow the instructions in the README page for more details. ### To clone the repository: ```bash git clone https://github.com/nirmata/nch-charts.git cd nch-charts git checkout release/4.24 make help ``` ## Upgrade from Release 4.24.x To upgrade a 4.24.x system to 4.24.20, render the charts provided in [https://github.com/nirmata/nch-charts](https://github.com/nirmata/nch-charts). ### Step 1: Clone the Helm chart repository ```bash git clone https://github.com/nirmata/nch-charts.git cd nch-charts git checkout release/4.24 make help ``` ### Step 2: Edit the value file Edit `./config/values/environments/prod.yaml` and set the image version to `4.24.20` (`global.common.version`). The `llm-apps` image uses the tag `v4.24.20`. ### Step 3: Render the Kubernetes manifests #### NDP setup ```bash make render-all ENV=prod NDP=true OUT= ``` #### NCH setup ```bash make render-all ENV=prod OUT= ``` ### Step 4: Apply the generated manifests Apply the generated manifests to your setup. Deploy the `config` service before the `security` and `cluster` services. ### Upgrade Notes - The `users` and `policies` services create new MongoDB indexes on first start. On large tenants the first start can take longer. No manual step is required. - Cluster types created before 4.24.20 have Windows worker support disabled. Edit the cluster type to enable it before adding Windows workers; otherwise Windows hosts are skipped. - Default policy groups that failed to initialize are repaired automatically within about 15 minutes, and their policies are then rolled out to attached clusters. - Upgrade the Nirmata controller on managed clusters to v3.10.25 with **Upgrade Controller**. - Windows hosts enrolled with earlier scripts should be re-enrolled with the 4.24.20 `Prepare-WindowsWorkerNode.ps1`. ## Manifest Changes This section highlights the manifest changes in 4.24.20. - **Removed:** the `policy-studio` service. Delete its objects when upgrading with rendered manifests (`helm upgrade` removes them automatically): ```bash kubectl -n delete deployment/policy-studio service/policy-studio \ pdb/policy-studio-pdb serviceaccount/policy-studio \ configmap/policy-studio-config secret/policy-studio-ai --ignore-not-found ``` The HAProxy `/policy-studio` route is also removed. - MongoDB and mongo-k8s-sidecar chart defaults move to `4.24.4`. - **Optional, AWS role-based authentication (NDP):** set `NIRMATA_AWS_PLATFORM_AUTH_ENABLED=true` on the `cluster` and `cluster-processor` Deployments and associate an IAM role with their service accounts through EKS Pod Identity or IRSA (see below). Without it, access-key behaviour is unchanged. - **Optional, AWS account ID:** an administrator can set it through the config API (`PUT /config/api/awsPlatformConfig`). - Custom image registry settings (`nirmata.imageRegistry.*`) now apply to all images in auto-created cluster types. - New data model fields are created automatically. No manual migration is required. ## AWS Role-Based Authentication Configuration (NDP) ### Platform Identity for the Cluster Service Create an IAM role for Nirmata and associate it with the `cluster` and `cluster-processor` service accounts: ```bash aws eks create-pod-identity-association \ --cluster-name --namespace \ --service-account cluster-service \ --role-arn arn:aws:iam:::role/ # repeat for --service-account cluster-processor-service ``` For non-EKS clusters, use IRSA as described for `llm-apps` in the [v4.24.0 release notes](../v4.24/) (`AWS_ROLE_ARN` and `AWS_WEB_IDENTITY_TOKEN_FILE` environment variables). ### Cross-Account EKS (Hub and Spoke) - **Hub:** an AWS cloud credential with a role ARN and external ID. The hub role needs an IAM policy that allows `sts:AssumeRole` and `sts:TagSession` on each spoke role ARN. - **Spoke:** in each target account, a role whose trust policy trusts the hub role (with the external ID). - In the EKS cluster type, select the hub credential and the Target Account Role ARN. The EKS cluster role must come from the spoke account. ## Windows Worker Node Configuration (NDP) - Create a cluster type with the "Other" cloud provider, Kubernetes 1.22 or later, and **Support Windows Worker Nodes?** enabled. VXLAN networking is required. - On each Windows Server 2022 host, run the PowerShell command from the Host Group **Windows** tab as Administrator. For air-gapped environments, fill in the private registry fields so that the command includes `-PrivateRegistry`. - To reuse a Windows host for a new cluster, run `cleanup-cluster-windows.ps1`. To remove the host completely, run `cleanup-cluster-agent-windows.ps1`.