# KubeHound: Detecting Microservices' Security Smells in Kubernetes Deployments
## 4 Detecting Security Smells in Kubernetes-Based Microservices
### Hardcoded Secrets  
We consider three different instances of the _Hardcoded Secrets_ smell, for which we hereafter introduce three different detection techniques. The introduced techniques are distinguished based on whether the secrets are hardcoded in Kubernetes configuration files, Dockerfiles and source code, or in containers' environment variables. **Hardcoded Unencrypted Kubernetes Secrets**. This technique enables the detection of an instance of the _Hardcoded Secrets_ smell by statically analysing the configuration files specifying an application's deployment in Kubernetes and by looking for unencrypted secrets written therein. As stated in the official documentation, Kubernetes secrets are by default stored unencrypted, typically represented in base64 encoding, which can be decoded to recover the original secret [33]. Listing 3 shows an example of an unencrypted Kubernetes secret in which one can readily recover the username \"admin\" and password \"password\" by decoding the data fields. The tool Checkov [15] can statically detect unencrypted Kubernetes secrets in order to enforce encryption-at-rest of secrets. ```
apiVersion:v1 data:{username:YWRttaW=password:cGFzcdvcmQ=} kind:Secret type:Opaque metadata:{...}
```  
**Listing 3**. Example of an unencrypted Kubernetes secret. **Hardcoded Secrets in Dockerfiles and Source Code**. This technique enables the detection of an instance of the _Hardcoded Secrets_ smell by statically looking for hardcoded secrets in the Dockerfiles and source code of the microservices forming an application. Since it is not obvious whether secrets are stored, we can employ different techniques to find them. For instance, we can define heuristics on the names of constants (e.g., \"user\", \"password\", \"pwd\", etc. ), match the file's content against regular expressions that represent known secrets formats (e.g., AWS API keys format), or use entropy-based approaches. This analysis technique is very common among existing tools' implementations, and it is performed in both Checkov [15] and Sonarqube [20]. **Hardcoded Secrets in Containers' Environment**. This technique enables the detection of an instance of the _Hardcoded Secrets_ smell by dynamically inspecting the containers running an application's microservices. The analysis looks for hardcoded secrets within the environment variables of such containers. The environment variables can be retrieved from the containers running in the cluster's pods by exploiting the Kubernetes API with the command  
```
1*kubectlexec[pod_name]--env. Alternative approaches may exploit the docker inspect command, which also allows the inspection of the environment variables set for a running container. The retrieved environment variables are then checked to detect _Hardcoded Secrets_ using the same heuristics as those described for the _Hardcoded Secrets in Dockerfiles and Source Code_ analysis. ### Non-Secured Service-to-Service Communications

We consider one possible instance of the _Non-Secured Service-to-Service Communications_ smell, which can be detected with the analysis introduced hereafter. **Unencrypted Pod-to-Pod Traffic**. This technique enables the detection of an instance of the _Non-Secured Service-to-Service Communications_ smell by dynamically analysing the traffic exchanged among the pods used to deploy an application's microservices. The objective of the analysis is indeed to detect unencrypted traffic that is exchanged among such pods. This analysis requires the modification of the cluster by deploying network probes to record the traffic exchanged among the microservices forming the deployed application. The captured packets are then analysed to ensure that all the traffic is encrypted, reporting the cases in which packets are exchanged by exploiting unencrypted communication protocols, such as HTTP or HTTP2, for instance. ### Unauthenticated Traffic

We consider one possible instance of the _Unauthenticated Traffic_ smell, which can be detected by looking for user context drops in internal requests.