# KubeHound: Detecting Microservices' Security Smells in Kubernetes Deployments
## 4 Detecting Security Smells in Kubernetes-Based Microservices
### Unnecessary Privileges to Microservices  
We consider two different instances of the _Unnecessary Privileges to Microservices_ smell, for which we hereafter introduce two different detection techniques. The detected instances are distinguished based on whether they are detected by analysing the privileges assigned to the pods in Kubernetes configuration files or by checking the network policies.  
**Unnecessary Privileges to Kubernetes Pods**. This technique enables the detection of an instance of the _Unnecessary Privileges to Microservices_ by statically analysing the configuration files specifying an application's deployment in Kubernetes. The analysis checks the privileges of the cluster's pods by parsing the Kubernetes configuration files specifying them.  
Kubernetes allows developers to configure each pod with some associated privileges, e.g., through the securityContext field, which describes the security properties that a deployed pod should have (Listing 2). This field can be given for each pod or each container in a pod, enabling a more granular privilege specification. The properties specified include, e.g., if the service should run as privileged or unprivileged, its access control to files using User ID and Group ID, and its Linux capabilities. A proper setting of the securityContext field can thus help achieve minimal privileges for a microservice at the level of the Kubernetes pod used to deploy it [30]. Implementations of this analysis should ensure that the service is running as a non-privileged user, the application has minimal capabilities, and the host network namespace is invisible to the service.  
```
securityContext: runAsMonRoot: true runAsUser: 10001 allowPrivilegeescalation: false readOnlyRootFilesystem: true capabilities: { drop: [ all], add: [ NET_BINO_SERVICE ] }
```  
Listing 2: Example configuration of securityContext.  
Moreover, the proper configuration of service accounts should be taken into careful consideration. If this is not carried out, an attacker that obtained unauthorised access to a pod's file system, e.g., by exploiting a software vulnerability, may also be able to escalate their privileges by gaining access to the Kubernetes API. Service accounts offer a solution to try to mitigate the impact of this occurrence by offering the pods a token to access the Kubernetes API, if needed, and with limited privileges [31]. The described analysis is implemented and validated in two existing tools, viz., Kubesec.io [14] and Checkov [15].  
**Misconfigured Network Policies**. This technique enables the detection of an instance of the _Unnecessary Privileges to Microservices_ smell by dynamically checking whether each service can communicate only with the services it is supposed to. In Kubernetes, developers can configure network policies. These are often used in combination with Kubernetes namespaces to create groups of microservices that can communicate with each other, but not with other entities [32]. This enables creating pods with the fewest privileges possible, as they can access only the services/resources they require to provide their functionality. The tool Kube-bench [16] can be used to dynamically check such network policies.