You might think that your metrics are harmless from a security point of view. Well, that’s not true, and in this talk at KubeCon Valencia 2022, we share the risk of exposed Prometheus server and how attackers use this information to successfully access a Kubernetes cluster. The slides are available here, and we also collected some mentions in social media and blogs and the feedback was very positive: It was our first time as speakers at KubeCon and expectations were really high.

In a Kubernetes cluster, Control Plane controls Nodes, Nodes control Pods, Pods control containers, and containers control applications. But what controls the Control Plane? Kubernetes exposes APIs that let you configure the entire Kubernetes cluster management lifecycle. Thus, securing access to the Kubernetes API is one of the most security-sensitive aspects to consider when considering Kubernetes security.

Why settle for less! The challenge of manually dealing with self-hosting a product like Velero or Kasten on dozens of clusters and multiple clouds, and then trying to migrate data across different accounts and even different clouds is very different from dealing with a single cluster and a single cloud environment. CloudCasa provides a guided workflow for cross-account and cross-cluster Kubernetes restores in Amazon EKS from an intuitive GUI.

Amazon EKS Anywhere (EKS-A) on Bare Metal is a new deployment option for Amazon Elastic Kubernetes Service that launched this week. Why bare metal? In the age of the cloud it would seem to go against “best practices.” On the contrary. While we tend to overuse the term, “hybrid cloud,” it is a real thing. Enterprises come in all shapes and sizes — and so do their compute choices and privacy requirements.

At Sysdig, we are constantly looking for ways to improve the security posture of the organizations that we work with. One of the areas we continuously improve upon is our platform’s threat intelligence and detection capabilities that leverage the open-source Falco project. We incorporate threat intelligence sourced from our own strategically placed honeypots, data collection systems, and multiple other open-source feeds.

Containers revolutionized how we build, deploy, and run applications with increased speed, agility, and scalability. But, as often happens with transformative technologies, they require an evolution to security strategy. Centralized deployments inside a protected perimeter gave way to continuous and distributed deployment of containers, creating a growing, dynamic, and distributed attack surface. IT and security teams were left blind and exposed in the cloud.

Either through human error or intentionally, configuration changes in the cloud may suddenly increase your attack surface. AWS Route 53 is an example of a service that needs to be continuously tracked for risky changes. As the first line of defense of our cloud, it is necessary to secure Amazon Route 53 and monitor risky configuration changes to avoid unwanted surprises. As you probably know, AWS Route 53 is of course a very popular DNS service offered by AWS, with millions of top-level domains.

In my previous blog, I introduced the brief history of zero trust, the core pillars of a zero-trust model, and how to build a zero-trust model for cloud-native workloads. In this blog, you will learn how Calico can help mitigate vulnerabilities such as the recent zero-day Log4j vulnerability with its zero-trust workload security approach.