Shulou(Shulou.com)05/31 Report--

This article mainly explains the "Docker image security example analysis", the article explains the content is simple and clear, easy to learn and understand, the following please follow the editor's ideas slowly in depth, together to study and learn "Docker image security example analysis" bar!

First, problems

When using Docker to run containerized applications, the host usually downloads the corresponding image from the Registry service (such as Docker Hub). This mirroring mechanism is effective in the development environment, and the same image can be easily shared among team members.

However, in the actual production environment, when a large number of hosts need to download and run container applications from Registry images at the same time (such as releasing new versions, patching, etc.), Registry services often become the bottleneck of image distribution, and it takes a long time for application images to be transmitted to all hosts, which greatly prolongs the cycle of application release.

In this regard, many enterprises have proposed P2P solutions to accelerate image download, but they are all use scenarios of private cloud and internal environment, which are not used in public cloud, mainly because users are worried about security problems in data transmission in P2P. This paper will focus on the P2P image distribution system to ensure the security of user data.

II. Structure

Sample diagram of Huawei Cloud P2P container image distribution system

The P2P container image distribution system of Huawei cloud container image service SWR consists of three components: client agent (Proxy), BT client and BT Tracker.

Client Agent (Proxy)

The client agent is deployed in each node of the cluster, configured as the Http Proxy of Docker, intercepts the image download request of Docker Daemon, notifies Client to download, and finally imports the image into Docker daemon.

BT client

The BT client and Tracker deployed in the cluster node together constitute a complete P2P file transfer system. During the whole distribution process of the image, they use the BT protocol to complete the image download.

BT Tracker

Tracker is a part of BT system, it stores the metadata information and seed information needed in the download process of BT client, and assists each BT client to complete the whole communication process.

III. Safety

First of all, we limit P2P downloads across clusters to maximize data leakage between tenants.

After that, the security at the link level and the security at the business level are enhanced.

1. Link security

When we think of link security, the first thing we think of is encryption.

Symmetric encryption server and client use the same secret key to encrypt and decrypt, as long as the secret key is not public and the secret key is secure enough, then the link is secure. However, using the same symmetric encryption key in the network is tantamount to public transmission, and if the key is hijacked, then all the data on the link can be tampered with.

Then we must think of HTTPS, how does it achieve security? Let's first take a look at how HTTPS is implemented.

In the specific process of data transmission, HTTPS adopts the way of symmetrical encryption and decryption, but it adds the process of handshake negotiation when the connection is established.

What is a public key:

Public key is a concept in asymmetric encryption. The asymmetric encryption algorithm is based on a secret key pair, and the data is encrypted by one secret key and can only be decrypted by another secret key. The server saves the private key and sends the public key to the client.

Let's assume a scenario where we generate a secret key pair, the client encrypts the data with the public key, and the server decrypts the data with the private key. Then even if the user hijacks the public key, he cannot hijack and tamper with the user's data. However, the link from the server to the client is not secure.

HTTPS makes use of this feature of asymmetric encryption to ensure that the transmission of symmetric secret keys is secure, and finally uses symmetric encryption to transmit data.

The meaning of the certificate:

However, this gives rise to a new problem: what if the public key is hijacked?

Of course, HTTPS will not be hijacked so easily, it introduces digital certificates and third-party institutions. The certificate is issued by a third-party certification authority through the public key, which contains not only the public key, but also the signature (encrypted by the private key of the issuing node), time limit, issuing authority, web address, expiration date, etc.

HTTPS no longer returns a private key, but a certificate. When the client receives the certificate, it makes a check on the certificate. An authoritative list of third-party institutions (including their public keys) is maintained on each machine, and when the client needs the public key, the public key can be found locally based on the authority information. The client verifies the validity of the signature and the integrity of the certificate through the public key of the authority to ensure that the public key has not been tampered with.

HTTPS secures the link through private keys, certificates, and CA (the issuing authority). In the P2P scenario, the BT Client is peer-to-peer, and when they transmit data to each other, it should be the server-side verification client rather than the HTTPS client-side verification server. And because BT Client is deployed on the user's node, you also need to consider the risk of certificate and private key being hijacked.

How did we do it?

Between Client

Data transferred between BT Client must need to be encrypted to prevent link data from being hijacked. But only add HTTPS, although the link is encrypted, but the client may be faked. As long as the impostor does not verify the server's certificate and directly shakes hands with the server, he can get the data he wants from other BT Client.

We draw lessons from the implementation of HTTPS and adopt the mode of two-way verification.

You need to have a certificate, first of all, you need a unified CA (issuing authority), so we save the certificate and private key in Tracker as the issuing authority. When Proxy gets the seed, it returns CA, and the user verifies the client's certificate.

Then, it is dangerous to use only one certificate pair and put it in Bt Client, and it is very likely to be intercepted by intrusion, so the way we obtain the certificate is changed to obtain the certificate from Tracker, get the seed while obtaining the temporary certificate private key pair generated by Tracker, and add it to the download queue of BT Client. When BT Client begins to connect with each other, it first confirms the validity of each other's certificate (signature, issuing authority, etc.), and then requests and downloads data from each other after verification.

In this way, the link between Client is secure.

(1) it is not feasible to intercept the link directly because the link is encrypted by certificate.

(2) even if we imitate the method of BT Client, since each connection of Client requires two-way certificate verification, if you want to intercept data in this way, you must request Tracker to obtain it, and accessing Tracker is first of all HTTPS, and then we have done a security check at the business layer (which will be mentioned below), which is not feasible.

Docker Daemon to Proxy

We need to hijack Docker's request in Proxy, because Docker accesses Registry using HTTPS when it is not configured, so Proxy hijacking Docker request must maintain HTTPS connection with Docker.

We asked the client agent to listen only on the localhost port, eliminating the possibility of external use of the agent. At the same time, the client agent binds a set of temporarily generated self-signed certificates and CA certificates issued to the registry domain name to hijack the Docker Daemon request and add the CA certificate to the machine's trust certificate.

The certificate bound by the agent is only stored in memory, and even if the CA certificate and server certificate of the current node are obtained in a specific way, the data of other nodes cannot be intercepted.

From user node to Registry, Tracker

First of all, in order to ensure the security of the link, Regstry and Tracker are bound to HTTPS certificate private key pairs purchased from authoritative third parties. Both Proxy and BT Client will verify the validity of the certificate when they visit them, and send requests only if the certificate is valid, which eliminates the possibility of Regstry and Tracker being faked.

2. Business encryption

After ensuring the security of the link, we have also done a layer of business security reinforcement. First, let's take a look at JWT Token.

Json web token (JWT) is a JSON-based development standard (RFC 7519) for the delivery of declarations between network application environments. The token is designed to be compact and secure, especially suitable for single sign-on (SSO) scenarios of distributed sites. The declaration of JWT is generally used to transfer authenticated user identity information between the identity provider and the service provider in order to obtain resources from the resource server, and can also add some additional declaration information necessary for other business logic. The token can also be directly used for authentication or can be encrypted.

When we use the Docker command to download the image, Docker will first go to Registy to obtain the Token. Later, in the process of obtaining the image layer, the Token will be used for authentication. The Token group should contain the following information:

(1) user information

(2) Resource information, which is the name of the image and namespace of the operation.

(3) permission information: whether there is PULL/PUSH permission

(4) Certificate used to parse Token signature

Using the feature of parsing Token certificate in JWT Token, we add Token check in the communication between BT Client. After the certificate verification in the previous article has passed, the client needs to send Token to the server for verification. In order to prevent the Token from being impersonated, the intruder is generated by a third party. We use the server to intercept the certificate parsing in the Token intercepted from the Docker to verify the client's Token to eliminate this situation.

At the same time, the Token,Tracker will also be used on the Proxy's interface to access Tracker to verify the permissions of Token, complete the security verification at the business layer, and prevent certificates and seeds from being stolen.

Thank you for your reading. The above is the content of "Docker Image Security example Analysis". After the study of this article, I believe you have a deeper understanding of the problem of Docker image security example analysis, and the specific use needs to be verified in practice. Here is, the editor will push for you more related knowledge points of the article, welcome to follow!

Welcome to subscribe "Shulou Technology Information " to get latest news, interesting things and hot topics in the IT industry, and controls the hottest and latest Internet news, technology news and IT industry trends.