Source-linked AI summary
Exploiting and Securing Docker containers and Kubernetes pods from a MitM attack
Henry Kabuye, Ismail Khalid Kazmi, Chunyan Mu, Paolo Modesti
TL;DR
The paper addresses how containerised operating systems can be protected from MitM attacks, including risk associated with a Kubernetes endpoint-routing vulnerability. It combines a systematic review with a Java cryptographic security mechanism, and reports implementing a mechanism in a containerised scenario. The proposed design uses AnBxJ and connection-queue features to address malicious connections.
Problem
The study addresses MitM risk in containerised systems, including Kubernetes CVE-2021-25737, which permits pod traffic rerouting to private Node networks.
Source: A. Rationale of the Study · p. 3, A. The ”Man-in-The-Middle (MiTM)” attack · p. 8Method
The study combines a PRISMA-based systematic review with a Java security mechanism based on AnB models and cryptographic primitives.
Source: §I · p. 2, §III · p. 3, §VII · p. 8Results
The paper reports that a security mechanism was implemented for containerised systems and describes multi-listener and connection-queue features for proactively eliminating malicious connections.
Source: §I · p. 2, D. Mitigation · p. 10, §IX · p. 10Takeaways & Limitations
The proposed mechanism uses AnBxJ and connection-queue features to address malicious connections and endpoint addresses associated with CVE-2021-25737.
Source: D. Mitigation · p. 10The authors identify future work on security firewalls for concurrency designs using AnB notation and machine-learning algorithms to detect and classify anomalies.
Source: §IX · pp. 10–11
Abstract
from arXiv · showhide
PURPOSE - Workloads in containers, such as Docker containers and Kubernetes pods, are vulnerable to many of the same attacks as workloads in non-container environments, including phishing, application exploits and network intrusions. This systematic review and design-and-creation study explores techniques for securing containerised-based operating systems against Man-in-the-Middle (MitM) attacks. The proposed framework uses a conceptual model for representing communication and cryptographic primitives, together with the AnBxJ Java security library and container firewalls operating at layer 7 of the OSI model. The study addresses the question: How can containerised-based operating systems be effectively secured from Man-in-the-Middle attacks? It aims to support practitioners in protecting Docker and Kubernetes deployments by systematising security practices and applying a zero trust architecture. METHODOLOGY - The research uses a Systematic Review (SR) based on the Preferred Reporting Items for Systematic Reviews and Meta-Analyses (PRISMA), bringing together evidence from studies addressing the same research topic. FINDINGS - Success factors were identified, and a security mechanism was successfully implemented in a containerised-based operating system scenario. VALUE - The findings may help practitioners protect Kubernetes and Docker installations by systematising container security practices and providing a zero trust architecture for containerised-based operating systems.
I. INTRODUCTION
The introduction frames container security as protecting Docker and Kubernetes workloads from MitM attacks. It proposes a cryptographic Java security mechanism and layer-7 firewall, motivated in part by a Kubernetes endpoint-routing vulnerability.
I. INTRODUCTION
- The proposed AnBxJ Java security library provides cryptographic primitives and a communication API, with AnB models supporting verification and automatic Java implementation.The introduction reports that the mechanism was deployed in a containerised platform scenario to mitigate MitM attacks.Source: §I · p. 2
- The introduction presents zero trust as protecting resources without granting implicit trust and identifies cryptography as critical for secure container communication authentication.The proposed mechanism uses cryptographic primitives in its communication API.Source: §I · p. 2
- The proposed layer-7 firewall uses a Java security library to inspect packet contents for malware or other cyber threats, rather than filtering by IP address.The architecture is set up on a VMware vSphere virtual laboratory platform.Source: §I · p. 3
- The study asks how containerised operating systems can be secured effectively against MitM exploitation.It describes Kubernetes as an open-source system for deployment, scaling, and administration of container applications.Source: §I · pp. 2–3
A. Rationale of the Study
- CVE-2021-25737 permits pod traffic to be rerouted to private Node networks, and exposing an external IP to reach a cluster application may increase MitM risk.The passage notes Kubernetes already blocks localhost and link-local endpoint IPs, but the same check was not applied to Endpoint Slice IPs.Source: A. Rationale of the Study · p. 3
B. Technical Objectives
The paper aims to secure Docker containers and Kubernetes pods, including database traffic and authorized access. Its objectives address cost and mechanism testing, while the reviewed literature discusses container use, vulnerabilities, and security context.
B. Technical Objectives
- The technical objective is to secure traffic between databases and web applications so only authorised applications and users can access databases.The stated architecture targets Docker containers and Kubernetes pods against MitM exploitation.Source: B. Technical Objectives · p. 3
C. Financial Objectives
- The paper identifies the cost of cloud security features as a concern for securing Docker and Kubernetes environments.It states that possible solutions to these cost issues are addressed in the article.Source: C. Financial Objectives · p. 3
D. Other objectives
- The other objectives are to assess exploitability, identify protective mechanisms, develop a MitM-protection mechanism, and test its effectiveness.Source: D. Other objectives · p. 3
II. REVIEW OF LITERATURE
- The reviewed literature connects container use to DevOps workflows and rolling updates, and reports vulnerabilities in container components and host-kernel image packages.The review also notes that improper cipher suites are associated with SDN and TLS misconfigurations.Source: §II · p. 3
III. METHODS
The methods use a PRISMA-based systematic review, with independent screening, data extraction, and bias assessment. The search and selection process focuses on container security and MitM attacks across specified databases and PIO-guided questions.
III. METHODS
- The study uses a PRISMA-based Systematic Review to compile evidence-based reviews on the same topic, and the author independently screened papers, extracted data, and assessed bias.Source: §III · pp. 3–4
A. Eligibility Criteria
- Eligibility was limited to English-language publications from 2018 to 2022.Source: A. Eligibility Criteria · p. 4
B. Information Sources
- The information sources were the IEEE, ACM, and Scopus databases.Source: B. Information Sources · p. 4
C. Search Strategy
- The search used Boolean operators with the terms “docker” OR “kubernetes” OR contain* AND secur*.Source: C. Search Strategy · p. 4
D. Selection Process
- Selection was guided by four concepts—Docker containers, Kubernetes pods, container security, and MitM attacks—and by questions covering publications, peer review, CIA principles, and MitM protection.The process used the PIO element to structure the search strategy; Table I is identified as presenting that element.Source: D. Selection Process · p. 4, Table I · p. 4
E. Data Collection process
Data collection is described as searches of ACM, IEEE, and Scopus, with the collected information tabulated by database.
E. Data Collection process
- Data collection drew on detailed searches of ACM, IEEE, and Scopus, with results organized in database-specific tables.The supplied table passages identify the ACM and IEEE tables; the text also names a Scopus table.Source: E. Data Collection process · p. 4, Table II · p. 4, Table III · p. 5
F. Data Items
The review describes a four-phase process, from defining the security challenge through deploying an automated Java security-library scenario. Its study-selection process narrowed searches across three databases to seven relevant articles.
F. Data Items
- The four data-item phases define the problem, gather information, analyse it, and produce a deployable system, following Foroughi and Luksch.The production phase is demonstrated by deploying a Java security library to detect and provide cryptographic primitives automatically.Source: F. Data Items · p. 5
A. Study Selection related to Inclusion and Exclusion criteria
- The Scopus table is identified as part of the study-selection material, alongside the reported database search and filtering results.The supplied passage identifies it as Table IV but gives no table contents.Source: Table IV · p. 5
- ACM, IEEE, and Scopus searches were limited by English-language publication from 2018 to 2022, peer review, and title, abstract, and author keywords.The MitM search terms were then applied to identify relevant articles.Source: A. Study Selection related to… · pp. 5–6
- Seven articles remained relevant to the MitM research question after filtering searches across ACM, IEEE, and Scopus.The final database ratio was 1:5:1, respectively.Source: A. Study Selection related to… · p. 6
B. Results of Syntheses
The synthesis organizes the included studies using PIO and tabulates their characteristics across seven result tables. The review identifies six fields for those tables.
B. Results of Syntheses
- The PIO synthesis is presented as a basis for interpreting the review conclusions and as a review output in its own right.It is tabulated in Tables VI–XII.Source: B. Results of Syntheses · p. 6
- The synthesis tables screen studies across six fields: author, framework tools, assessment tools, baseline operating system, vulnerabilities tested, and mitigation techniques.The review identifies Tables VI–XII as outputs of the PIO synthesis.Source: B. Results of Syntheses · p. 6
- Tables VI, VII, and VIII are identified as the first three results of synthesis; the supplied passages do not report their cell contents.The other named synthesis tables are IX, X, XI, and XII.Source: Table VI · p. 6, Table VII · p. 6, Table VIII · p. 6
V. DISCUSSION
The discussion reviews seven studies and evaluates their approaches using real data and SWOT analysis. It identifies gaps in concurrency-oriented designs and protection of container images.
V. DISCUSSION
- The discussion synthesizes seven studies on security mechanisms for protecting containerised operating systems from MitM attacks.It compares the studied techniques and results using real data.Source: §V · p. 7, A. Evaluation of data-sets · p. 7
A. Evaluation of data-sets
- The evaluation groups studies as theoretical, practical, or machine-learning/artificial-intelligence approaches.Table XIII presents the approaches by publication author.Source: A. Evaluation of data-sets · p. 7, Table XIII · p. 7
B. Analysis of the data-sets
- SWOT analysis found that searched studies lacked concurrency security designs and solutions embedding machine learning for vulnerability detection and classification.The review notes that such algorithms could create training sets for detected and classified vulnerabilities.Source: B. Analysis of the data-sets · p. 7
- The reviewed mechanisms detect cyber-attacks and support application confidentiality and integrity, but ignore the underlying container image.The review cites a 2019 report of maliciously used DockerHub images and identifies anomaly detection as an opportunity.Source: B. Analysis of the data-sets · p. 7
- The review says mechanisms focused outside container applications leave the inside unaddressed, increasing exposure to attacks such as MitM.Source: B. Analysis of the data-sets · p. 8
VI. THE THREAT MODEL
The threat model describes MitM interception and modification, including a Kubernetes pod-traffic vulnerability, and depicts communication between separate master and worker containers. The assessment uses OpenVAS to examine the vulnerability.
A. The ”Man-in-The-Middle (MiTM)” attack.
- The threat model characterizes MitM as interception and modification of communication between a sender and receiver who believe they are communicating securely.The attacker can alter communications so they reach the attacker's intended target.Source: A. The ”Man-in-The-Middle (MiTM)” attack · p. 8
- CVE-2021-25737 allows pod traffic to be rerouted to private networks on a Node; Kubernetes blocks localhost and link-local endpoint IPs but the cited issue concerns Endpoint Slice IPs.The text links disclosure of an external IP address for cluster-application access with greater likelihood of MitM attack.Source: A. The ”Man-in-The-Middle (MiTM)” attack · p. 8
- The MitM scenario is represented as an attack tree and places AnBxJ cryptographic primitives between master node 10.1.16.13 and worker node 10.1.16.14.The nodes are configured in separate containers and separate Linux-based operating systems.Source: A. The ”Man-in-The-Middle (MiTM)” attack · p. 8, Figure 1 · p. 8
B. Vulnerability Assessment
- Kubernetes' master node manages the cluster; etcd, kube-scheduler, kube-apiserver, and kube-controller are identified as its four essential components.The architecture is shown in Figure 2.Source: B. Vulnerability Assessment · p. 8, Figure 2 · p. 8
- OpenVAS, an open-source vulnerability scanner, was used to assess the severity of CVE-2021-25737 in Kubernetes pods.The study describes its assessment as an initial analysis of the vulnerability's presence.Source: B. Vulnerability Assessment · p. 8
VII. PROPOSED SECURITY MODEL AND DESIGN
The proposed security design uses AnB to create abstract and concrete models for formal verification and automatic Java implementation. Its implementation applies AnBxJ to secure communication between master and worker nodes.
VII. PROPOSED SECURITY MODEL AND DESIGN
- AnB provides abstract and concrete models for formal verification and automatic Java implementation in the proposed security design.The architecture embeds concurrent Java programs with containerised programs running parallel independent processes.Source: §VII · p. 8
VIII. IMPLEMENTATION AND EVALUATION
- The sample implementation uses three vSphere virtual machines: two Ubuntu 18.04.6 nodes and one Kali Linux machine.Both Ubuntu nodes run Docker 20.10.7 and Kubernetes tools; one acts as master and the other as worker.Source: §VIII · p. 9
- AnBxJ safeguarded communication between the master and worker nodes, with compiled metadata used to study AnB security goals.Figure 3 depicts the abstract and concrete model.Source: §VIII · p. 9, Figure 3 · p. 9
VII. PROPOSED SECURITY MODEL AND DESIGN
- Figure 5 presents the proposed secure Docker architecture embedded with the AnBxJ security library.The framework and toolkit workflow is also shown in Figure 4.Source: Figure 5 · p. 9, Figure 4 · p. 9
A. Connection-Queue
The implementation authenticates connections and limits the master node to configured listeners. The EndpointSlices assessment found MitM attack severity to be high, and the proposed mitigation uses Java cryptographic primitives and connection controls to address CVE-2021-25737.
A. Connection-Queue
- The Java code accepts connections during authentication, closes unauthorized or completed sessions, and gives both nodes private keys.Source: A. Connection-Queue · p. 9
B. Multi-listener
- The master node listens only for connections configured in the .PROPERTIES file, using port 6631 as the safe channel.Figure 6 shows the master node waiting for clients.Source: B. Multi-listener · p. 9, Figure 6 · p. 10
C. Detection
- MitM attack severity was shown as high on the EndpointSlices list.The assessment examined metadata flow for endpoint addresses to check for exploitation of CVE-2021-25737 using OpenVAS.Source: C. Detection · pp. 9–10
D. Mitigation
- The proposed Java mechanism uses JCA cryptographic primitives and AnBxJ multi-listener and connection-queue features to proactively eliminate malicious connections targeting CVE-2021-25737.The cited alternative admission-webhook mitigation requires policy establishment and may require upgrading kube-apiserver.Source: D. Mitigation · p. 10
IX. FUTURE WORK AND CONCLUSION
The conclusion presents a systematic review and a Java security mechanism based on AnB notation, while identifying Java security firewalls with concurrency designs and machine learning as future work. The study's artefact was created in Teesside University's protected vSphere environment without additional human interaction.
IX. FUTURE WORK AND CONCLUSION
- The conclusion presents a systematic review of containerised operating-system security studies and a Java security mechanism based on AnB notation.The notation provides abstract and concrete models; the paper suggests further study of Java security firewalls with concurrency designs and machine-learning anomaly detection.Source: §IX · pp. 10–11
- The proposed future research direction is Java security firewalls using concurrency designs and machine learning to detect and classify container anomalies.Source: §IX · p. 11
X. ETHICAL STATEMENT
- The artefact was created on Teesside University's protected vSphere platform and required no additional human interaction.Source: §X · p. 11