Talking about Linux container and mirror signature

Guide

Fundamentally, almost all of the major software, even open-source software, was designed before the advent of mirror-based container technology. This means that putting the software in a container is equivalent to a platform migration. This also means that some programs can be easily migrated, while others are more difficult.

I carried out mirroring-based container-related work about 3.5 ago. So far, I've containerized a lot of applications. I learned what reality is and what superstition is. Today, I would like to briefly describe how Linux containers are designed, and also talk about mirrored signatures.

How the Linux container is designed

For a mirrored-based Linux container, most people are confused that it divides the operating system into two parts: kernel space and user space . In traditional operating systems, the kernel runs on hardware and you cannot interact directly with it. User space is what you really interact with, including all the files, libraries, and programs you can see through the file browser or by running the LS command. When you use the Ifconfig command to adjust the IP address, you are actually using the user-space program to make the kernel change based on the TCP protocol stack. This is often a surprise to those who have not studied the Linux/unix Foundation. In the past, class libraries in user space supported programs that interacted with the kernel (such as ifconfig, Sysctl, Tuned-adm) and user-oriented programs such as network servers and databases. All of these things are stacked in a single file system structure. Users can find all programs and class libraries supported by the operating system itself in the/sbin or/lib folder, or they can find all user-oriented programs or class libraries in the/usr/sbin or/usr/lib folder (see File system hierarchy Standards). The problem with this model is that operating system programs and business support programs do not have absolute isolation. The programs in/usr/bin may depend on the class library in/lib. If an application owner needs to change something, it is likely to disrupt the operating system. Conversely, if the team responsible for security updates needs to change a class library, it can (often) disrupt business-oriented applications. This is a real mess. With mirroring-based containers such as Docker, LXD, and RKT, application owners can package and tune all dependencies placed in/sbin,/lib,/usr/bin, and/usr/lib without worrying about destroying the underlying operating system. Essentially, container technology cleanly isolates the operating system into two parts: kernel space and user space. Now developers and OPS can independently update their own things. However, there are some disturbing places. Typically, each application owner (or developer) does not want to be responsible for updating these application dependencies: such as OpenSSL, glibc, or very low-level underlying components, such as an XML parser, JVM, or processing performance-related settings. In the past, these issues were entrusted to the OPS team for processing. Because we pack a lot of dependencies in containers, it's still a serious problem for many organizations to be responsible for everything inside the container.

Migrating existing applications to Linux containers

Putting the application in a container is a platform transplant, and I'm going to highlight exactly what makes porting certain applications to containers so difficult. Developers now have complete control over the contents of/sbin,/lib,/usr/bin, and/usr/lib. The challenge, however, is that they still need to put the data and configuration in the/etc or/var/lib folder. This is a bad idea for mirroring-based containers. What we really need is the isolation of code, configuration, and data. We want developers to put the code in the container, and the data and configuration are available in different environments, such as development, testing, or production environments. This means that we (or platforms) need to mount some files or folders in/etc or/var/lib while instantiating the container. This allows us to move containers around and still get data and configuration from the environment. Sounds cool, huh? Here's the problem, we need to be able to cleanly isolate the configuration and data. Many modern open-source software such as Apache, MySQL, MongoDB, Nginx is done by default. But many of the self-produced, historical, or proprietary programs are not designed by default. For many organizations, this is the main pain point. The best practice for developers is to start architecting new applications and porting legacy code to complete configuration and data isolation.

Introduction to mirrored signatures

Trust mechanism is an important issue in containers. The container mirroring signature allows the user to add a digital fingerprint to the mirror. This fingerprint can then be verified by the cryptographic algorithm. This allows the user of the container image to verify its origin and trust. The container community often uses the phrase "container mirroring," but this naming method can be quite confusing. Docker, LXD, and RKT implement the concept of getting remote files to run as containers. Each of these technologies handles container mirroring in different ways. LXD uses a separate layer to obtain a single container, while Docker and RKT are based on the Open container image (OCI) format, which can be composed of multiple layers. Unfortunately, there are situations where different teams and organizations are responsible for the different layers in the container image. The concept of container mirroring is implicit in the concept of container mirroring. Having a standard image format, such as OCI, enables the container ecosystem to thrive around mirroring, signing, and transferring between different cloud service providers. Now it's about the signature. There is a problem with the container, and we put a bunch of code, binaries, and class libraries into it. Once we have packaged the code, we will share it with the necessary file servers (registered servers). As long as the code is shared, it is basically anonymous and lacks some kind of ciphertext signature. To make it worse, container mirroring is often made up of individual mirror layers that are controlled by different people or teams. Each team needs to be able to check the work of the previous team, increase their own work content, and add their own approval stamp to it. Then they need to continue to hand over the work to the next team. The end user (composed of many mirrors) of the container image needs to check the chain of custody. They need to verify the trustworthiness of each team that adds files to it. It is extremely important for end users to have confidence in each layer in the container image.

Originally from: http://www.linuxprobe.com/linux-docker-sign.html

Free to provide the latest Linux technology tutorials Books, for open-source technology enthusiasts to do more and better: http://www.linuxprobe.com/

Talking about Linux container and mirror signature