Multimedia Tools and Applications

https://doi.org/10.1007/s11042-024-19613-x

Secure container Orchestration: A framework for detecting

and mitigating Orchestrator ‑ level vulnerabilities

V. Mahavaishnavi1 · R. Saminathan1,2 · R. Prithviraj1,3

Received: 8 November 2023 / Revised: 24 April 2024 / Accepted: 6 June 2024

© The Author(s), under exclusive licence to Springer Science+Business Media, LLC, part of Springer Nature 2024

Abstract
This paper presents Secure Orchestration, a novel framework meticulously planned to
uphold rigorous security measures over the profound security concerns that lie within the
container orchestration platforms, especially in Kubernetes. The widespread adoption of
containerized environments has raised concerns about the vulnerabilities at the level of the
orchestrator. Secure Orchestration delivers a comprehensive approach by leveraging cut-
ting-edge methods to detect and prevent the exposure of vulnerabilities from orchestrator
misconfigurations, privilege escalation exploits that can thwart the orchestration security
layer, and unauthorized access attempts targeting the orchestration system itself. In addi-
tion, it is further strengthened by deploying an Intrusion Detection and Prevention System
(IDPS), which is responsible for actively monitoring the orchestration infrastructure. The
IDPS utilizes sophisticated algorithms and mechanisms for detecting anomalies to continu-
ously assess the orchestration environment for indications of intrusion, vulnerabilities, and
anomalous activities. By using this proactive approach, the framework is able to rapidly
identify potential threats and respond through countermeasures in a timely manner, thus
greatly reducing the risks associated with orchestrator level vulnerabilities. Conducting a
set of real-world experiments that closely simulate a variety of threat scenarios is imper-
ative for empirically validating the efficiency of this framework. The obtained empirical
results yield insightful revelations on the efficacy of the framework in accurately identify-
ing and mitigating vulnerabilities, thereby ensuring the privacy and integrity of container
orchestration systems.

Keywords Container Security · Orchestration process · KVM · Kubernetes

* V. Mahavaishnavi
mahavaishavi8@gmail.com
1
Assistant Professor, Department of Artificial Intelligence and Data Science, Panimalar Engineering
College, Chennai, Tamil Nadu 600123, India
2
Associate Professor, Department of Computer Science and Engineering, Annamalai University,
Chidambaram, India
3
Research Scholar, Department of Computer Science and Engineering, Annamalai University,
Chidambaram, India

13
Vol.:(0123456789)
 Multimedia Tools and Applications

1 Introduction

The management of container installation, scaling, and maintenance in a safe manner

is known as secure container orchestration. Applications and their dependencies can be
distributed and packaged in lightweight, portable containers. Automating and managing
containerized applications is made possible by container orchestration technologies like
Kubernetes, Docker Swarm, and Amazon ECS. Protecting sensitive data, preventing unau-
thorized access, and preserving the integrity of programmes depend on the reliability of
these environments.
The current value of the global container security market, which reached over $1.3 bil-
lion in 2021, is expected to grow to over $3.6 billion by the end of 2026, with a CAGR of
22.0% over the period of forecasting [1]. The expansion of the container security sector is
fueled by the adoption of micro services, enterprise-wide digitization, and an increase in
east-west traffic in container-based data centers.
Micro services are most frequently used by businesses implementing DevOps
approaches. Containers are of great importance to enterprise developers using the 12-fac-
tor app methodology. Utilizing Application Programming Interfaces (APIs), application
elements are individually conceived, created, and incorporated in a software architecture
known as a micro service. Micro services are frequently developed and deployed using
containers to the point that the two technologies almost work in harmony [2, 5]. Enterprise
IT rules are created using containers, micro services, and business objectives. The opera-
tional performance of the organization determines whether these IT policies are successful
or unsuccessful, so eventually the implementation of containers and micro services will
grow into a key point of concern [6].
The ability to put more software on a single machine through containers has enabled
businesses to create portable software. Images of containers can be moved from one
machine to another and are simple to deploy [8]. These are now a crucial piece of technol-
ogy for enabling micro services. The advantage of container technology is that it speeds
up the process of developing and deploying applications, allowing for quick and simple
security updates, upgrades, and vulnerability patching. Without altering the application’s
original essence, the entire process is feasible. However, because containers make appli-
cation deployment quicker, there is also a higher risk of failure [9–11]. Containers house
valuable data, making them more vulnerable in addition to isolating the data. Due to the
deployment’s rapid pace, testing and quality control are frequently neglected. Therefore, it
is up to the organizations to perform the manual testing process and to guarantee that they
are only utilizing the most current versions of the containers.
At the same time the Internet of Things (IoT) first appeared on the technology scene,
containers also started to gain popularity. IoT and containers have developed close ties,
and models for both of them have been available on the market for a while. IoT has
many important applications, some of which require containerizations due to their enor-
mous scale and high data reliance. IoT applications need to have the ability to scale
much beyond the capabilities of typical apps if they are to gather, store, and analyze
thousands of petabytes of data. Micro services are used by containers to easily scale IoT
data. Additionally, containers have the natural ability to run programmes on IoT edge
devices that primarily support the lightweight OS and have fewer resources. The IoT
market is enormous, and by 2023, many connected devices are anticipated to be in use.
Containers would be necessary for the front-end and back-end software on these devices
to function quickly and smoothly [35]. Additionally, because the majority of IoT apps

13
Multimedia Tools and Applications

are brand-new, it is anticipated that they will be created using the most recent container
technology. Because regular software upgrades of distinct, distributed IoT devices’
segregated micro services are made possible by containers, the need for containers in
the IoT space is expected to rise as well. The need for container security systems is
anticipated to increase in the upcoming years due to the growing adoption of containers
among different sectors in the IoT area [35].
The uses for biotechnology, medical, pharmaceutical, and medical device businesses are
included in the healthcare industry. In order to help IT, DevOps, and health teams build
apps fast and securely in a cloud that complies with HIPAA, container security is being
used by businesses more and more. In addition, businesses are able to integrate their sys-
tems with other medical networks so that they may exchange information and coordinate
their efforts to support expansion and boost agility. Complexity abounds in healthcare apps.
These applications are made up of services that deal with particular tasks, such as process-
ing records for patients, transferring files, document export, and communications. With the
help of containerizing services, moving complicated systems that manage Protected Health
Information (PHI) is made much simpler. Because of this, container security is crucial in
the healthcare industry. Recent years have seen a massive increase of data in the healthcare
sector. The emergence of container services is changing how healthcare applications are
deployed as well as how information is gathered and disseminated. The healthcare sector
is increasingly more concerned with value generation than quantity. Organizations in the
public and private healthcare sectors are under pressure to boost population health while
cutting costs.
Some of the research questions addressed in this paper includes

• In what way could the framework be optimized reducing overhead at the same time as
maintaining robust security monitoring?
• Which techniques could be applied to scale up the framework for large scale orchestra-
tion environments?
• Are there any fresh ideas that could be tested out to handle zero-day vulnerabilities and
insider threats inside the orchestration system?
• How could machine learning and artificial intelligence techniques be combined into the
framework to enhance threat analyst capabilities and security against advanced attacks?

1.1 Terminologies

1.1.1 Kubernetes

In order to automate the deployment, scale, and maintenance of containerized applications,

Google created the open source project known as Kubernetes. This project was established
as a result of Google’s ten-year experience using containers in production. In a production
setting, only container technologies are used by Google [2][3]. It serves as an orchestrator
that, in contrast to other tools, kubernetes supports a variety of container solutions (such
as Docker, rkt, crio-o, and Windows containers). It is also flexible and a variety of exten-
sions are available. Two fundamental roles make up Kubernetes: the master and the node
(previously referred to as the minion). Every node in the group is primarily managed by the
master. These nodes carry out tasks assigned to them by the master and accept its demands.
Three fundamental parts are used for container initialization and management:

13
 Multimedia Tools and Applications

• Pod, a location and collection point for containers (e.g., a single pod can hold an entire
application).
• Replication controller that acts as the pod’s supervisor and keeps track of the wellbeing
of the cluster.
• Each pod contains a kubelet that manages and supervises the containers running on
Kubernetes.

1.2 Docker compose

The Docker Corporation offers Docker Compose as a solution that works with multicon-
tainer Docker applications [4]. This approach is built on a configuration yml document,
which defines the connections and specifics of a container (such as image, volumes, service
configurations, etc.). The project’s benefits include legibility and purity of construction, as
well as ease of execution. The lack of sophisticated features (high availability, distribution,
etc.) and the fact that it offers fewer functionality than other projects are disadvantages.
Docker Compose is best suited for developers rather than for complex infrastructures.

1.3 Docker Swarm

Originally a Docker Swarm add-on, the capability has been incorporated into the same
package from Docker 1.12 [4]. Kubernetes’ design and functionalities are currently fairly
comparable. The main benefit is native support for Compose configuration less. Other fea-
tures include rolling updates, decentralized design, multi-host networking, load balancing,
and so on. This is an improved method that is comparable to other orchestrators in contrast
to Compose. Numerous functions are included as standard. Compared to the environment
and community that surround Kubernetes, its potential is currently constrained. Swarm
technology is deployable and useful in small production contexts, ideal for tiny clusters,
and offers a simple administration system. Scalability and only supporting Docker contain-
ers are some of the Swarm orchestrator’s drawbacks.

1.4 Fleet

The CoreOS firm offers Project Fleet, a system-based solution [5]. Fleet uses systems to
manage clusters and manage processes. The authors advise against using this project on
over 100 servers with 1000 services due to its restricted utilisation for large infrastructures,
which is a benefit of the project’s simplicity in working with clusters. Since February 2017,
development on this project has been halted, and CoreOS has started utilising Kubernetes.

1.5 Apache mesos

The distributed clusters project is called Apache Mesos [6]. Mesos is unique from other
solutions in that it is not just for containers. It is an open source programme made up of
Apache Foundation projects (including Hadoop and Zookeeper). Marathon, an Apache
Mesos project component, offers container orchestration. The primary distinction between
Swarm and Kubernetes is a two-level scheduler which operates on the first layer integrat-
ing sources using various label types. They can be distinguished from one another and
connected to the group using various hardware hardware tips. Mesos allocates resources

13
Multimedia Tools and Applications

among source frameworks and frameworks running the technology on the second tier of
the scheduler. The containers are run using the Marathon framework. This orchestrator is
utilised for Big Data issues and is frequently likened with the freely available cloud com-
puting system OpenStack. Vulnerabilities at the orchestrator level are security gaps and
errors that can be found in platforms for container orchestration. Malicious actors may use
these flaws as a means of compromising the security and integrity of containerized apps
and the supporting infrastructure. Strong tools for handling and deploying containers at
scale are provided by container orchestrators like Kubernetes, Docker Swarm, and Apache
Mesos. However, because of their complexity, these orchestrators also increase the poten-
tial for additional vulnerabilities and attack vectors.
Protecting containerized environments is the goal of container security because they
are far more difficult than conventional workloads. The number of containers deployed
in production systems is enormous. In a containerized system as opposed to a traditional
deployment, security professionals and administrators have to safeguard more components.
Although containers provide numerous benefits, they also present some security issues
that may prove difficult to resolve. The increased attack surface that containers create com-
pared with conventional workloads is probably the most obvious security concern. This
is because there are so many containers, each of which is built on an array of potentially
vulnerable underlying images. The kernel architecture that underlies containers is another
important problem. To guarantee protection, protecting the host is insufficient. To restrict
container rights and guarantee correct isolation across containers, you must also maintain
secure configurations. Containerized environments are quite dynamic, and containerized
workloads have visibility issues as well. This is due to the possibility that conventional
monitoring tools may be unable to determine which containers are active, what they are
doing, or how their networks behave. Enhancing visibility as much as feasible is essential
to ensuring prompt correction and avoiding breaches.
The contributions of this paper are as follows:

• It presents a new, ground-breaking framework created especially to overcome flaws in

platforms for container orchestration’s orchestrator.
• For defending container orchestration settings against potential attacks and vulnerabili-
ties, it suggests a thorough set of security procedures and tactics.

The remaining portions of the paper is divided into the following sections: In Section II,
a literature survey of recently methods is covered. In Section III, orchestrators and orches-
trator level vulnerabilities are discussed. In Section IV, the proposed secure container
orchestration framework is discussed. In Section V, the experimental setup of the work
is discussed. In Section VI, the results and discussion of the proposed work is explained.
Finally in Section VII, the conclusion is mentioned.

2 Related work

A process for choosing security and privacy controls to safeguard organizational activities
is provided by the National Institute of Standards and Technology (NIST) in addition to a
catalog of 224 security and privacy measures for federal information systems and organiza-
tions [7, 8]. The following controls are included: access controls, auditing and accountabil-
ity, security evaluation and approval, identity and verification, incident response, employee

13
 Multimedia Tools and Applications

safety, risk evaluation, system and communications safety, and system and data integrity,
among others. With regard to security controls and security control evaluation, NIST’s
Open Security Controls evaluation Language (OSCAL) is trying to tackle a number of
issues.
The security problems with OS-level virtualization and possible fixes have been cov-
ered by [9]. For a containerized context, an attack model is presented that causes privilege
escalation, unauthorized data access, control flow error, and denial of service. The func-
tionality of container-based operating systems (FreeBSD, Linux-VServer, OpenVZ, etc.)
is detailed, as well as its container management options. In-depth discussion is given on
the security needs for containerization, which include isolation of the file system, network,
and devices as well as. It identifies the pressing security issues that the container ecosystem
must address.
The shared host kernel used by containers might be a single point of breakdown leading
to system collapse. The author proposed a few mechanisms for safeguarding containerized
environments, including executing containers in Virtual Machines (VM), employing lim-
ited resources (processes aren’t running within containers as a root, allowing file-system
as only accessible by reading, etc.), employing separate Docker hosts in multi-tenancy
contexts, image labeling, preventing abandoned drivers, image origins (cryptographic sign-
ing), accurate and Reliable Dockerfiles, operating typical auditing, and handling incidents
(like Docker diff, logs, commit) [10]. Author has spoken about the risks to host and data
posed by poisoned images, container breakdowns (especially privilege escalation attacks),
kernel vulnerabilities, denial of service attacks, and compromised knowledge. Addition-
ally, a set of security measures is recommended for containerized environments, including
operating containers within a Virtual Machine (VM), employing minimal resources, and
employing distinct.
A study on the internal security of Docker and its Linux-based security features has
been presented in [11]. Attacks that cause a denial of service or privilege escalation are
explored, along with solutions such as isolating a process from its file system and device,
restricting network access and inter-process communication, and lastly defining resource
usage limitations. Analysis covers Linux components because Docker is built on the Linux
operating system. Due to the fact that SELinux and AppArmor are built-in to Linux, char-
acteristics of these security technologies are also highlighted.
Security flaws in the Docker Hub images have been discovered after studying them
[12]. To determine the impact level of Debian packages, OpenSSL, Ubuntu repositories,
etc., official images are analyzed. An increased number of susceptible images are found
when non-official Docker Hub images are analyzed. The flaws that lead to serious security
threats like escalated privileges and container leakage have been covered. The graphics
can be scanned, put into a virtual computer, and rebuilt from scratch as solutions. Regular
updates to official images are required to improve the security mechanism of the Docker
ecosystem by removing extraneous layers.
A model to identify harmful behavior within the Docker ecosystem has been presented
by [13]. The system call has been collected for analysis using a SQL injection attack. To
handle the active container’s contextual data and system calls, utilize the strace tool and
Docker introspection approach. It is possible to estimate the true positive and false posi-
tive rates of malicious detection techniques. The presented study can be used to implement
extra functionalities for an intrusion detection system, such as monitoring and alert crea-
tion for malicious container processes. A review of Docker’s features and security issues
has been provided [14]. According to the authors, network security, kernel security mod-
ules, and process isolation form the foundation of Docker security. Insecure local setup,

13
Multimedia Tools and Applications

malicious images, and lax local access control are some of the issues with Docker contain-
ers that have been addressed.
SANS ISC InfoSec provides instructions on how to record the process ID of a Docker
system operating on an Ubuntu virtual machine [15, 16]. Every active container is a pro-
cess with its own unique ID that can be recorded in RAM. The Volatility Foundation
Framework 2.4 is used to study the memory after taking a snapshot of it. The author has
described how to extract a virtual machine’s *.vmem image’s PID using Docker. In this
process, the multilayer filesystem and Linux mount files are examined, and it is advised to
operate the system as a privileged user. The explanation offered regarding the Docker plat-
form escape is described as being dirty "Copy on Write" and vDSO manipulation.
To strengthen security in a cloud system based on containers, have suggested a vul-
nerability assessment and risk identification approach [17]. To evaluate the risk feature
present in the container ecosystem, authors have concentrated on the analysis of the con-
tainer’s image vulnerability. The sort of attack and its base score are determined by analyz-
ing Docker images of NGINX, Tomcat, and Linux packages, among others. These results
are used to generate a risk factor, which is then scaled from 0 to 10. In order to operate
containers in safe mode and prevent attacks like privilege escalation, vulnerable pictures
should be evaluated before being downloaded into the host system.
A solution to thwart a Docker escape assault has been published that examines the
namespace and looks for suspicious activity [18]. By changing namespaces and making
changes to shared memories that expose virtual dynamic shared objects (vDSO), escape
assault is discussed. Malicious activity can be found using Docker introspection techniques
including obtaining metadata from Docker containers and namespace tags. To inspect
Docker container objects, meta-data collecting, status assessment, and response measures
are employed. It is also necessary to analyze Docker objects (images, storage, etc.) in order
to comprehend the attack strategy and security measures.
In a suggestion on application container security, NIST outlines the problems and offers
suggestions for solving them [19]. Five key levels of container technology risk are identi-
fied: image risk, registry risk, orchestrator risk, container risk, and host OS risk. The fol-
lowing recommendations are made to prevent attacks brought on by the exploitation of
these risks:
(a) use a host OS designed specifically for containers to reduce the size of the attack sur-
face; (b) employ various hosts for various types of containers; (d) adopt vulnerability man-
agement tools tailored specifically for containers; (e) utilize hardware-based countermeas-
ures; and (f) utilize execution defense tools that are familiar with containers. The security
of container technology has been explored in terms of five phases: the beginning phase, the
design and planning phase, the implementation phase, the management and upkeep phase,
and the elimination phase.
An investigative framework for a Docker container escape assault has been provided
[20]. The suggested ELK framework consists of three modules: logstash, a log routing and
handling engine, and a web-based visualization tool called "kibana." Elastic search is used
to extract documents from the store. If the kernel is weak or there is a problem with the
setup of a file, container escape may be successful. The segmentation of picture layer data
and ongoing system monitoring have been proposed as primary remedies for container
escape. The Dirty Copy onWrite method is a result of the Docker escape being integrated
in the Linux kernel. To produce logs recorded using the Kibana interface, an instance of
NGINX is set up. A DMLA architecture is provided that details the tracking, logging, and
alerting functionality for Docker Host and containers. In order to obtain the log files’ sys-
tem call traces, a vulnerable image (vDSO, which is accountable for container escape),

13
 Multimedia Tools and Applications

is run within the Docker environment for a case study. Additionally offering proof which
might be utilized in a suggested architecture are the Host OS file system and Docker intro-
spection techniques.
For forensic investigation, have created the scalable real-time forensic framework
SCARF [21]. Systems built on containers are utilized for low-cost module expansion and
data-parallel processing. The containerized environment is used to evaluate the metadata
parsing, file streaming, text, and feature extraction capabilities of forensic tools including
ExifTool, OpenNSFW, Bulk Extractor, and Tika. In order to automate the data operation
process, tools have been containerized utilizing Dockerfile. This study demonstrates that
Bulk Extractor’s performance and ExifTool’s scalability are both improved in the sug-
gested architecture. To assess the suggested model’s strength, a real-time analysis of the
container-specific assault is necessary.
In a container context, examined the attack parameters and suggested a defense for esca-
lating privileges attacks [22]. Information escape, DoS attacks, and other attacks are taken
into account when creating an attack dataset. A programme that executes within the con-
tainer uses an exploit to attack the Docker engine and vulnerable kernel. Researchers have
examined the security and defense mechanisms for escalating privilege attacks in relation
to containers, kernels, and CPUs. The container system’s ROOT privilege security con-
trols are managed by a defense system. The advantages and disadvantages of the suggested
model are also examined because it is effective for exploitation of ROOT access but has to
be strengthened to counteract exploitation at the kernel level.
Utilizing Docker APIs, suggested forensics solutions for the Docker platform [23]. Evi-
dence fluctuation, evidence credibility, cross-platform, and cross-host container forensics
difficulties have been discussed. Host OS has a Docker file system that offers informa-
tion on Docker objects (containers, networks, storage, and images), including read/write
layers, routing tables, network addresses, and other things. The Docker APIs include log
files, hostnames, and configuration file information for containers and images. A Docker
forensics architecture is suggested, whereby forensic agent modules acquire and save the
information that the investigator will review. Evidence gathering is carried out using the
"docker-py" library. A case study of an attack investigation employing the suggested para-
digm could be offered.
A thorough analysis of the vulnerability of the Docker ecosystem has been provided
[24]. The different facets of the containerized environment have been covered by the
authors, including a comparison with virtualization technologies, unikernel execution
models, supporting libraries, Linux containers, and dependencies. In relation to potential
assaults, the strengths and drawbacks of Docker containers are additionally highlighted. In
addition to Amazon ECS and Kubernetes orchestration, the usefulness of Docker Swarm is
also highlighted. A risk study is conducted on a number of Docker ecosystem components,
including malicious Dockerfiles, unsecured system setups, vulnerable Docker image dis-
persion, and vulnerable Linux kernels.
The National Vulnerability Database (NVD) contains information on container vulner-
abilities that can be categorized according to different severity levels using the Common
Vulnerability Scoring System (CVSS) [25]. Path traversal, Code injections, Unauthorized
modification, Bypassing authentication for users, Inadequate input validation, Deserializa-
tion of Untrusted Data, Data Processing Error, etc. are some more categories into which
these vulnerabilities can be further divided.
The standard methods of file recovery, file carving, and file system analysis have
been used in a study to obtain data from Docker containers for forensics purposes [26].
To extract environmental data, image and container introspection is done using Docker

13
Multimedia Tools and Applications

commands. The authors have concentrated on restoring corrupted or deleted files from the
Docker image layer. To obtain Docker-related data, including directories and image layer
configuration files, the host OS is inspected. To obtain the details of removed image layers,
Docker’s file system (AUFS, overlay2) is examined.
A model to identify transient files in Docker images has been proposed to prevent
file duplication [27]. To determine the Temporary File (TF) pattern, the build procedure
(FROM, COPY, RUN) for Dockerfiles and image layers is examined. Static analysis tech-
niques used to identify TF in Dockerfiles include state-dependence file comparison, syntax
analysis, and verification methods. The direct copy method, instruction fusion and outside
storage methods have all been offered by authors as ways to get rid of temporary files. As
there are thousands of image repositories on Docker Hub, this model’s manual inspection
process for examining the TF in Dockerfiles should be automated.
The research of a security flaw in Docker containers was published in [28, 29]. The
suggested methodology solely examines Debian packages of Docker Hub images. Vulner-
ability analysis is carried out using information from the Debian Security Bug Tracker and
the past data of the vulnerability database. To compare the database’s accessible attrib-
utes, data is extracted such as version name and number, distribution category (testing,
stable, old stable), and release date. The Ultimate Debian Database is also used to create
a bug report, which is checked according to the version requirements. Additional package
deployments of Docker images can be included to the intended research.
The author’s discussed the metrics for logging and alerting in the Docker ecosystem
[30]. The core building block of containerization, cluster nodes, apps, and micro services
have all been discussed by authors. To identify and fix operational problems, these units are
watched. The path of micro services, which is supported by a database server and HTTP
routing, mentions the need for an authentication server. A containerized environment that
also stores and analyzes the log files mentions alerting and visualization tools.
To examine the metadata associated with application containers at the orchestration
layer, Sysdig tool is also described [31]. To acquire the container data, log collection tools
and data introspection techniques are discussed. The design of Docker containers and secu-
rity issues have been covered [32]. Four kinds of Docker vulnerabilities are investigated:
file system isolation, process and communication, device and host resources, and network
and image transfer. The authors have described the security elements of Docker and the
kernel, such as the network structure, integrity protection, access control, security augmen-
tation mechanism, etc.

3 Orchestrator level vulnerabilities

For container orchestration, there are many options. Five of the most frequently utilised
applications were picked, and they are contrasted. In vast infrastructures, certain orchestra-
tors are suited for use as production orchestrators because of variances in their manageabil-
ity and attitude. For specific technologies, the orchestrator’s ability to handle the amount of
containers is critical. Following a few typical orchestrator-level vulnerabilities that should
be taken into account:

• Escalation of Privilege: Attackers may take advantage of flaws to obtain elevated

privileges within the orchestrator environment, giving them the potential to manage
resources, containers, and ultimately take complete command of the cluster.

13
 Multimedia Tools and Applications

• Insecure Presets and Settings: Basic configurations for orchestrators are frequently
provided, however they may not be safe for use in deployments for production. Vul-
nerabilities may result from incorrect settings or from relying too heavily on unsafe
defaults.
• Unauthorized Access: Unauthorized users being able to access and manipulate
orchestrator components due to improper authentication and authorization systems
might result in unauthorized actions and data exposures.
• API Security Flaws: When exposed APIs have not been properly secured, they may
turn into attack vectors. Unauthorized access, leakage of information, and some-
times execution of code remotely can result from API flaws.
• Network Vulnerabilities: The exposure of sensitive information or the ability for
attackers to tamper with communication among containers and nodes are both risks
associated with networking setup flaws.
• Escaping a Container: The security of the entire cluster could be jeopardized if an
attacker tries to breach a container and obtain access to the host system.
• Resource Depletion: Orchestrators control the resources used by containers, but
flaws might let attackers build resource-hungry containers that cause denial-of-ser-
vice problems.
• Image Vulnerabilities: Images, which are the building blocks of containers, can have
flaws (such as obsolete software or unpatched libraries) that an attacker can use to
their advantage.
• Secrets Leakage and Persistent Storage: Data leakage or unauthorized access to pri-
vate data might result from improperly secured storage and secret management.
• Across-the-Cluster Vulnerabilities: Managed node clusters are orchestrated. Multi-
ple node weaknesses may have wide-ranging effects and may jeopardize the entire
cluster.
• Zero-Day Vulnerabilities: Like all software, orchestrators could contain zero-day vul-
nerabilities which attackers could take advantage of once they were fixed.
• Component Vulnerabilities of Third Parties: Orchestrators depend on a number of
external components. The entire security of the orchestrator may be compromised by
flaws in these components.
• Supply-chain Assaults: It is possible for malicious malware to be loaded into images
when they are deployed, creating vulnerabilities in the container image supply chain.
Following their distribution and execution, these infected pictures may enable unau-
thorized access or data loss.
• Denial-of-Service (DoS) Attacks: By triggering resource depletion, interfering with
container scheduling, or changing network configurations, orchestrator flaws can be
used to perform denial-of-service attacks.
• Man-in-the-Middle Attacks: Attackers may be able to intercept and modify traffic in
orchestrator communications due to insufficient encryption or lax security procedures,
allowing them to extract sensitive data or incorporate harmful payloads.
• Inadequate Logging and Monitoring: Security breaches could go undiscovered in the
absence of adequate monitoring and logging. It can be difficult to recognize and coun-
teract an assault because attackers might take advantage of weaknesses and hide their
footprints.
• Vulnerabilities across the Entire Cluster: Vulnerabilities may be revealed by improp-
erly specified parameters at the cluster level. For instance, if a Kubernetes dashboard is
open and improper authentication is used, attackers may be able to take over the entire
cluster.

13
Multimedia Tools and Applications

• Lateral Movement: After gaining access to one area of the orchestrator, an attacker can
try to migrate laterally through the environment to elevate their privileges and obtain
access to more vital areas.
• Compatible Orchestrator Versions: If orchestrator updates and patches are not correctly
managed, they may cause compatibility problems with already-installed deployments,
potentially creating security risks.
• Human Errors: Administrator errors during deployment or configuration, inappropriate
access controls, and misconfigurations can all lead to weaknesses that attackers may
take advantage of.
• Vulnerabilities Unique to each Vendor: The components and architectures of various
container orchestration platforms vary. Attackers familiar with the platform may focus
on vulnerabilities unique to a particular orchestrator.
• Postponing Patching: Patched orchestrator vulnerabilities may still be dangerous if
organizations take too long to install the fixes, leaving the environment open to existing
attacks.

Frequent security monitoring, correct configuration, periodic updates and patches,

compliance to security recommended practices, and the use of robust authentication and
authorization systems are just a few of the practices needed to mitigate orchestrator-level
weaknesses. A thorough security plan should also involve penetration testing, vulnerability
assessments and keeping up with the most recent security developments in the container
orchestration industry. Organizations should also continuously update their security prac-
tices to address emerging risks by staying up to date on the newest security advances in the
container orchestration environment.

4 Proposed framework: secure Orchestration

For the management, deployment, scaling, and security of containerized applications, safe
container orchestration entails the cooperation of multiple elements. The proposed frame-
work is depicted in Fig. 1. These are the primary elements required for secure container
orchestration:

4.1 Container Orchestrator

It is the primary element in charge of automatically managing, scaling, and deploying

containers. Kubernetes, Docker Swarm, Apache Mesos, and Amazon ECS are examples
of common orchestrators. Container orchestrators manage processes including rolling
updates, self-healing, load balancing, and container scheduling.

4.2 Master node

It is in charge of overseeing the cluster as a whole and making big choices. Additionally
it regulates scaling, maintains container scheduling, and guarantees the cluster is in the
proper state. It consists of parts like the controller manager, scheduler, API server, etc (a
persistent key-value store).

13
 Multimedia Tools and Applications

Fig. 1  Proposed Secure Orchestration Framework

4.3 Worker node

Workloads are carried out and containers are hosted. In addition to managing network-
ing and operating the container runtime (such as Docker), it also communicates to the
master node of the orchestrator. To fit more containers, it can be horizontally scaled.

4.4 Container runtime

The management and operation of containers is handled by the software. Runtimes like
Docker, containerd, and rkt are frequently used. The file systems, resources, and net-
working of containers are isolated and managed.

4.5 Load balancing and ingress controllers

Inbound network traffic is managed by them, and it is distributed to the relevant con-
tainers. Routing, SSL termination, and authentication are all made possible by ingress
controllers, which also regulate external access to cluster services.

13
Multimedia Tools and Applications

4.6 Container registry

It gives users access to a central site for posting and disseminating images while stor-
ing and managing container images. AWS Elastic Container Registry, Google Container
Registry, and Docker Hub are a few examples.

4.7 Network policies

In addition to enforcing segmentation, isolation, and security constraints, they specify

how containers communicate with one another within the cluster. Additionally, they
provide for precise network traffic control.

4.8 Secret management

Passwords and API keys are among the sensitive information that is safely stored there.
Additionally, it makes sure that only authorized containers have access to secrets. It is
possible to use programmes like HashiCorp Vault or Kubernetes Secrets.

4.9 Monitoring and logging

It keeps tabs on the cluster’s performance, security, and general well-being. Measure-
ments, logs, and footprints are gathered for evaluation and debugging. The ELK stack
(Elasticsearch, Logstash, and Kibana) and Prometheus are popular tools.

4.10 Security and compliance

It has practices and tools to make certain security and compliance requirements are sat-
isfied. Additionally, it includes checking for vulnerabilities, compliance checks, access
control (RBAC), and image protection.

4.11 Automated deployment and CI/CD

Container deployment from development to production environments is automated

because of its integration with Continuous Integration/Continuous Deployment (CI/CD)
pipelines.

4.12 Backup and disaster recovery

It contains tactics for business continuity, data backup, and recovery. Additionally, it
guarantees that, in the event of a failure, data and settings can be restored.

13
 Multimedia Tools and Applications

4.13 Auto‑Scaling and self‑healing

In order to preserve application availability, it detects failed containers and replaces

them automatically depending on resource demands.

4.14 Infrastructure as a Code (IaaC)

It visualizes IaaC files that specify the configuration of the infrastructure. These docu-
ments guarantee uniform, predictable deployments.
In order to ensure the secure deployment and maintenance of containerized appli-
cations, a Secure Container Orchestration system functions through a painstakingly
planned procedure that includes numerous components and security mechanisms. This
procedure is essential for preserving the reliability of applications and the supporting
infrastructure. Exploring its main components in depth is necessary to understand how
it functions.
The selected Container Orchestrator, such as Kubernetes or Docker Swarm, is at the
centre of the system. The orchestrator serves as the brain of the system, enabling the auto-
mation of critical operations like container deployment, scaling, and management. The
application code and dependencies are first created into container images by developers.
Only authorized individuals have access to the secure storage of these photos within a des-
ignated Container Registry.
The system moves forward with establishing the preferred configuration for the deploy-
ment of the application after the container images are prepared. The total amount of con-
tainer duplicates, their resource needs, networking demands, and other pertinent settings
must all be specified. Manifest files that specify where the containers must be managed are
typically used to describe these setups. The orchestrator is then given this data.
This data is managed by the master node of the orchestrator. It makes use of its inherent
intelligence to arrange the containers onto the cluster’s available worker nodes. This sched-
uling procedure ensures high availability while optimising resource use. In order to ensure
a seamless user experience, load balancers and ingress controllers are also used to manage
incoming network traffic and direct it to the right containers.
Security is the top priority at every turn. In order to achieve isolation and segmentation,
Network Policies are utilised to control communication between containers. To manage
rights, prevent unauthorised operations, make sure that containers and users are limited to
their proper responsibilities, and Role-Based Access Control (RBAC) are used.
Secret management technologies are used to maintain sensitive data securely, including
API keys and login credentials. These technologies eliminate the possibility of hardcoded
secrets within container images by securely storing and injecting these delicate details into
containers at runtime. To further gather and analyse metrics, logs, and traces from contain-
ers and the orchestrator, standard monitoring and logging tools are included. This thorough
approach makes it easier to spot abnormalities, keep performance at its peak, and react
quickly to security occurrences.
Tools for vulnerability scanning are used to continuously monitor and evaluate con-
tainer images for security flaws. Before deployment, any concerns can be addressed, guar-
anteeing that the containers begin their lives with the highest level of security. Realtime
security methods also keep a close eye on container behaviour and notify managers of any
unusual behaviour or actions.

13
Multimedia Tools and Applications

Self-healing procedures are implemented to ensure application availability and account

for changing demand. In order to avoid disturbances, the orchestrator automatically recog-
nises and replaces failed containers. Additionally, auto-scaling features adapt the number
of active containers based on demand patterns, optimising resource usage while adjusting
for variations in user traffic.
The technology streamlines the deployment process by seamlessly connecting the
orchestrator with Continuous Integration/Continuous Deployment (CI/CD) pipelines.
Automated image builds and deployments are triggered by changes to the application
code, encouraging agility and reducing manual involvement. To maintain the application’s
security, routine changes, such as security patches and software updates, are methodically
included into container images and deployment configurations.
The system also places a strong emphasis on compliance and audits. The security con-
figurations and settings within the orchestrator are examined as part of routine security
audits and reviews. Compliance checks make sure that the coordinated containers follow
safety guidelines and legal requirements, thus boosting the environment’s overall security
posture.

5 Experimental setup

In this experimental setup, we will delve into the concept of Infrastructure as a Code
(IaaC) and explore the utilization of Ansible as a powerful tool for automating DevOps
tasks (Refer Fig. 2). The architecture of Ansible will be elucidated, with a particular

Fig. 2  Summary of the Nodes that are Successfully Deployed

13
 Multimedia Tools and Applications

emphasis on its three primary components: the control node, managed nodes, and inven-
tory. This experiment aims to provide a comprehensive understanding of Ansible’s
functionalities, from executing ad hoc commands to orchestrating complex configura-
tions using playbooks. Additionally, Ansible will be compared to other configuration
management tools, such as Puppet and Chef, showcasing its distinctive features.
The primary objectives encompass a comprehensive grasp of the concept of Infra-
structure as Code (IaaC) and a thorough examination of Ansible’s capabilities as a tool
for automating DevOps workflows. This aim to meticulously dissect the architecture of
Ansible, delving into its core components – the control node, managed nodes, and inven-
tory – to provide a nuanced understanding of their roles and interactions. This investiga-
tion extends to explore Ansible’s modular framework, exemplified through the practical
application of modules like community. docker volume for Docker volume manage-
ment. The endeavor to elucidate the mechanics of executing ad hoc commands for rapid
task automation to the world of Ansible playbooks, illustrate their role in orchestrating
complex configurations using the YAML language. The execution process of playbooks,
including the targeting of hosts, will be intricately explained. Additionally, this aim to
provide a tangible scenario that demonstrates Ansible’s practical application in solving
real-world challenges. Lastly, the investigation encompasses a comparative analysis of
Ansible in contrast to other configuration management tools, highlighting its distinct
advantages such as an agentless architecture and the use of YAML language for configu-
ration specification. A strong crypto module is adapted for additional security [34].
In a concerted effort to enhance the security landscape, an Intrusion Detection and
Prevention System (IDPS) utilizing Suricata is strategically implemented [35]. This
IDPS assumes a pivotal role by actively surveilling the orchestration infrastructure,
thereby enabling proactive identification of vulnerabilities and potential intrusions.
Moreover, to enhance the monitoring and analysis capabilities, an Elasticsearch, Log-
stash, Kibana (ELK) stack is seamlessly integrated, facilitating real-time visualization
and in-depth examination of security events and system logs.

Fig. 3  Shows the Output of Attacks in the Monitoring Dashboard of ELK

13
Multimedia Tools and Applications

6 Results and discussion

Figure 3 provides a compelling visual representation of attack outputs within the moni-
toring dashboard of the ELK (Elasticsearch, Logstash, Kibana) stack. This depiction
specifically highlights the geographical distribution of detected attacks, offering a com-
prehensive view of the origins of potential threats across various regions. The visualiza-
tion within Fig. 3 effectively harnesses the power of ELK’s analytical capabilities, trans-
lating raw attack data into an informative map that showcases the geographic locations
from which these attacks are originating. By associating attacks with specific locations,
this visualization adds an additional layer of insight, potentially aiding in the identifica-
tion of patterns and correlations that could inform security strategies.
(Geographical Representation)
The interplay between ELK’s components, Elasticsearch for data storage, Logstash
for data processing, and Kibana for data visualization, is vividly exemplified in this
monitoring dashboard. The intuitive map-based representation serves as a valuable tool
for security analysts, enabling them to not only detect attack trends but also to assess
the global reach and potential impact of these threats. In essence, Fig. 3 encapsulates
the tangible benefits of integrating the ELK stack into the security infrastructure, show-
casing its capacity to transform raw data into actionable insights, fostering a proactive
stance in responding to security threats within the container orchestration ecosystem.
Figure 4 presents a detailed depiction of the SURICATA alerts, showcasing the dis-
cerning capabilities of the Intrusion Detection and Prevention System (IDPS) in identi-
fying potential threats within the orchestration ecosystem. These alerts serve as real-time
notifications of anomalous activities, enabling security personnel to promptly address
and mitigate potential security breaches. The visual representation in Fig. 4 encapsulates
a range of crucial information, including the type of alert, its severity level, the source
and destination IP addresses, as well as the timestamp of the detected event. This amal-
gamation of data equips administrators with the insights needed to evaluate the nature
and extent of each alert and to make informed decisions about the appropriate course of
action. The clarity and specificity offered by the SURICATA alerts in Fig. 4 underscore
the IDPS’s efficacy in swiftly identifying and flagging potential security incidents. By
capturing a diverse array of suspicious activities, ranging from reconnaissance attempts

Fig. 4  Shows the SURICATA Alerts

13
 Multimedia Tools and Applications

Fig. 5  Shows the Output of the Attack Information (SURICATA)

to intrusion efforts, this visualization reinforces the system’s proactive role in bolstering
the security posture of the container orchestration environment.
Figure 5 provides a visual representation of the output showcasing attack-related infor-
mation captured by the Suricata Intrusion Detection and Prevention System (IDPS). This
snapshot of attack data offers a glimpse into the system’s vigilant monitoring and its abil-
ity to promptly detect and log various forms of malicious activities, which could include
exploits, intrusion attempts, and potential vulnerabilities. The graphical interface highlights
the richness of information collected by Suricata, such as the type of attack, its severity
level, the affected system, and the timestamp of the incident. This comprehensive view
empowers administrators and security personnel to swiftly assess the nature and impact of
an attack, aiding them in making informed decisions regarding mitigation strategies and
response actions. Through the intuitive visualization provided in Fig. 5, the effectiveness
of the integrated IDPS solution, specifically Suricata, becomes apparent. This visual repre-
sentation not only aids in real-time incident response but also contributes to post-incident
analysis and forensic investigations, ultimately contributing to a more robust and resilient
security posture within the orchestrated environment.

7 Conclusion and future work

The research presented here offers a strategy for identifying and addressing orchestrator-
level vulnerabilities in platforms for container orchestration, such as Kubernetes. It sug-
gests cutting-edge methods for locating and eliminating security vulnerabilities brought on
by incorrect configurations, escalated privileges, and illicit access inside the orchestrator
system. The study highlights the best practices for safeguarding container orchestration
systems and tests the framework’s efficacy via practical experiments.
This research also introduces a comprehensive framework designed to identify and
counteract orchestrator-level vulnerabilities prevalent in container orchestration plat-
forms like Kubernetes. By innovatively addressing security concerns emanating from
misconfigurations, privilege escalation, and unauthorized access within the orchestrator

13
Multimedia Tools and Applications

system, this framework offers a robust solution to enhance platform security. To further
fortify the security landscape, an Intrusion Detection and Prevention System (IDPS) in
the form of Suricata is deployed. This IDPS plays a pivotal role in actively monitoring
the orchestration infrastructure, facilitating the detection of vulnerabilities and intru-
sions. This collaborative approach ensures a multifaceted security response to the chal-
lenges posed by orchestrator-level vulnerabilities.
Through rigorous real-world experiments (Refer Figs. 2, 3, 4), the efficacy of the
proposed approach, bolstered by the IDPS deployment, is meticulously evaluated. These
experiments closely simulate various threat scenarios, enabling a comprehensive assess-
ment of the framework’s ability to detect and respond to vulnerabilities and intrusions
within the container orchestration environment [33]. The empirical results obtained
from these experiments provide tangible evidence of the framework’s capacity to effec-
tively identify, mitigate, and prevent potential security breaches.

7.1 Current challenges in the proposed methodologies and future research

directions

In spite of the claim of the proposed methodology for enhancing security in container
orchestration, there are still drawbacks to apply whole system monitoring, including
possible influence on the system resources due to high frequency monitoring as well as
the manual adjustment for the detection threshold. In terms of our future work, it should
focus on the design of optimized mechanism to the framework for a better trade-off
between the framework’s real-time performance and its defense capability, especially
under large-scale orchestration environment. Specifically, as for zero-day vulnerabili-
ties as well as insider threats, we hope to figure out additional and on-line mechanism.
Machine learning techniques [36, 37] have proved to outperform traditional methods
especially on feature selection.
Also, this research endeavour will not only contributes to advancing the understand-
ing of container orchestration security but also offers valuable insights into implement-
ing best practices to safeguard container orchestration environments effectively. The
confluence of the proposed framework, IDPS deployment, and the strategic integration
of security practices contributes to a holistic approach in securing container orchestra-
tion platforms against diverse security risks. The study’s outcomes hold implications for
both academia and industry, fostering a proactive stance in addressing emerging secu-
rity challenges within dynamic IT ecosystems.

Funding No fund received for this project

Data availability All the data is collected from the simulation reports of the software and tools used by the
authors. Authors are working on implementing the same using real world data with appropriate permissions.

Declarations
Ethical approval and human participation No ethics approval is required.

Conflicts of interest The authors declare that they have no conflict of interest.

13
 Multimedia Tools and Applications

References
1. https://​www.​marke​tsand​marke​ts.​com/​pdfdo​wnloa​dNew.​asp?​id=​17658​4778&​utm_​source=​Email​&​
utm_​medium=​Acous​tic_​ICT_​APAC&​utm_​campa​ign=​Acous​tic_​Secur ​ity_​Orche​strat​ion_​Autom​
ation_​and%​20_​Respo​nse_​Market_​12_​July_​2022
2. Brewer EA (2015) Kubernetes and the path to cloud native. In: Proceedings of the SixthACM Sympo-
sium on Cloud Computing, 167167
3. Kubernetes Documentation https://​kuber​netes.​io/​docs/​home/. Accessed 1/6/24
4. Docker Documentation, https://​docs.​docker.​com/, Accessed as on 18 Aug 2023
5. Container Linux, Tectonic for Kubernetes, and Quay: CoreOS https://​coreos.​com/. Accessed 1/6/24
6. Apache Mesos http://​mesos.​apache.​org/. Accessed 1/6/24
7. The National Institute of Standards and Technology (2020) Open Security Controls Assessment Lan-
guage (OSCAL). https://​pages.​nist.​gov/​OSCAL/. Accessed 1/6/24
8. Ross RS (2013) Security and privacy controls for federal information systems and organizations. Tech-
nical report, National Institute of Standards and Technology
9. Reshetova E, Karhunen J, Nyman T, Asokan N (2014) Security of os-level virtualization technologies.
Nordic Conference on Secure IT Systems. Springer, Tromsø, pp 77–93
10. Mouat A (2015) Docker Security: Using Containers Safely in Production. O’Reilly Media, Sebastopol
11. Bui T (2015) Analysis of docker security. arXiv preprint arXiv:1501.02967. http://​arxiv.​org/​abs/​1501.​
02967. Accessed 1/6/24
12. Gummaraju J, Desikan T, Turner Y (2015) Over 30% of official images in docker hub contain high
priority security vulnerabilities. Technical Report, Banyan Ops
13. Abed AS, Clancy TC, Levy DS (2015) Applying bag of system calls for anomalous behavior detection
of applications in linux containers. In: IEEE Globecom Workshops. IEEE, San Diego. pp 1–5
14. Combe T, Martin A, Di Pietro R (2016) To docker or not to docker: A security perspective. IEEE
Cloud Comput 3(5):54–62
15. (2019) The Volatility Foundation. https://​www.​volat​ility​found​ation.​org/. Accessed 1/6/24
16. Clausing J (2016) SANS ISC InfoSec Forums: Forensicating Docker. https://​isc.​sans.​edu/​forums/​diary/​
Foren​sicat​ing+​Docker+​Part+1/​20835/. Accessed 1/6/24
17. Mostajeran E, Mydin MNM, Khalid MF, Ismail BI, Kandan R, Hoe OH (2017) Quantitative risk
assessment of container based cloud platform. In: IEEE Conference on Application, Information and
Network Security. IEEE, Sarawak. pp 19–24
18. Jian Z, Chen L (2017) A defense method against docker escape attack. In: International Conference on
Cryptography, Security and Privacy ACM, Wuhan. pp 142–146
19. Souppaya M, Morello J, Scarfone K (2017) Application container security guide. NIST Spec Publ
800–190:1–56
20. Winkel S (2017) Forensicating docker with elk. The SANS Institute. https://​sanso​rg.​egnyte.​com/​dl/​
J3Zw8​Npj4F. Accessed 1/6/24
21. Stelly C, Roussev V (2017) Scarf: A container-based approach to cloud-scale digital forensic process-
ing. Digit Investig 22:39–47
22. Lin X, Lei L, Wang Y, Jing J, Sun K, Zhou Q (2018) A measurement study on linux container secu-
rity: Attacks and countermeasures. In: Proc. 34th Annual Computer Security Applications Conference.
Association for Computing Machinery, San Juan. pp 418–429
23. Xiang J, Chen L (2018) A method of docker container forensics based on api. In: 2nd Int. Conf. on
Cryptography, Security and Privacy. ACM, NewYork. pp 159–164
24. Martin A, Raponi S, Combe T, Di Pietro R (2018) Docker ecosystem–vulnerability analysis. Comput
Commun 122:30–43
25. NIST (2018) National Vulnerability Database. https://​nvd.​nist.​gov/
26. Dewald A, Luft M, Suleder J (2018) Incident Analysis and Forensics in Docker Environments. ERNW
WHITE PAPER. https://​static.​ernw.​de/​white​paper/​ERNW_​White​paper​64_​Incid​entFo​rensi​cDock​er_​
signed.​pdf. Accessed 1/6/24
27. Lu Z, Xu J, Wu Y, Wang T, Huang T (2019) An empirical case study on the temporary file smell in
dockerfiles. IEEE Access 7:63650–63659
28. Debian’s security team (2020) Security Bug Tracker. https://​secur​itytr​acker.​debian.​org/​track​
er/. Accessed 1/6/24
29. Zerouali A, Mens T, Robles G, Gonzalez-Barahona JM (2019) On the relation between outdated
docker containers, severity vulnerabilities, and bugs. In: IEEE 26th Int. Conf. on Software Analysis,
Evolution & Reengineering. IEEE, Hangzhou. pp 491–501

13
Multimedia Tools and Applications

30. Williams A, Ball B, Hoang Dinh G, Hecht L (2019) Monitoring and Management with Docker and
Containers. https://​thene​wstack.​io/​ebooks/​docker-​and-​conta​iners/​monit​oring-​manag​ement-​docke​rcont​
ainers/. Accessed 1/6/24
31. Sysdig (2020) Run Confidently with Secure Devops - Security for containers, Kubernetes, and cloud
services. https://​sysdig.​com/. Accessed 1/6/24
32. Wenhao J, Zheng L (2020) Vulnerability analysis and security research of docker container. In: IEEE
3rd International Conference on Information Systems and Computer Aided Education. IEEE, Dalian.
pp 354–357
33. Devi Priya VS, Chakkaravarthy Sethuraman S (2023) Containerized cloud-based honeypot deception
for tracking attackers. Sci Rep Nat
34. Das D, Sethuraman SC, Satapathy SC (2022) A Decentralized Open Web Cryptographic Standard.
Comput Electr Eng 99:107751
35. Chakkaravarthy SS, Sangeetha D, Cruz MV, Vaidehi V, Vaidehi V (2020) Design of Intrusion Detec-
tion Honeypot using Social Leopard Algorithm to detect IoT ransomware attacks IEEE. Access
8:169944–169956
36. Yang S, Chen B (2023) SNIB: Improving Spike-Based Machine Learning Using Nonlinear Informa-
tion Bottleneck. IEEE Trans Syst Man Cybern 53(12):7852–7863
37. Yang S, Chen B (2023) Effective Surrogate Gradient Learning With High-Order Information Bottle-
neck for Spike-Based Machine Intelligence. In: IEEE Transactions on Neural Networks and Learning
Systems

Publisher’s Note Springer Nature remains neutral with regard to jurisdictional claims in published maps and
institutional affiliations.

Springer Nature or its licensor (e.g. a society or other partner) holds exclusive rights to this article under
a publishing agreement with the author(s) or other rightsholder(s); author self-archiving of the accepted
manuscript version of this article is solely governed by the terms of such publishing agreement and applicable
law.

13