KubeCon + CloudNativeCon India 2024

The most widely used runtime enforcement techniques today are prone to attackers. Many of these techniques work on the principle of stopping or killing a process in response to an attack, which relies at the mercy of an exploit writer putting little to no effort into avoiding triggering these detection mechanisms. Our discussion will focus on various aspects of runtime security: how it is currently implemented, its shortcomings, and the performance implications associated with these approaches. We'll explore a various range of cloud-based runtime security implementations. We'll expose the attacker's perspective, demonstrating how they can bypass these common runtime security measures. This will equip you to anticipate and counter their tactics. Finally, we will cover recent popular attacks and how appropriate runtime security measures can prevent them in the future.

Among the 4C (Cloud, Cluster, Container, Code) security in Kubernetes, there are various techniques to enhance the security of the cluster surface. In particular, Admission Control (webhook) is one of the most flexible and powerful methods. As this trend, there is movement to apply it to various forms of Kubernetes(e.g. GKE, Openshift and so on). In my opinion, one of the easiest and most efficient ways to apply it is to improve security through CEL (Common Expression Language). I believe that the Validating Admission Policy becoming `stable` in v1.30 is part of this proof. So I will show you the CEL DEMO provided by Google Cloud to get a quick and easy understanding of how to improve the security of GKE. Through this exercise, you will learn the basic structure of CEL and the freedom of scope that can be applied, and you will be able to apply it to any other platform with minimal effort.

Security is non-negotiable area and Kubernetes based environments are no exception! Usage of x509 certificates is the key thing. Be it K8s deployments in private or public cloud, ensuring availability of "right" X509 certificate for a service is very important. If this service is getting connected from external (apps/clients which are outside of K8s cluster) clients, this is even more important! But what is really the "right" x509 certificate and how can we ensure that is always remains "right"? Can we make corrections dynamically? Can we also ensure easy propagation of certificates imported from outside the cluster? Propagation of Certificate revocation lists to ensure services can deny revoked certificates? This talk helps describe the strategy K8s based products can use to dynamically generate, make correction and propagation of X509 certificates within K8s cluster using K8s operator design pattern and makes use of well-known CNCF projects such as cert-manager and trust-manager.

Join this talk to uncover the story of a high severity CVE-2024-26147 [CVSS: 7.5] discovered in Helm and understand the role of fuzzing in maintaining the ecosystem’s integrity. Through this demonstration, you'll see firsthand the systematic approach used to identify the vulnerability that caused Helm to panic when faced with missing YAML metadata. The issue enabled crashing Helm SDK-based clients over the network and additionally, bricking local Helm client installations. We'll dive into the specific tools and techniques that were instrumental in detecting the issue, focusing on their applicability to your daily work. This session is designed not just to share a discovery but to foster a community-wide commitment to proactive security practices. Learn how these insights can be applied to strengthen the security and reliability of your Kubernetes deployments, ensuring a safer environment for all users of the ecosystem.

Emerging Telco trends such as ORAN, advanced 5G core demands a disaggregated arch for scaling. Kubernetes based deployments are becoming a norm and much of the open CNCF/LF tooling are playing a major role. The aim of this submission is to talk about the challenges that Nephio(www.nephio.org) SIG-Security team faced about streamlining security operations across multi-cluster multi-region, multi-vendor based deployments. The aim is to talk about specific instances/use-cases where the Nephio management cluster needs to securely interact with regional/edge clusters for the control plane needs. Also why/how the Nephio security team envisaged SPIFFE as a foundational layer to bind multi region together. A particular problem statement in the context of ORAN deployments where SMO (Service Mgmt Orchestation) has to securely interact with IMS (Infra Mgmt Service) for secure creation of infrastructure and the role SPIFFE played in the context would be highlighted.