# KubeHound: Detecting Microservices' Security Smells in Kubernetes Deployments
## 2 Background
This smell occurs when secrets (e.g., API keys, client secrets, or long-term credentials) are hardcoded in the microservices' source code or deployment scripts. Secrets should also not be stored in environment variables, because logging platforms might accidentally expose them by dumping the environment. This could lead to _Confidentiality_ and _Integrity_ violations of the stored secrets. The suggested refactoring is to _Encrypt Secrets at Rest_ by allowing only authorised services to access their corresponding secrets. This includes never storing credentials alongside applications, as well as avoiding passing secrets to a microservice by setting environment variables of its hosting container. **Non-Secured Service-to-Service Communications**. Even if running in the same internal network, microservices should establish secure communication channels to interact with each other. When this is not the case, we have _Non-Secured Service-to-Service Communications_, which may compromise an application's _Confidentiality_, _Integrity_, and _Authenticity_. Indeed, when service communications are not secured, attackers can perform man-in-the-middle, eavesdropping, and/or tampering attacks on such communications. Development teams should rather follow a \"zero-trust\" approach by applying the _Use Mutual TLS_ refactoring. Mutual TLS is a well-known method to secure service-to-service communications that creates a secure communication channel that features data encryption and mutual authentication, hence preventing, e.g., man-in-the-middle attacks. **Unauthenticated Traffic**. This smell occurs when a microservice receives unauthenticated requests from external clients or other microservices of the same application. This may result in violating the application's _Authenticity_, since there is no guarantee that the exchanged data are trusted and have not been modified. The suggested refactoring is to _Use Mutual TLS_ (described earlier) and to _Use OpenID Connect_, an identity layer built on top of OAuth 2.0. **Multiple User Authentication** This smell occurs on microservice applications authenticating users through multiple different access points. Each access point can be exploited by intruders to authenticate as end-users, thus violating the _Authenticity_ of the application. The suggested refactoring is to _Use Single Sign-On_, namely, a single entry point to handle user authentication. The single sign-on can be realised by also implementing the _Add an API Gateway_ and _Use OpenID Connect_ refactorings discussed earlier. **Centralised Authorisation** This smell occurs when authorisation is handled by only one application component. This may result in violating the _Authenticity_ of the application, since compromising such a component could lead to an attacker having full access to the application. A fine-grained, microservice-level authorisation control should rather be enforced. For this reason, the suggested refactoring is to _Use Decentralised Authorisation_ by relying on access tokens (e.g., JSON Web Tokens) transmitted with each request. Tokens indeed provide a mechanism to pass digitally signed user claims or data, which enables the enactment of access control at the microservice level.