In the rapidly evolving world of container orchestration, developers have come to rely on Kubernetes to manage containerized applications. However, as Kubernetes adoption increases among organizations, ensuring the security of Kubernetes environments becomes essential. One particularly significant aspect to consider is vulnerability prioritization. It’s essential to understand that chasing after the highest CVSS scoring vulnerabilities might not always align with real-world threats.

Addressing Common Vulnerabilities and Exposures, known as CVE patching, is a practice of applying updates to software (patching) to address security vulnerabilities. CVE patching is your shield against the threat of malicious actors exploiting such weaknesses and is of crucial importance for every organization’s cybersecurity. This post will cover the basics of CVE patching: the roles and stakeholders, the step-by-step process, and common mistakes to avoid.

Guest post originally published on Kubescape’s blog by Oshrat Nir, Developer Advocate at ARMO and a Kubescape contributer.

Kubernetes 1.29 will be the last release from the Kubernetes team for 2023. The new release has 49 enhancements, with a multitude of beta and stable ones in addition to a high number of bug fixes. As Kubernetes security professionals, we explored the release to find the most notable security-centric features and improvements. This blog is tailored for those with a keen eye for security, aiming to break down how these changes will impact and enhance the security posture of Kubernetes clusters.

Kubernetes has revolutionized container orchestration, becoming the go-to platform for managing containerized workloads at scale. However, with its growing popularity, the complexity of managing role-based access control (RBAC) on Day 2 and especially in a multi-cluster environment has become a daunting task. DevOps, SRE, and Platform teams are responsible for multiple clusters and different teams.

In the evolving landscape of technology, cloud agnosticism has seen increasing traction. This refers to the ability to design and deploy applications seamlessly on any cloud platform, whether that be AWS, GCP, Azure, or others. Cloud agnosticism is essentially a design principle that advocates for flexibility, portability, and interoperability, allowing organizations to use multiple cloud providers without being tied to the services or infrastructure of any single one.

As you begin developing your application to get services in front of your customers, you will notice a lot of processes and contributors are involved—from development to production. All of these processes and people are part of the “software supply chain.” It goes without saying that your software supply chain plays a crucial role in ensuring your business’s success.

GitOps can be a powerful means of achieving continuous compliance in Kubernetes deployments. It provides transparency for any changes made to your infrastructure, along with the ability to trace and audit these changes. In this article, we will discuss how GitOps can enhance security and ensure compliance in Kubernetes deployments. We will also discuss potential security threats that GitOps could introduce into a Kubernetes infrastructure.

While Kubernetes adoption continues to soar, it has become a prime target for cyberattacks. Unfortunately, Kubernetes clusters are complex and can be difficult to secure. Safeguarding your Kubernetes environment requires a solid understanding of the common attack chains that pose a threat to your infrastructure. In this blog post, we dig into the top attack chains that target Kubernetes, shedding light on the risks and offering valuable insights to bolster your defenses.

According to research done by ARMO, 100% of Kubernetes clusters that were tested contained at least one misconfiguration, while 65% had at least one high-severity misconfiguration. 50% of clusters had 14 or more failed security controls. According to Redhat research from 2023, 45% of respondents experienced security incidents or issues related to containers and/or Kubernetes due to misconfigurations.