| dc.description.abstract | The rapid increase in cloud usage among organizations has led to a shift in the cybersecurity
industry. Whereas before, organizations wanted traditional security monitoring using statically placed IDS sensors within their data centers and networks, they now want dynamic
security monitoring of their cloud solutions. As more and more organizations move their
infrastructure and applications to the cloud the need for cybersecurity solutions that can
adapt and transform to meet this new demand is increasing. Although many cloud providers,
provide integrated security solutions, these are dependent on the correct configuration from
the 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 looking
to move into IDS monitoring of cloud solutions, more specifically providing network IDS
monitoring of traffic within managed Kubernetes clusters at cloud providers, such as Amazon Web Services Elastic Kubernetes Service. This is to be accomplished by providing all
the desired pods within a cluster their own sidecar container, which acts as a network sniffer
that sends the recorded traffic through vxlan to an external sensor also operating in the
cloud. 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 monitoring
the 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 script
sniffing the localhost traffic of the shared network namespace of a Kubernetes pod. This
infrastructure 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 the
container level, through Prometheus and Grafana. Finally, a series of performance tests will
be conducted, using k6s and iperf, automated by Ansible, to gather the performance impact
of the sidecar container.
A series of iperf and k6s tests were conducted against the sidecar container. The k6s test
was run at a data rate of 3 Mb/s and showed that the data rate needed to be higher to
gather useful performance metrics. This is where iperf took over and tested the sidecar
container at data rates of 50,100,250 and 500 Mb/s using a server at the University of Agder
as base. These initial raw performance results showed a max CPU usage of 11.8% of the
Kubernetes node’s 2 vCPU’s. Together with a max memory usage of 14 MB this showed
that the sidecar container does not consume a vast amount of resources. And has the
potential as a scalable and efficient network tapping method in Kubernetes. However, some
anomalies were discovered during the performance testing that revealed undiscovered issues
with the method. One of which was packet anomalies between the number of packets at the
sensor 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 considering
alternative transport methods to vxlan. | |
