# KubeHound: Detecting Microservices' Security Smells in Kubernetes Deployments
## 4 Detecting Security Smells in Kubernetes-Based Microservices
### Hardcoded Secrets
We now comment on some of the security smells reported by KubeHound on Sock Shop, while the full list of identified smells can be found online ([[https://github.com/di-unipi-socc/kube-hound/tree/master/data/examples/sock_shop](https://github.com/di-unipi-socc/kube-hound/tree/master/data/examples/sock_shop)]([https://github.com/di-unipi-socc/kube-hound/tree/master/data/examples/sock_shop](https://github.com/di-unipi-socc/kube-hound/tree/master/data/examples/sock_shop)), accessed on 26 June 2023). **Unnecessary Privileges to Microservices**. By analysing Sock Shop's Kubernetes manifest files, KubeHound identified various instances of the _Unnecessary Privileges to Microservices_ smell in multiple services. We hence inspected such Kubernetes manifest files, observing that there are inconsistencies in the privileges assigned to the pods, which correspond to the identified smell instances. For instance, in the deployment configuration of the service carts-db the securityContext specification is incomplete, as fields such as the runAsNonRoot are missing and resource limits and requests are not present. Other examples are given by the deployment of the service queue-master, which lacks altogether any security-related specification, and by the fact that all services do not have any service account specified. All those instances of the _Unnecessary Privileges to Microservices_ smells were correctly identified by KubeHound. **Insufficient Access Control**. The check for _Insufficient Access Control in API Specifications_ enacted by KubeHound identified that each microservice's OpenAPI specification did not include any securityScheme, hence classifying this as an instance of the _Insufficient Access Control_ smell. Upon inspection of the APIs exposed by the internal services and their implementation, we realised that Sock Shop's microservices indeed do not enact any authorisation of requests, as correctly witnessed by the identified instances of the _Insufficient Access Control_ smell. **Harcoded Secrets**. The detection of _Hardcoded Secrets in Containers' Environment_ implemented by KubeHound found an interesting result, namely, that catalogue-db's environment includes a variable named MYSQL_ROOT_PASWORD, which stores a secret starting with fake. One such variable was quite suspicious, as it very likely contains the database's root password for the catalogue-db. We then inspected the Kubernetes deployment of the catalogue-db service, and we identified the hardcoded database password (viz., fake_password), meaning that the identified smell instance was denoting a security issue for the application. **Non-Secured Service-to-Service Communications**. KubeHound reported unencrypted HTTP traffic sent to or from all Sock Shop's microservices, hence identifying instances of the _Non-Secured Service-to-Service Communications_ smell on all of them (Listing 7). We hence inspected the application to detect whether this truly denote some security issue, finding that this was the case, as no encryption was performed on the messages exchanged among Sock Shop's microservices. ``` Secrets in environment variables analysis - detected smells (HS) Detected secret in pod catalogue-db-6d49c7c65-146 bk, container catalogue-db variable: MYSQL_ROOT_PASSWORD=fakes========.........................................................  
was much more adherent to good security practices, so in the case of the application deployed with Istio enabled, the identified security smells did not correspond to true bad security decisions in the application. Indeed, KubeHound identified _Hardcoded Secrets_ due to the featured, heuristics-based _Hardcoded Secrets in Containers' Environment_ analysis, which reported false positive secrets this time. KubeHound also detected _Unnecessary Privileges to Microservices_ smells due to Online Boutique's microservices running as root.