# KubeHound: Detecting Microservices' Security Smells in Kubernetes Deployments
## 4 Detecting Security Smells in Kubernetes-Based Microservices
### Publicly Accessible Microservices  
We consider three different instances of the _Publicly Accessible Microservices_ smell, for which we hereafter introduce three different detection techniques. The techniques are distinguished based on whether they detect smell instances by statically analysing the Kubernetes configuration files or by dynamically interacting with a running Kubernetes deployment. Extra care has to be taken in this case, as some services could be intentionally exposed by application developers, e.g., API gateways. The actual implementation of the introduced analyses should therefore enable developers to specify this information to filter out intentionally exposed services.  
**Exposed Kubernetes Services Using Service Type**. This technique enables the detection of an instance of the _Publicly Accessible Microservices_ smell by statically analysing the configuration files specifying an application's deployment in Kubernetes. In particular, for each microservice in an application, the analysis statically checks whether its deployment configuration is set to be publicly accessible. Namely, the analysis checks whether the microservice is exposed through Kubernetes Service objects of type LoadBalancer and NodePort [26] or by using Ingress objects [27].  
**Exposed Kubernetes Services Using External-IP Field**. This technique enables the detection of an instance of the _Publicly Accessible Microservices_ smell by dynamically analysing the metadata assigned by Kubernetes to running microservices. Kubernetes indeed associates all running services with a Cluster-IP, that is, an IP address to reach the service from within the internal cluster network. Publicly exposed services are also assigned an External-IP address. This analysis hence retrieves the information about all services and whether they are assigned an External-IP in their metadata.  
Listing 1 gives an example of how this information can be retrieved using the command kubect1. The output in the figure shows the Kubernetes services running on the cluster, with two of them publicly accessible by external clients. While this may be intentional for the application's gateway, the same may not be the case for service2. The latter may indeed be an internal microservice whose misconfiguration resulted in unintentionally exposing it.  
```
1 Skubect1 getservices
2 NAMETYPECLUSTER-IPEXTERNAL-IPPORT(5) service1 ClusterIP10.128.129.2<none>80/TCP service2 NodePort10.128.61.47{RealIPhere}443/TCP gatewayNodePort10.128.61.46{RealIPhere}43/TCP
```  
**Listing 1**. Example of output returned by kubect1, simplified for readability reasons.  
**Exposed Kubernetes Services Using Port Scanning**. This technique enables the detection of an instance of the _Publicly Accessible Microservices_ smell dynamically. This is performed by running port scanning [28], a technique that allows probing a host in order to find services listening on specific ports. The industry-standard tool that implements this technique is Nmap [29], which can also enumerate the exposed services, e.g., by returning the name of the running service. Other existing security-analysis tools, e.g., Kube-hunter [17], also perform port-scanning techniques to search for exposed services.