#kubernetes

We are thrilled to announce the general availability of Red Hat OpenShift Service Mesh 3.2. This release includes the general availability of Istio’s ambient mode—a new way of deploying service mesh without sidecars that significantly lowers the resource costs of using service mesh. This provides a low overhead solution for zero trust networking with lightweight pod-to-pod mTLS encryption and authorization policies based on workload identities, with the ability to add more advanced features as required.Based on the Istio, Envoy, and Kiali projects, this release updates the version of Istio

We’ve been dedicated to advancing Red Hat Advanced Cluster Security for Kubernetes in line with the rapid evolution of Kubernetes security. With version 4.9, we’re introducing key integrations and updates designed to help streamline your workflows. To that end, we’ve improved our ability to integrate with other tools and services, enhanced visibility into operations, and begun the work of bringing virtual machines (VMs) into our scope of reporting and scanning. Red Hat Advanced Cluster Security Integration with ServiceNowA significant highlight of Red Hat Advanced Cluster Security 4.9 is

The age of quantum computing is on the horizon, and with its immense processing power comes a significant threat to the cryptographic foundations of our digital world. In this article, we'll explore the emerging support for post-quantum cryptography (PQC) in Red Hat OpenShift 4.20, focusing on how it enhances the core components of the Kubernetes control plane: the apiserver, kubelet, scheduler, and controller-manager. Missing is etcd, using an older version of Go.The quantum threatToday's widely used public-key cryptosystems, such as RSA and elliptic curve cryptography (ECC), form the foundat

SUMMARY We have identified and verified an SSRF vulnerability where webhook URLs are not validated, allowing repository administrators to create webhooks targeting internal services, private networks, and cloud metadata endpoints. AFFECTED COMPONENTS (VERIFIED) 1. Webhook Creation (pkg/ssh/cmd/webhooks.go:125) 2. Backend CreateWebhook (pkg/backend/webhooks.go:17) 3. Backend UpdateWebhook (pkg/backend/webhooks.go:122) 4. Webhook Delivery (pkg/webhook/webhook.go:97) IMPACT This vulnerability allows repository administrators to perform SSRF attacks, potentially enabling: a) Cloud Metadata Theft - Access AWS/Azure/GCP credentials via 169.254.169.254 b) Internal Network Access - Target localhost and private networks (10.x, 192.168.x, 172.16.x) c) Port Scanning - Enumerate internal services via response codes and timing d) Data Exfiltration - Full HTTP responses stored in webhook delivery logs e) Internal API Access - Call internal admin panels and Kubernetes endpoints PROOF OF CONCE...

### Summary _Short summary of the problem. Make the impact and severity as clear as possible. The permissions granted to the `virt-handler` service account, such as the ability to update VMI and patch nodes, could be abused to force a VMI migration to an attacker-controlled node. ### Details _Give all details on the vulnerability. Pointing to the incriminated source code is very helpful for the maintainer._ Following the [GitHub security advisory published on March 23 2023](https://github.com/kubevirt/kubevirt/security/advisories/GHSA-cp96-jpmq-xrr2), a `ValidatingAdmissionPolicy` was introduced to impose restrictions on which sections of node resources the `virt-handler` service account can modify. For instance, the `spec` section of nodes has been made immutable, and modifications to the `labels` section are now limited to `kubevirt.io`-prefixed labels only. This vulnerability could otherwise allow an attacker to mark all nodes as unschedulable, potentially forcing the migration o...

### Summary _Short summary of the problem. Make the impact and severity as clear as possible. A logic flaw in the `virt-controller` allows an attacker to disrupt the control over a running VMI by creating a pod with the same labels as the legitimate `virt-launcher` pod associated with the VMI. This can mislead the `virt-controller` into associating the fake pod with the VMI, resulting in incorrect status updates and potentially causing a DoS (Denial-of-Service). ### Details _Give all details on the vulnerability. Pointing to the incriminated source code is very helpful for the maintainer._ A vulnerability has been identified in the logic responsible for reconciling the state of VMI. Specifically, it is possible to associate a malicious attacker-controlled pod with an existing VMI running within the same namespace as the pod, thereby replacing the legitimate `virt-launcher` pod associated with the VMI. The `virt-launcher` pod is critical for enforcing the isolation mechanisms appli...

### Summary _Short summary of the problem. Make the impact and severity as clear as possible. Mounting a user-controlled PVC disk within a VM allows an attacker to read any file present in the `virt-launcher` pod. This is due to erroneous handling of symlinks defined within a PVC. ### Details _Give all details on the vulnerability. Pointing to the incriminated source code is very helpful for the maintainer._ A vulnerability was discovered that allows a VM to read arbitrary files from the `virt-launcher` pod's file system. This issue stems from improper symlink handling when mounting PVC disks into a VM. Specifically, if a malicious user has full or partial control over the contents of a PVC, they can create a symbolic link that points to a file within the `virt-launcher` pod's file system. Since `libvirt` can treat regular files as block devices, any file on the pod's file system that is symlinked in this way can be mounted into the VM and subsequently read. Although a security mec...

### Summary _Short summary of the problem. Make the impact and severity as clear as possible. A flawed implementation of the Kubernetes aggregation layer's authentication flow could enable bypassing RBAC controls. ### Details _Give all details on the vulnerability. Pointing to the incriminated source code is very helpful for the maintainer._ It was discovered that the `virt-api` component fails to correctly authenticate the client when receiving API requests over mTLS. In particular, it fails to validate the CN (Common Name) field in the received client TLS certificates against the set of allowed values defined in the `extension-apiserver-authentication` configmap. The Kubernetes API server proxies received client requests through a component called aggregator (part of K8S's API server), and authenticates to the `virt-api` server using a certificate signed by the CA specified via the `--requestheader-client-ca-file` CLI flag. This CA bundle is primarily used in the context of aggr...

### Impact A bug was found in containerd's CRI Attach implementation where a user can exhaust memory on the host due to goroutine leaks. Repetitive calls of CRI Attach (e.g., [`kubectl attach`](https://kubernetes.io/docs/reference/kubectl/generated/kubectl_attach/)) could increase the memory usage of containerd. ### Patches This bug has been fixed in the following containerd versions: * 2.2.0 * 2.1.5 * 2.0.7 * 1.7.29 Users should update to these versions to resolve the issue. ### Workarounds Set up an admission controller to control accesses to `pods/attach` resources. e.g., [Validating Admission Policy](https://kubernetes.io/docs/reference/access-authn-authz/validating-admission-policy/). ### Credits The containerd project would like to thank @Wheat2018 for responsibly disclosing this issue in accordance with the [containerd security policy](https://github.com/containerd/project/blob/main/SECURITY.md). ### References https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2025...

### Impact An overly broad default permission vulnerability was found in containerd. - `/var/lib/containerd` was created with the permission bits 0o711, while it should be created with 0o700 - Allowed local users on the host to potentially access the metadata store and the content store - `/run/containerd/io.containerd.grpc.v1.cri` was created with 0o755, while it should be created with 0o700 - Allowed local users on the host to potentially access the contents of Kubernetes local volumes. The contents of volumes might include setuid binaries, which could allow a local user on the host to elevate privileges on the host. - `/run/containerd/io.containerd.sandbox.controller.v1.shim` was created with 0o711, while it should be created with 0o700 The directory paths may differ depending on the daemon configuration. When the `temp` directory path is specified in the daemon configuration, that directory was also created with 0o711, while it should be created with 0o700. ### Patches Thi...