Tapping network traffic in Kubernetes
Master thesis
Permanent lenke
https://hdl.handle.net/11250/3086709Utgivelsesdato
2023Metadata
Vis full innførselSamlinger
Sammendrag
The rapid increase in cloud usage among organizations has led to a shift in the cybersecurityindustry. Whereas before, organizations wanted traditional security monitoring using statically placed IDS sensors within their data centers and networks, they now want dynamicsecurity monitoring of their cloud solutions. As more and more organizations move theirinfrastructure and applications to the cloud the need for cybersecurity solutions that canadapt and transform to meet this new demand is increasing. Although many cloud providers,provide integrated security solutions, these are dependent on the correct configuration fromthe customers, which may rather want to pay a security firm instead. Telenor Security Operation Center is a long contender in the traditional cybersecurity firm space and is lookingto move into IDS monitoring of cloud solutions, more specifically providing network IDSmonitoring of traffic within managed Kubernetes clusters at cloud providers, such as Amazon Web Services Elastic Kubernetes Service. This is to be accomplished by providing allthe desired pods within a cluster their own sidecar container, which acts as a network snifferthat sends the recorded traffic through vxlan to an external sensor also operating in thecloud. By doing this, traditional IDS monitoring suddenly becomes available in the cloud,and is covering a part that is often neglected in cloud environments, and that is monitoringthe internal Kubernetes cluster traffic.
AWS EKS was used as a testing ground for a simulated Kubernetes cluster running sample applications monitored by the sidecar container. Which is essentially a Python scriptsniffing the localhost traffic of the shared network namespace of a Kubernetes pod. Thisinfrastructure will be generated by a set of Terraform files for automated setup and reproducibility, as well as making use of the gitops tool Fluxcd for syncing Kubernetes manifests.The solution will also be monitored by a complete monitoring solution in the form of kube-prometheus-stack which will provide complete insight into performance metrics down at thecontainer level, through Prometheus and Grafana. Finally, a series of performance tests willbe conducted, using k6s and iperf, automated by Ansible, to gather the performance impactof the sidecar container.
A series of iperf and k6s tests were conducted against the sidecar container. The k6s testwas run at a data rate of 3 Mb/s and showed that the data rate needed to be higher togather useful performance metrics. This is where iperf took over and tested the sidecarcontainer at data rates of 50,100,250 and 500 Mb/s using a server at the University of Agderas base. These initial raw performance results showed a max CPU usage of 11.8% of theKubernetes node’s 2 vCPU’s. Together with a max memory usage of 14 MB this showedthat the sidecar container does not consume a vast amount of resources. And has thepotential as a scalable and efficient network tapping method in Kubernetes. However, someanomalies were discovered during the performance testing that revealed undiscovered issueswith the method. One of which was packet anomalies between the number of packets at thesensor and the number of packets observed by the iperf server at the University of Agder.Due to the many layers involved in the networking stack for this method, there needs to be conducted additional research into how these anomalies arise. While also consideringalternative transport methods to vxlan.