Security | Threat Detection | Cyberattacks | DevSecOps | Compliance

The desire to take advantage of the modern cloud-native paradigm has forced many enterprises to rush to production with Kubernetes and containerized applications. Often, the incorrect expectation with cloud-native adoption is that Ops teams would be able to easily transition their existing security and operational practices, workflows and tooling to these new software development platforms and everything would still work as before.

Kubernetes is the de-facto container management platform of today and the future. It has increased the scalability and flexibility of applications and eliminated vendor lock-in. Kubernetes also brings a lot of security native features; however, with security, the devil is always in the details. By default, the security of cloud services, applications, and infrastructure is not in the scope of Kubernetes. This does not mean that running Kubernetes is destructive and makes your applications vulnerable.

Cross-cluster migration of Kubernetes workloads continues to be challenging since workloads are isolated from each other by design. There are several reasons why you may want to separate your workloads, whether it is to reduce complexity or to have the cluster closer to the user base. However, this can be complex as Kubernetes has many components.

Enterprises are embracing the cloud native paradigm for agility, scalability, composability, and portability. Kubernetes, the open source container orchestration engine, is the foundation of modern, cloud native workloads. AWS customers can leverage managed Kubernetes available in the form of Amazon Elastic Kubernetes Service (EKS) or deploy a cluster based on upstream Kubernetes distribution running in a set of Amazon EC2 instances.

From a people perspective and an organizational standpoint, many CISOs have said that their security teams are not ready for containers and Kubernetes. This isn’t surprising, given the stark contrast between where we were less than a decade ago and where we are today in terms of systems architecture. I am of course referring to the cloud-native era, which has ushered in a whole new architectural approach.

Kubernetes leverages various deployment objects to simplify the provisioning of resources and configuration of workloads running in containers. These objects include ReplicaSets, lSets, Sets, and Deployments. A pod is the smallest deployment unit in Kubernetes that usually represents one instance of the containerized application.

Container-based web applications built on microservices architecture, whether public-facing or internal, are critical to businesses. This new class of applications is commonly referred to as cloud-native applications. Read on to find out why traditional WAFs are no longer enough to protect cloud-native applications and how Calico’s new workload-centric WAF solves this problem.

When running containers in a Kubernetes cluster, trusting the images you deploy is key to enforce security. The use of mutable images represents a risk to the secure Kubernetes deployment and highlights the importance of having a reliable mechanism to ensure you run what you expect. In this blog, you will learn step-by-step how to implement a secure Kubernetes deployment.

Kubescape is a Kubernetes open-source platform providing a multi-cloud K8s single pane of glass, including risk analysis, security compliance, RBAC visualizer, and image vulnerabilities scanning.

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.