# KubeHound: Detecting Microservices' Security Smells in Kubernetes Deployments
## 4 Detecting Security Smells in Kubernetes-Based Microservices
### Hardcoded Secrets
Moreover, these applications are rather complex, and this makes it difficult to exploit them to \"unit test\" the implemented analyses. We instead decided to implement a mock microservice application that focused on security and that would adhere to well-known architectural security patterns [46; 47]. The idea was to have a microservice application without any security smells and to artificially introduce them to test the analyses. The mock application is composed of the seven microservices shown in Figure 4, each with an associated OpenAPI specification of its API. The microservices are essentially instances of the following three types of services:

* The Authorization server handles user tokens and authorisation. * The Gateway service implements an API gateway for all the functionalities of the application. * Echo services call other Echo services (following the topology shown in Figure 4), wait for their answers, and then simply return back the messages they received when invoked. The functionality is therefore very simple: the gateway exposes a /login endpoint, where the user can perform authentication and receive an access token, and two endpoints /echo1 and /echo2 that simply return back the input to the user. These two endpoints must be called by the user using the authorisation token emitted by the Authorization server. Decentralised authorisation is implemented by using a signed user claim token emitted by the Authorization server, which is decoupled from the \"external\" authorisationmechanism [48]. A variant of this pattern was presented by Netflix in 2019, using what they called a \"user passport\" to solve the user-identification and -authorisation problems [49]. We also used the Istio service mesh to enable mTLS communications between the services. In the following, we show how we configured our mock application to inject instances of the security smells covered by the analysis techniques implemented by the plugins featured by KubeHound. Our objective is to demonstrate that all injected smell instances were automatically detected by KubeHound. #### 6.1.1 Insufficient Access Control in API Specifications

To test whether KubeHound can detect _Insufficient Access Control_ in API specifications, we devised three alternative versions of the OpenAPI specification of the Echo service, which can be found online ([[https://github.com/di-unipi-socc/kube-hound/tree/master/data/examples/openapi_security/openapi_iac](https://github.com/di-unipi-socc/kube-hound/tree/master/data/examples/openapi_security/openapi_iac)]([https://github.com/di-unipi-socc/kube-hound/tree/master/data/examples/openapi_security/openapi_iac](https://github.com/di-unipi-socc/kube-hound/tree/master/data/examples/openapi_security/openapi_iac)), accessed on 26 June 2023). * The specifications in echo_no_security.yaml and echo_no_schemes.yaml instantiate two different _Insufficient Access Control_ smells by not specifying the service's security or securityScheme, respectively. * In echo_security_override.yaml, the POST /echo endpoint is overriding the global security policy with an empty policy (i.e., no authorisation is performed). We then executed three different runs of KubeHound, to which we passed the smell-free mock application deployment. In each run, we replaced the OpenAPI specification of the Echo service with one of the above-listed specifications. As a result, we observed that KubeHound was capable of identifying all the injected security smells. #### 6.1.2 Multiple Authentication Endpoints in Services' API Specifications

For this experiment we modified the OpenAPI specification of the Gateway service, naming it gateway_multiple_auth.yaml and including an additional endpoint secured with HTTP Basic. This is an instance of the _Multiple User Authentication_ smell, since the modified version has two endpoints that perform authentication. KubeHound was able to correctly identify it as an instance of the _Multiple User Authentication_ smell.