# KubeHound: Detecting Microservices' Security Smells in Kubernetes Deployments
## 4 Detecting Security Smells in Kubernetes-Based Microservices
### Insufficient Access Control  
We consider three different instances of the _Insufficient Access Control_ smell, for which we hereafter introduce three different detection techniques. The detected instances are distinguished based on whether they affect the specification of the microservice's API, their actual implementations, or their deployment in Kubernetes. In the first two cases, we take the OpenAPI standard [23] as a reference to specify microservices' API. When analysing the OpenAPI specification of microservices' API, we assume their actual implementation to align to that specified, as possible divergences can be automatically detected with existing techniques [24].  
**Insufficient Access Control in API Specifications**. This technique enables the detection of an instance of the _Insufficient Access Control_ smell by statically analysing the OpenAPI specification of microservices' APIs. This can be accomplished by identifying specific endpoints or even whole services that are not performing authorisation, according to their OpenAPI specification. The OpenAPI standard indeed allows specifying the authorisation scheme enacted by each endpoint of a microservice's API by specifying a security field, which links to a securityscheme. The latter specifies the actual authorisation scheme enforced by the endpoint, which spans from passing the username and password passed through HTTP headers, to more elaborate schemes exploiting API keys, OAuth2, or OpenId Connect [23]. The actual implementation of this analysis technique must take into consideration that the authentication endpoint itself does not by design have a security scheme associated with it. In addition, there could be some endpoints that are by design accessible without any authentication (e.g., to provide pre-authentication functionality).  
**Insufficient Access Control in Services' Implementations**. This technique enables the detection of an instance of the _Insufficient Access Control_ smell by dynamically analysing microservices' APIs, and more precisely by enacting automated API security testing. To ensure that the services perform correct access control, it is not enough to check their API specification, because the services' implementation may not fully adhere to their specification. Some form of dynamic testing is thus required to test the correctness of the authorisation implementation. This analysis does not require the modification of the cluster's structure, since it can be performed by deploying a testing pod in the cluster that calls an application's microservices and checks their response to detect possible anomalies. The testing pod can be implemented in two ways: if an OpenAPI specification is given, then OpenAPI-fuzzer [19] can be employed to check the compliance of the services' implementation with their specifications. Otherwise, OWASP ZAP can be used to detect broken access control in the services' APIs [18].  
**Insufficient Access Control to the Kubernetes API**. This technique enables the detection of an instance of the _Insufficient Access Control_ smell affecting the Kubernetes control plane by dynamically interacting with it. The Kubernetes API should indeed be configured with proper authentication and authorisation configurations, since leaving the API unprotected could lead to compromising the Kubernetes control plane, which would give an attacker full control of the deployed application. Development teams should also set up proper user/service accounts, configured with the fewest privileges to limit the risk of unauthorised access to the Kubernetes API with full privileges [25]. A tool that can be used to check whether this is the case is Kube-hunter [17], which ensures that the Kubernetes API is secured and has proper access control configured.