Cloud Computing Security: Challenges and Solutions

Introduction

The main goal of the research is to study the wide variety of challenges, issues and solutions Kubernetes presents in regard to cloud computing security. With the rise of microservice architecture and containerization technology, developers and administrators have begun to test and deploy modern software in a completely different way. Containers make it easier to scale and deploy applications, but they also create an entirely new infrastructure ecosystem, which means new challenges and complexities. There are many solutions already created for Kubernetes that allow its users to achieve standards compliance even in highly demanding environments. However, despite the continuous progress in assessing greater level of cloud security, there are still issues Kubernetes has yet to solve. The challenges are plenty, and they assemble into one big question: how to effectively avoid different threats when using Kubernetes without losing any data or control over the system itself? This research will address the Kubernetes security issue and try to find solutions for the most imposing safety risks to cloud computing.

Prototyping and Testing

The main prototype used and tested in the project is a specifically designed architecture that ensures the transmission security of the information in the Kubernetes Cluster on a controlled Cloud Vendor environment. An open-source version control system will be used as a source of configuration description for deployment automation systems, as well as for scaling microservice applications. The integration of Kubernetes, Git, Kube-applier and Sealed Secrets is the most suitable for ensuring the protection of information in the version control system. The Sealed Secrets system consists of two parts: a controller on the Kubernetes’ cluster side, and a tool Kubeseal on the user side. At the first start, the controller generates encryption keys – public and private – and stores them within the cluster. Subsequently, the controller decrypts cluster objects of type SealedSecret and creates, deletes or modifies objects of the Secret type, and recording decrypted information in them.

Enabled TLS-support

Another test requires the enabling of TLS-support. For every component that supports TLS, it must be enabled – to prevent sniffing of the traffic, the server identity authentication, and, in case of Mutual TLS, the client identity. Ideally, TLS is needed between each component on the master, and also between the Kubelet and the API server. Historically, auto-scaling of Kubernetes’ nodes has been challenging because each node required a TLS key to connect to the master, and keeping valuable information in base images made the system vulnerable. The Kubelet TLS bootstrapping enables the new Kubelet to create a certificate signing request so that certificates are generated at boot time.

The designed solution will be implemented in a test environment and tested with a suitable containerized application.

Risk Assessment

The Impact of Kubernetes’ Security within a Controlled Cloud Environment

Hardware technology is constantly developing in accordance with Moore’s law – their demand doubles every 24 months. Following the trends, high-performance servers that originally used the first expensive solid state drives for storing data now use large volumes cloud environments to store their databases. The abstraction of various cloud infrastructures with management containers requires a special software environment – such as Kubernetes, Google Anthos or Microsoft Azure Arc. Controlled cloud applications have a more detailed set of lightweight security primitives to help protect workloads and infrastructure. The power and flexibility of Kubernetes’ tools is both a blessing and a curse: without enough automation to use them, it’s even easier to expose unsafe applications that allow them to go beyond the container or their isolation model. The implementation of the Kubernetes’ continuous delivery principles ensures regulatory compliance, continuous auditing, and enhanced governance without impacting performance. Kubernetes’ most impressive feature is the ability to improve cloud environment safety quickly and incrementally through continuous security. It is, essentially, an alternative to time-based penetration tests with constant validation in the pipeline that ensures that the attack area is known and the risk is always clear and manageable.

Docker and Kubernetes in Security-Demanding Environments

A container is an isolated user-space environment that is often implemented using kernel capabilities. For example, Docker uses the Linux namespaces, cgroups and capabilities for operations. In this sense, Docker container isolation is very different from virtual machines launched by type 1 hypervisors which run directly on the hardware. Looking at the attack vectors of a bare-metal hypervisor versus the Linux kernel, it is obvious that the latter has a much larger attack surface due to its size and range of capabilities. Large attack surface means more potential attack vectors for cloud environments using container isolation, and Docker is quite vulnerable to them. To manage containers running in multi-node environments more efficiently, Kubernetes orchestration is used. The idea is that the nodes of the Kubernetes cluster are virtual machines using virtualization on hardware. Since virtual machines will act as sandboxes for containers that run in pods, each node can be viewed as a safe sandboxed environment. To take advantage of this method in a cloud environment and provide scalability, additional requirements must be met. The most important requirement will be the implementation and verification of the ubiquitous accounting of the classification of applications.

Project Methodology

Application containerization is one of the main trends in modern IT development. However, containers have one significant drawback for the mass consumer – the complex scaling settings. The automated containerization management systems could present a solution to this problem, and the most popular of these systems is Kubernetes. This open source software has gained recognition for its combination of flexibility, security and power. Kubernetes is an external source project designed to manage a Linux container cluster as a single system. It manages and runs Docker containers on a large number of hosts, while also providing co-location and replication of a large number of containers. The project was started by Google and is now supported by different companies such as Microsoft, RedHat, IBM and Docker. The project offers a solution for two questions: how to scale and run containers on a large number of Docker hosts at once, and how to balance them. To address those issues, Kubernetes offers a high-level API that defines the logical grouping of containers, allowing the user to define pools of containers, balance the load, and specify their placement. For example, when a user manages several data centers, thousands of hardware servers, virtual machines and hostings for hundreds of thousands of sites, Kubernetes can greatly simplify the unified administration.

Project Approach

Kubernetes’ Security Challenges. User and Market needs

To understand the issues behind Kubernetes’ security, one should first develop a full and thorough understanding of what Kubernetes is and how does it work. For this, an elaborate study of Kubernetes’ architecture is necessary. By developing an insight into the structure of the system and the interconnections behind its parts, one can develop a more comprehensive perspective of Kubernetes’ unique features. The basics of how Kubernetes work demand the use of a declarative approach. The developer is required to indicate what needs to be achieved, not how to achieve it, which is also a point to consider in studying the security challenges of cloud computing using Kubernetes. Diving further into researching Kubernetes, one might find that understanding the system’s main tasks would also help construct an objective view of Kubernetes’ role in cloud management. With the help of ample research, the main goal of understanding and addressing Kubernetes’ security issues is perfectly achievable in the time allowed. The only technical requirement is the access to Kubernetes itself. However, there is also an alternative study possibility – the containers and the perspectives of their use in microservices architectures.

Background. Analysis of User Needs and Solutions

The open-source deployment tools like Kubernetes offer an API, defining logical grouping of containers, allowing to determine pools of containers, balance the load, and also set their placements. This technology solves several problems of its users at once:

1. The problem of free space: each individual container rises with its assembled image on Linux technology, and into each image user can put the maximum small number of additional functions.
2. The product in the container is isolated from the rest of the environment. Therefore, its fault tolerance increases accordingly.
3. The customizable balancing helps to regulate traffic between containers and improves fault tolerance.

Looking at the architecture of the system, users can break it down into different services. These services are launched on each individual Kubernetes’ node – they are necessary for managing this node by the master and for launching applications. In addition, Docker runs on each node too, providing loading images and launching containers.

Developing a Solution

After carrying out a study of the problems of microservice architecture, the requirements for the automation of the development process, the process of managing powerful resources and methods of their implementation were identified. The proposed solution is to design a secure pipeline composed of some of the researched Open Source deployment tools. It shall be built based on modern principles and recommendations using only open-source tools.

When deploying a multi-component application, Kubernetes independently chooses a server for each component, installs the component, and ensures its visibility and communication with other application parts. To deploy software, Kubernetes uses a Linux container base (for example, Containerd or CRI-O) and a description of the number of containers required and how much resources they will need. Essentially, basic Kubernetes tasks include mainly the deployment of containers and all operations necessary for running the required configuration. To these operations belong the restarting of the stopped containers, their relocation for allocating resources for new containers, as well as scaling and running multiple containers simultaneously on a large number of hosts. In addition, to balance multiple containers during startup, Kubernetes uses an API whose task is to logically group containers. This makes it possible to define their pools, set their placement, and evenly distribute the load.

The Solution Implementation and Deployment

To create a self-restoring system using Kubernetes, a cluster is required, because a single server cannot be fault tolerant. If the server’s hardware fails, the self-restoring system will not be able to take the necessary action to fix the error. Thus, the system must start simultaneously with the cluster. After creating a cluster, user can deploy services to it. However, managing the deployment of many containers without automation is nearly impossible, and this is where Kubernetes’ open source tools come into action. The base of any independent self-restoring system is a complex structure of monitoring of the state of deployed services, and the hardware component on which these services are run. The most optimal way to get information about the existence of services is a service discovery system, for example, Consul, etcd, or Zookeeper. After the cluster is configured, the system monitoring, which seeks out various anomalies, can be connected to it. The monitoring needs to know not only the required state of the system, but the real state, too, at any given time. Consul Watches, Nagios or Icinga, would be the most useful tools for this task.

Testing the Solution

Just like any other development environment, everything starts with version control. For this project, Git will be the version control system. Compared to analogs, Git is the leading version control system because of the variety of its functional component, ease of use and integration with third-party services. However, Git itself will not be enough – a Git repository manager is also required, as it provides said integration to open source tools. For example, if the tested continuous integration tool fails a build, it can reach back to the Git manager, where a red mark will be displayed next to the commit signifying the tool was not able to build it. After deciding which technologies will be implemented into the system, the next step will be the visualization of the system architecture and construction algorithms for assembling, testing and releasing software. Thus, using different open source tools, the created architecture would provide a fully automated and secure delivery of confidential information for microservice programs, in conditions of open access to the version control system.

Design Modifications and a Second Test

Workloads in Kubernetes are distributed across pods, which consist of one or more containers deployed together. Kubernetes’ network policies set permissions for pod groups in the same way that cloud security groups are used to control access to virtual machine instances. If no policies are defined, Kubernetes allows all traffic by default. All pods can freely exchange information with each other. Due to this complexity, the policies of many existing clusters contain failures and may potentially cause danger to information security. This issue might be resolved by including automatic policy definitions or the usage of other segmentation tools. Moreover, inappropriate or unnecessarily permissive RBAC policies create a security risk if the pod is compromised. Audit logging offers a customizable API for workloads logging such as request and response at the metadata level. The logging level must be configured in accordance with the organization’s security policy. Storing these logs inside the cluster is a security risk for any system working on Kubernetes. These logs, like any other security-sensitive assets, should be placed outside the cluster to avoid negative consequences in the event of a vulnerability, using the control plane.

Results Report

A consecutive conducting of solution tests identified the problems that arise with the usage of microservice architecture to build high-load application software. These problems lie both in the development and management process of this process, as well as in the infrastructure and system landscape. These problems, present over the course of the development of the system, entail an increase in the time intervals between deployments, as well as reveal unnecessary risks regarding information security. In the course of the study, an analysis of the approaches and methods of automating the above processes was carried out. The analysis showed that in order to achieve the necessary results, the open-source tools for the system deployment and operation are required. Moreover, the findings suggest the implementation of practices such as continuous integration and continuous deployment help resolve security issues. It is recommended to move from traditional virtualization to containerization of microservices using a container orchestration mechanism.

Project Plan

The main goal of the project is to build a reliable Kubernetes self-restoring system with continuous integration to solve a complex of development tasks like analyzing, building and testing applications. It is necessary to develop assembly algorithms applications using containerization tools and integrate open source tools into it. Moreover, the system will be deployed on a controlled cloud service that allows flexible configuration of the security of group policies, assign roles and extend the application. From existing modern cloud services, the most optimal for this project is the Google Cloud Platform. This service provides the largest amount of integration with Kubernetes technology, such as creating compute clusters for Kubernetes, its monitoring and management. Next, in the selection of an artifact repository, the following criteria have been considered:

• High speed of loading and unloading artifacts;
• Fault tolerance and high availability;
• Integration with third-party services.

After assessing all of the criteria, Git repository manager have been selected as an artifact repository.

Project Phases

The first step in implementing the system is to connect servers to Google Cloud Platform using Kubernetes and create a cluster with standard characteristics.

In a ready-to-run cluster, [NAME OF THE INTEGRATION TOOLS] continuous integration tools are [IS] deployed. The security settings are configured, and the necessary plugins to work with the rest of the continuous integration tools are installed.

The source code analysis is to be conducted. This process is called Pull-Analyze, and the following operations are necessary:

• Downloading the source code from a remote Git repository;
• Connecting to [NAME OF THE TOOL] and transferring parameters to analyze the source code;
• Sending logs to mail if execution experiences success or fails;
• Triggering the Build-Push-Deploy Task.

After that, the deployment of the implementation process begins. It consists of the following operations in the [NAME OF THE TOOL] task:

• Google Service Account authorization;
• Setting up the Docker environment;
• Assembling the project;
• Uploading the image to Google Cloud Registry;
• Configuring access to the Kubernetes cluster;
• Deploying the application to a cluster;
• Sending logs to mail if execution experiences success or fails;
• Triggering the Automated-Tests task.

With deployment complete, an analysis of results is to be conducted, and design modifications and a second testing are in order. Final results are reported.

Deliverables and Milestones

Desired deliverables would contain extensive documentation on the installation and use of the program in order for the mass user to employ. This documentation will include readme markdown files expressing in detail how to deploy a reliable Kubernetes self-restoring program. Kubernetes can serve as an application for the secure processing of confidential information related to the operation of applications – passwords, OAuth tokens, SSH keys. Moreover, depending on the application, the data and settings can be updated without re-creating the container. Using special metrics and tests, a self-restoring system can quickly identify damaged or unresponsive containers, which are created anew and restarted on the same pod. Additionally, it will include a well-commented code as an instruction for the open-source community intending to clone the system and contribute to the repository. A possible milestone of the project is an open-source code that could be continually improved by the open-source community. The benefits of the open-source code is that it is considered more cost-effective, quicker to develop, well-secured, and more extensible in the future by anyone.

Conclusion

Kubernetes is the most advanced container orchestration tool available today. It allows not only to automate the deployment process, but it also maximally simplifies the further process of working with arrays of containers. Boundary calculations are of enormous importance for mass headquarters deployment of the global Internet of things. It is precisely the development and optimization of the edge cloud framework that will allow users to achieve the maximum efficient computing system capable of adapting depending on different factors. The approach of unifying a distributed application into a single computing cluster, creating a reliable data link brings the concept of a comprehensive, seamless data center. This center will link edge servers together, as well as the edge cloud and, through a gateway, public network services. However, there are several security challenges regarding Kubernetes’ networking policies, implementation of bare-metal hypervisors and improvement of systems’ fault tolerance. These issues can be resolved by a more apprehensive approach to the Kubernetes’ inner management, as well as by developing test systems to assess the security risks and continuously gather data for resolving them.