Container-orchestration software such as Kubernetes make it easy to deploy and manage modern cloud applications based on microservices. Yet, its network abstractions pave the way for "unexpected attacks" if we approach cloud network security with the same mental model of traditional network security.Microservices have become the template for cloud-native applications: easy to develop, deploy, debug, scale, and share. When an application is decomposed into independent microservices, ensuring that the services can communicate with one another in a secure way introduces new challenges, particularly when the decomposition results in many services. Even rudimentary cloud applications contain a few tens of microservices, and some of the largest (e.g., Netflix and Uber platforms) contain hundreds or thousands of microservices, possibly running on several containers. Container-orchestration software such as Kubernetes (K8s) 1 provide a simplified interface or model to address these challenges.At the same time, abstractions make it easy to overlook security threats. For example, (in)secure practices concerning use of K8s default configuration have been well studied. 2,3 Security issues in software-defined networking (SDN) solutions used for managing cloud infrastructure have also been investigated. 4,5 Nam et al. 6 present an overview of security challenges in container networks and the limitations of common networking plug-ins.In particular, the security implications of K8s networking components (e.g., how K8s configures connectivity between services and enforces network-security policies) are largely unexplored. Indeed, when we think about networking between microservices, we have a "mental model" of networking derived from physical networks, with switches and interfaces interconnected with physical cables-a model that we show significantly departs from reality.As a result, when thinking about (cloud) network security, we may picture "digitally unbridgeable moats" that do not really exist. The correct analogy with traditional networking would be that as one is able to escalate within a switching device, then one can start laying cables between different devices. The key takeaway is not that K8s is insecure, but that it is insecure to apply the "mental extension" of traditional network security terminology to a different world. A Playground for "Unexpected Attacks"To understand the issues, consider some typical deployment scenarios in which a company is wishing to use K8s.A K8s-single-cluster consists of one master and one or more (i.e., a customizable number of) worker nodes. The applications aimed at the users are deployed on two clusters-"development" and "production"-both of which contain the same set of applications, but with different levels of security (typically, more restricted

No abstract

No abstract

No abstract

Securing cloud configurations is an elusive task, which is left up to system administrators who have to base their decisions on "trial and error" experimentations or by observing good practices (e.g., CIS Benchmarks). We propose a knowledge, AND/OR, graphs approach to model cloud deployment security objects and vulnerabilities. In this way, we can capture relationships between configurations, permissions (e.g., CAP SYS ADMIN), and security profiles (e.g., AppArmor and SecComp), as first-class citizens. Such an approach allows us to suggest alternative and safer configurations, support administrators in the study of what-if scenarios, and scale the analysis to large scale deployments. We present an initial validation and illustrate the approach with three real vulnerabilities from known sources.