#kubernetes

The security landscape for cloud-native applications is undergoing a profound transformation. Containers, Kubernetes, and serverless technologies are now the default for modern enterprises, accelerating delivery but also expanding the attack surface in ways traditional security models can’t keep up with. As adoption grows, so does complexity. Security teams are asked to monitor sprawling hybrid

Red Hat helps organizations embrace AI innovation by providing a comprehensive and layered approach to security and safety across the entire AI lifecycle. We use our trusted foundation and expertise in open hybrid cloud to address the challenges around AI security, helping our customers build and deploy AI applications with more trust.Understanding enterprise AI security risksAs organizations adopt AI , they encounter significant security and safety hurdles. These advanced workloads need robust infrastructure and scalable resources and a comprehensive security posture that extends across the A

As Kubernetes becomes the foundation of enterprise infrastructure, the underlying operating system must evolve alongside it.

Hello Kubernetes Community, A security issue was discovered in secrets-store-sync-controller where an actor with access to the controller logs could observe service account tokens. These tokens could then potentially be exchanged with external cloud providers to access secrets stored in cloud vault solutions. Tokens are only logged when there is a specific error marshaling the `parameters` sent to the providers. ### Am I vulnerable? To check if tokens are being logged, examine the manager container log: ```bash kubectl logs -l 'app.kubernetes.io/part-of=secrets-store-sync-controller' -c manager -f | grep --line-buffered "csi.storage.k8s.io/serviceAccount.tokens" ``` ### Affected Versions - secrets-store-sync-controller < v0.0.2 ### How do I mitigate this vulnerability? Upgrade to secrets-store-sync-controller v0.0.2+ ### Fixed Versions - secrets-store-sync-controller >= v0.0.2 ### Detection Examine cloud provider logs for unexpected token exchanges, as well as unexpected...

August Linux Patch Wednesday. I’m late with this LPW since I was improving the generation of LPW bulletin lists and the operation of Vulristics. 🙂 In August, Linux vendors addressed 867 vulnerabilities, nearly twice July’s total, including 455 in the Linux Kernel. One vulnerability is confirmed exploited in the wild (CISA KEV): 🔻 SFB – […]

The Confidential Clusters project integrates confidential computing technology into Kubernetes clusters. It's an end-to-end solution that provides data confidentiality on cloud platforms by isolating a cluster from its underlying infrastructure. In a confidential cluster, all nodes run on top of confidential virtual machines (cVM). Before a node can join the cluster and access secrets, the platform and environment's authenticity are verified through remote attestation. This process involves communication with a trusted remote server.Confidential Clusters enables you to use Red Hat OpenShift,

### Impact A vulnerability has been identified when using Fleet to manage Helm charts where sensitive information is passed through `BundleDeployment.Spec.Options.Helm.Values` may be stored in plain text. This can result in: 1. Unauthorized disclosure of sensitive data: Any user with `GET` or `LIST` permissions on `BundleDeployment` resources could retrieve Helm values containing credentials or other secrets. 2. Lack of encryption at rest: `BundleDeployment` is not configured for Kubernetes encryption at rest by default, causing sensitive values to remain unencrypted within the cluster datastore. This behavior differs from Helm v3’s default approach, where chart state — including values — is stored in Kubernetes secrets, benefiting from built-in protection mechanisms. In affected scenarios, credentials and other sensitive information are exposed both at rest and in responses to API calls. Please consult the associated [MITRE ATT&CK - Technique - Credentials from Password Stores](ht...

### Impact A vulnerability has been identified within Rancher Manager in which it did not enforce request body size limits on certain public (unauthenticated) and authenticated API endpoints. This allows a malicious user to exploit this by sending excessively large payloads, which are fully loaded into memory during processing. This could result in: - Denial of Service (DoS): The server process may crash or become unresponsive when memory consumption exceeds available resources. - Unauthenticated and authenticated exploitation: While the issue was initially observed in unauthenticated `/v3-public/*` endpoints, the absence of request body size limits also affected several authenticated APIs, broadening the potential attack surface. It's worth noting that other areas in Rancher do implement safeguards: requests proxied to Kubernetes APIs are subject to built-in size limits enforced by the [Kubernetes API server itself](https://github.com/kubernetes/kubernetes/blob/v1.33.4/staging/src/k8s...

This is the same vulnerability as https://github.com/edgelesssys/contrast/security/advisories/GHSA-h5f8-crrq-4pw8. The original vulnerability had been fixed for release `v1.8.1`, but the fix was not ported to the main branch and thus not present in releases `v1.9.0` ff. Below is a brief repetition of the relevant sections from the first GHSA, where you can find the full details. ### Impact * [Workload secrets](https://docs.edgeless.systems/contrast/1.11/architecture/secrets#workload-secrets) are visible to Kubernetes users with `get` or `list` permission on `pods/logs`, and thus need to be considered compromised. * Since workload secrets are used for [encrypted storage](https://docs.edgeless.systems/contrast/1.11/howto/encrypted-storage) and [Vault integration](https://docs.edgeless.systems/contrast/1.11/howto/vault), those need to be considered compromised, too. ### Patches Patches: * https://github.com/edgelesssys/contrast/commit/5a5512c4af63c17bb66331e7bd2768a863b2f225 * https...

### Impact A vulnerability exists in NeuVector versions up to and including **5.4.5**, where a fixed string is used as the default password for the built-in `admin` account. If this password is not changed immediately after deployment, any workload with network access within the cluster could use the default credentials to obtain an authentication token. This token can then be used to perform any operation via NeuVector APIs. In earlier versions, NeuVector supports setting the default (bootstrap) password for the `admin` account using a Kubernetes Secret named `neuvector-bootstrap-secret`. This Secret must contain a key named `bootstrapPassword`. However, if NeuVector fails to retrieve this value, it falls back to the fixed default password. ### Patches This issue is resolved in NeuVector version **5.4.6** and later. For rolling upgrades, it's strongly recommended to change the default `admin` password to a secure one. Starting from version **5.4.6**, NeuVector introduces addition...