# KubeHound: Detecting Microservices' Security Smells in Kubernetes Deployments
## 1 Introduction  
Microservices are being increasingly adopted by the IT industry, with companies such as Amazon, Netflix, and Spotify already delivering their core businesses through microservices [1; 2]. This is because microservices enable obtaining so-called _cloud-native_ applications, namely, applications fully exploiting the potentials of cloud computing, and since microservices smoothly integrate with the widespread DevOps practices [3]. Microservice architectures can be seen as peculiar extensions of service-oriented architectures (SOAs), characterised by an extended set of design principles, e.g., designing microservices around business concepts, making them independently deployable and highly observable, and isolating their possible failures [4]. Microservices hence inherit the traditional security concerns for SOA, whilst also raising new security challenges [5]. For instance, compared to SOA, microservices increase the surface prone to security attacks and raise the need to establish trust among the microservices forming an application and manage distributed secrets [6]. Furthermore, microservices interactions should be thoroughly secured, not only when interacting with external clients, but also whenever a microservice communicates with another microservice of the same application [7]. In this perspective, [PERSON] et al. [1] recently elicited the smells and refactorings for microservice security. They defined the \"security smells\" for microservices as possible symptoms of bad (though often unintentional) design decisions, which can negatively affect the security of a microservice application. Examples of security smells are non-secured service communications and unauthenticated traffic, which occur when the interactions among an application's microservices are not encrypted nor authenticated. Security smells can be resolved by refactoring an application or the microservices therein. For instance, the use of Mutual TLS and OpenID Connect enables the resolution of the above-mentioned smells [1]. However, automatically detecting the security smells affecting an existing microservice application is still an open problem [8]. In this perspective, the objective of this work is to demonstrate that instances of the security smells by [PERSON] et al. [1] can be automatically detected in microservice applications,while also providing an extensible tool for supporting this task. More precisely, the main contributions of this work are the following:  
1. We demonstrate that security smell detection can be automated by proposing a set of techniques enabling the detection of such smells in microservice applications deployed with Kubernetes, the de facto standard for orchestrating microservices [5]. 2. We introduce KubeHound, an open-source security-smell-detection tool that already features the implementation of a selected subset of the analyses in (i). KubeHound is extensible and modular, enabling users to specify custom plugins that implement additional analyses to be applied. 3. We assess our approach in practice by running KubeHound in controlled experiments with a \"mock\" microservice application and by applying it in two case studies based on existing, third-party applications. It is worth noting that KubeHound follows a \"best effort\" approach, meaning that it runs a smell-detection technique only if all the resources it needs are available. In other words, KubeHound performs the largest possible subset of smell-detection techniques it can, given the inputs provided by an end-user. This enables end-users to provide only what they wish to be analysed, e.g., also enabling KubeHound to work if the source code of some microservices is not available or if users do not wish KubeHound to interact with a running instance of the target microservice application. The rest of this article is organised as follows. Section 2 provides the necessary background on microservice security smells [1]. Section 3 discusses the relevant related work.