Security management of big data -- Kerberos

1 Introduction

Some time ago, I have been doing the configuration and analysis of the security environment (Kerberos) under the big data cluster. There are many misunderstandings, which are recorded here. Of course, kerbeos itself is also more complicated, and here it is only recorded from the perspective of a user

2. Security Basics – Kerberos

When it comes to Hadoop cluster security, we think of Kerberos. There are many explanations for Kerberos. The following is my understanding of kerberos

2.1 What is kerberos

Kerberos is a network authentication protocol designed to provide strong authentication services for client/server applications through a key system. The realization of the authentication process does not depend on the authentication of the host operating system, does not require trust based on the host address, does not require the physical security of all hosts on the network, and assumes that the data packets transmitted on the network can be read, modified and inserted arbitrarily. . In the above cases, Kerberos, as a trusted third-party authentication service, performs authentication services through traditional cryptographic techniques (such as shared keys).

This is an explanation on Baidu Encyclopedia, which is very official and correct (not that it is not good), but it is difficult to understand, but we only need to remember two points: 1.
Kerberos is a protocol.
2. This agreement should include three aspects: client, server, and authentication center

2.2 How Kerberos works

The Kerberos authentication process is similar to the process of seeing a doctor in our hospital. Let's take a look at our general medical treatment process
1. The patient will first take his ID card or medical card to the registration center to register. When the patient registers, the patient will provide the following information: doctor's name + department 2.
Registration After the center receives the patient's application, it will check the basic information of the patient, and then return a registration form. In this registration unit, it will include the following
residence registered. The registration center is to give a registration order. This form generally has the following information:
attending doctor|department|patient information|seeing time
3. After receiving the registration form, the patient goes to the corresponding doctor and hands the registration form
to the doctor. The first thing is to check the registration form. Generally, it is to see whether the items of doctor + department + diagnosis and treatment time are correct. If they are not correct, the patient will be thrown out (throwing an exception). If everything is correct, start diagnosis and treatment.
Write picture description here

And our Kerberos authentication process is also like this:
1. When a client needs to access a server, it first applies to the KDC for a ticket.
2. The KDC will verify the client information, that is, the principal corresponding to the client we input After the information and password are successfully compared, a ticket will be returned. In this ticket, there will be: server-side principal information | client-side principal information | ticket validity period
3. After the client gets the ticket, it will get the ticket to access the server.
4. After receiving the client's access request, the server will first check the ticket information. It also checks whether its own princal information corresponds to the princal information of the ticket, and whether the ticket is within the validity period. If there is a complete correspondence, the interaction process will be completed, otherwise an exception will be thrown.
(In fact, kerberos authentication is more complicated, you can read: http://blog.csdn.net/wulantian/article/details/42418231 )

One thing we need to pay attention to is: after the patient gets the call list, neither the patient nor the doctor will interact with the registration center. The same is true for Kerberos authentication. When the client gets the ticket, neither the client nor the server interacts with the server anymore.

Let's summarize the patient's entire diagnosis and treatment process, which has two parts:
1. The patient registers at the registration center, and the registration center verifies the identity according to the ID card provided by the patient and returns a registration form.
2. The patient hands the registration form to the doctor. The doctor checks this registration form.

Corresponding to the access process of kerbos, we can divide it into two parts, and these two parts correspond to our two protocols JaaS and GSS-API respectively. 1. The client makes a request to the KDC, and the KDC verifies the identity
and returns the ticket – JaaS
2. The client sends the ticket to the server, and the server performs ticket verification – GSS-API

In the next chapter, we will expand on these two

Guess you like

Origin blog.csdn.net/eyoulc123/article/details/78772209