#kubernetes

# Impact A bug was found in the containerd's CRI implementation where containerd doesn't put usernamespaced containers under the Kubernetes' cgroup hierarchy, therefore some Kubernetes limits are not honored. This may cause a denial of service of the Kubernetes node. # Patches This bug has been fixed in containerd 2.0.5+ and 2.1.0+. Users should update to these versions to resolve the issue. # Workarounds Disable usernamespaced pods in Kubernetes temporarily. # Credits The containerd project would like to thank Rodrigo Campos Catelin and Piotr Rogowski for responsibly disclosing this issue in accordance with the [containerd security policy](https://github.com/containerd/project/blob/main/SECURITY.md). # For more information If you have any questions or comments about this advisory: * Open an issue in [containerd](https://github.com/containerd/containerd/issues/new/choose) * Email us at security@containerd.io To report a security issue in containerd: * [Report a new vulnerabi...

To understand Red Hat OpenShift's journey to quantum-safe cryptography, it helps to look at the current and planned post-quantum cryptography support in Red Hat Enterprise Linux (RHEL). This is because OpenShift includes Red Hat Enterprise Linux CoreOS (RHCOS), which provides several important cryptographic libraries. Bringing post-quantum cryptography to OpenShift is not a one-line configuration, of course. It's an architectural transition.There are three main areas of focus when considering post-quantum cryptography for OpenShift: RHCOS kernelsOpenShift Core userspaceGo versions used by the

Non-human identities—also known as machine or workload identities—are becoming increasingly critical as organizations adopt cloud-native ecosystems and advanced AI workflows. For workloads spanning multiple cloud platforms, adhering to zero trust principles becomes challenging as they cross identity domains. A unified identity framework provides consistency in automating identity issuance and enforcing access control policies across diverse environments. SPIFFE/SPIRE, an open source identity issuance framework, enables organizations to implement centralized, scalable identity management on

In hybrid and multicloud environments, proper management of sensitive data-like secrets, credentials and certificates is critical to maintaining a robust security posture across Kubernetes clusters. While Kubernetes provides a Kube-native way to manage secrets, it’s generally understood that Kubernetes secrets are not particularly secret: they are base64 encoded and are accessible to cluster administrators. Additionally, anyone with privileges to create a pod in a specific namespace can access the secrets for that namespace. While at-rest protection can be provided by encrypting sensitive da

Cloud-native applications offer scalable, automated workflows, intelligent data processing, and seamless deployments. However, many organizations still struggle to…

Security leaders must address both internal and external risks, ranging from sophisticated cyberattacks to insider threats. At the same time, they must also adhere to an ever-growing list of regulations, including the General Data Protection Regulation (GDPR), the EU Cyber Resilience Acts (CRA) and industry-specific mandates like Payment Card Industry Data Security Standard (PCI DSS) and the Digital Operational Resilience Act (DORA). Balancing these concerns requires a strategic approach that integrates security and compliance without compromising operational efficiency.External threatsCybercr

Microsoft has warned that using pre-made templates, such as out-of-the-box Helm charts, during Kubernetes deployments could open the door to misconfigurations and leak valuable data. "While these 'plug-and-play' options greatly simplify the setup process, they often prioritize ease of use over security," Michael Katchinskiy and Yossi Weizman from the Microsoft Defender for Cloud Research team

Security policies like [`allowed-gadgets`](https://inspektor-gadget.io/docs/latest/reference/restricting-gadgets), [`disallow-pulling`](https://inspektor-gadget.io/docs/latest/reference/disallow-pulling), [`verify-image`](https://inspektor-gadget.io/docs/latest/reference/verify-assets#verify-image-based-gadgets) can be bypassed by a malicious client. ### Impact Users running `ig` in daemon mode or IG on Kubernetes that rely on any of the features mentioned above are vulnerable to this issue. In order to exploit this, the client needs access to the server, like the correct TLS certificates on the `ig daemon` case or access to the cluster in the Kubernetes case. ### Patches The issue has been fixed in v0.40.0 ### Workarounds There is not known workaround to fix it.

Software supply chain security has become more relevant in the last decade as more and more organizations consume, develop and deploy containerized workloads. Software is inherently complex so an analogy concerning an area of life that we can all relate to should help. Here's a conversation about cooking lasagna!“Do you need any help?”“No, it's fine. I have done this a thousand times, thanks.”“That meat packaging is unusual. It’s just a thin plastic bag. Where did you get that?”“It was a bargain. A young chap knocked the door earlier and said he was selling meat. He had a coole

### Impact This issue allows an attacker who has compromised either the Elastic service or the extender plugin to cause denial of service of the scheduler. This is a privilege escalation, because Volcano users may run their Elastic service and extender plugins in separate pods or nodes from the scheduler. In the Kubernetes security model, node isolation is a security boundary, and as such an attacker is able to cross that boundary in Volcano's case if they have compromised either the vulnerable services or the pod/node in which they are deployed. The scheduler will become unavailable to other users and workloads in the cluster. The scheduler will either crash with an unrecoverable OOM panic or freeze while consuming excessive amounts of memory. ### Workarounds No