# KubeHound: Detecting Microservices' Security Smells in Kubernetes Deployments
## 2 Background  
We hereafter recall the security smells for microservices proposed by [PERSON] et al. [1], which they organised in the taxonomy in Figure 1. We then show how to detect instances of each of such smell in Kubernetes-deployed microservices in Section 4. **Insufficient Access Control**. This smell occurs when a microservice does not enforce access control. The lack of access control may indeed compromise the _Confidentiality_ of a microservice, as attackers can trick it and access data/functions that should not be accessible to them. The possible effects of _Insufficient Access Control_ can be mitigated by applying the _Use OAuth 2.0_ refactoring, namely, by exploiting the access-delegation framework OAuth 2.0 to control the accesses to a microservice. Figure 1: Taxonomy showing the (**a**) affected security properties, (**b**) security smells, and (**c**) refactorings for microservices [1]. **Publicly Accessible Microservices**. This smell occurs when a microservice can be invoked directly by an external client. This would require authentication to be performed on all publicly accessible microservices, always requiring users' credentials, which may compromise the application's _Confidentiality_ (e.g., by exposing long-term credentials). It would also result in increasing an application's overall attack surface and in reducing its usability and maintainability. For this reason, the suggested refactoring is to _Add an API Gateway_ to be used as the entry point of the application. Individual microservice APIs can then be accessed through the gateway, and authentication can be performed centrally, overall reducing the attack surface of the application and simplifying authentication-auditing tasks. **Unnecessary Privileges to Microservices**. This smell occurs when unnecessary privileges are granted to a microservice, even if it does not need them to deliver its business functions. If this is the case, the resources of an application may become unnecessarily exposed, therefore increasing the attack surface and likelihood of compromising the application's _Confidentiality_ and _Integrity_. A microservice application should rather be secured by _Following the Least Privilege Principle_, namely, by ensuring that each microservice can access only the least set of functionalities and data it needs. This would indeed help contain the effects of security attacks in which attackers obtain control of a microservice, e.g., by exploiting a software vulnerability. **Own Crypto Code**. Microservices should be developed by avoiding the use of _Own Crypto Code_, which may compromise an application's _Confidentiality_, _Integrity_, and _Authenticity_. The use of _Own Crypto Code_ may produce a false sense of security, which may be even worse than not using any encryption solution. When the _Own Crypto Code_ smell occurs, the affected microservices should be refactored by _Using Established Encryption Technologies_, namely, by replacing the own crypto code with security technologies/libraries that have already been thoroughly tested. **Non-Encrypted Data Exposure**. Microservice applications may accidentally expose sensitive data, e.g., since no encryption was used when storing them or because of security vulnerabilities in the employed protection mechanisms. The _Confidentiality_ and _Integrity_ of the exposed data can thus be compromised, e.g., since an attacker could acquire or modify the exposed data by obtaining unauthorised access to the application. For this reason, the recommended refactoring is to _Encrypt All Sensitive Data at Rest_, with \"data at rest\" intended as structured/unstructured data stored in digital form (e.g., cloud storage [1]), and to decrypt such data only when it is used. Data encryption can be performed by database-management systems or by the operating system at the disk level, and it should also be applied to cached sensitive data. **Hardcoded Secrets**.