# KubeHound: Detecting Microservices' Security Smells in Kubernetes Deployments
## 4 Detecting Security Smells in Kubernetes-Based Microservices
### Hardcoded Secrets
We then injected another _Publicly Accessible Microservices_ smell by exploiting the kubect1 expose command to also expose the echo2 service. Finally, we analysed the resulting application deployment with KubeHound, observing that it successfully identified both the injected instances of the _Publicly Accessible Microservices_ smell. #### 6.1.6 Unencrypted Pod-to-Pod Traffic

This experiment aimed at checking whether KubeHound can effectively detect _Unencrypted Pod-to-Pod Traffic_ occurring in the application. We deployed the smell-free mock application on the cluster, enabling and disabling mTLS between the services by using the Istio service mesh [(42)]. More precisely, we wrote two Kubernetes configuration files:

* mTLS-disable.yaml, which specifies a PeerAuthentication object to disable mTLS in the cluster, and
* mTLS-strict.yaml, which specifies PeerAuthentication object to enable mTLS in strict mode on the cluster. Both the above-listed files can be downloaded from KubeHound's GitHub repository ([[https://github.com/di-unipi-socc/kube-hound/tree/master/data/examples/pod_to_pod_traffic](https://github.com/di-unipi-socc/kube-hound/tree/master/data/examples/pod_to_pod_traffic)]([https://github.com/di-unipi-socc/kube-hound/tree/master/data/examples/pod_to_pod_traffic](https://github.com/di-unipi-socc/kube-hound/tree/master/data/examples/pod_to_pod_traffic)), accessed on 26 June 2023). We then ran KubeHound on the cluster, making sure that we were making requests to the application while the analysis was running. When mTLS was enabled, no smells were found. Instead, when mTLS was disabled, KubeHound successfully identified the _Non-Secured Service-to-Service Communications_ smells due to the unencrypted traffic being exchanged between the deployed services. ### Case Studies

In this section, we describe two case studies based on two third-party microservices applications whose existing deployment was analysed by KubeHound. The applications are Weaveworks' Sock Shop [(44)] and Google's Online Boutique [(45)]. Both the considered applications are benchmarking applications intended to showcase microservice-basedarchitectures, but not focusing on application security. Hence, we expected that some security smells could be detected therein. #### 6.2.1 Sock Shop

Sock Shop [44] is composed of fourteen microservices implemented in different technologies whose sources are split in multiple repositories, following the \"one repository per service\" pattern. The deployment scripts can be found on the main GitHub repository of the application [[https://github.com/microservices-demo/microservices-demo](https://github.com/microservices-demo/microservices-demo)]([https://github.com/microservices-demo/microservices-demo](https://github.com/microservices-demo/microservices-demo)), accessed on 26 June 2023). while each microservice's source code, Dockerfile, and OpenAPI specification (if any) can be found in its own repository. The first thing we did for this case study was create the configuration file for letting KubeHound process Sock Shop's Kubernetes deployment and OpenAPI specifications. In the file, we specified the repositories from which to download the necessary inputs, and we set to true the external property of the front-end service, to indicate that it is acting as the gateway of the application, as indicated in the online documentation [44]. We deployed the application on a cluster, ran KubeHound on the obtained application deployment, and collected its output. We only then checked whether the security smells detected by KubeHound were present in the considered applications by inspecting their sources.