# KubeHound: Detecting Microservices' Security Smells in Kubernetes Deployments
## 4 Detecting Security Smells in Kubernetes-Based Microservices
### Hardcoded Secrets
Instances of the _Centralised Authorisation_ smell can also be detected by using the _Insufficient access control in Services' APIs_ analysis described in Section 4.1, detecting missing authorisation in the internal services' APIs. We here identify another possible instance of the _Centralised Authorisation_ smell, for which we provide the following detection technique. **Central Request Point**. This technique enables the detection of an instance of the _Centralised Authorisation_ smell by dynamically checking whether there exists a single microservice that is invoked for each request made to an application. _Centralised Authorisation_ indeed also occurs if the application is using a single microservice to perform authorisation. The analysis could make requests to the application and then, for each one of them, we inspect the call graph of the internal services. If there is one service that is always called (other than the edge service, which will likely be the API gateway) we can suspect that it is performing authorisation. As with the _User Context Drop in internal requests_ analysis (Section 4.8), this analysis requires modification of the cluster by inserting network probes and enabling access to the network packet content. ### Summary

Table 1 recaps the techniques introduced in the previous sections to enable automatic detection of instances of the microservice security smells of [PERSON] et al. [1]. The table associates each analysis technique with its type and its needed inputs. It hence distinguishes the static analysis techniques processing the application's source code, deployment files, or OpenAPI specification from the dynamic analysis techniques interacting with a modified/unmodified cluster where the application is running. Table 1 also indicates the security smells that can be detected with each analysis technique and the existing tools that can be used to implement such techniques, if any. The analyses listed in Table 1 provide examples of techniques enabling the detection of different instances of the microservices' security smells of [PERSON] et al. [1] to demonstrate that their detection can be automated. At the same time, being examples, such analysis techniques are not intended to comprehensively cover all the possible instances of such smells. For instance, we consider the OpenAPI standard for microservices' API specifications, if available, but APIs might be specified in different formats and therefore require different analysis techniques. For future work, we plan to expand the set of analysis techniques enabling the automatic detection of instances of the microservices' security smells, with the ultimate goal of enabling a more comprehensive and effective detection of microservice security smells. This is one of the main reasons behind developing an extensible tool for microservice smell detection, like the one we introduce in the following section. ## 5 An Extensible Tool for Detecting Microservices' Security Smells

We hereafter introduce KubeHound, a prototype tool for automatically detecting security smells in microservice applications. More precisely, after describing the extensible architecture of KubeHound (Section 5.1), we present its prototypical implementation (Section 5.2) and that of the six smell-detection techniques it already features (Section 5.3).