 Hello, everybody. My name is James Guo. I came from H3C. Today, we'll talk about Kingston as an authentication center for Kubernetes and OpenStack. I will talk... I choose to speak in Chinese because I think my PPTA is elutable for guys from other countries. So for guys from other countries, I think you can get much information from my PPTA as I speak in English. For Chinese, I can explain it deeply in Chinese. So I can talk beyond the PPTA. Let's take a look at a basic example. In OpenStack, there will be an organization called Kingston to do user authentication. But when we provide a cloud service, we always provide it with a cloud host, a login number, and a container as a service. At this time, we need a set of user systems, a user system, and a authentication system to provide service. We know Kubernetes is not the only way to do it. We can also use OpenStack, a user system, and a authentication system. I will talk about the same topic today. Let's take a look at the most basic price. We can see that the bottom is an OpenStack Kingston. We will divide it into two groups. Kingston needs to be divided into two groups. We know that Kingston has a strong capacity, but as a product, as a user system, it needs to provide service. There are still some work to be done. There are two solutions to this growth. One is the original Kingston. The other one is that after we divide it into two groups, we need to provide a special interface for our portal. Why do we need to provide a special interface for our portal? This is a price that is separated from the previous one. Our portal, we try to make our portal at the same time on the page, it has only one operation. In fact, if our portal is removed from the Kingston, it may be more important for the portal. In this case, we will divide it into two groups. In the future, our portal will include a portal for our user system and a portal for our service. This is a script, a script that is made through the interface. On the right side, we can see that we have some training services that will be implemented by the NOVA. We also have a service that will be implemented by KBS. The basic application process for a user is, first of all, it has a download action. After it releases a user password, it will be sent to Kingston, and then it will be sent to the Kingston. At this time, it will receive a token. After receiving a token, it will be used by the portal for the service, whether it is a training service or a software service. After the application is done, we don't need to talk about the NOVA. This is a standard process. If it is for Kubernetes, it can send the token to Kingston to the KBS service. We know that the KBS service is not supported by the original KBS. At this time, you need to use the battery token to add a webhook to the token. In this way, it can implement the connection process. The whole connection process is a process like this. There may be another question. This is what Kubernetes does. How do we do OpenShift? The process of OpenShift is different. Why? Because OpenShift does not accept an external token as its input. It has an awesome token. It has its own system. So it will be more complicated to implement in it. If we talk about OpenShift, let's look at the next question. I just drew this picture. It is a model without an SSO and without a gateway. Next, we will talk about the need to make some enhancements in Kingston. Let's take a look at some enhancements in Kingston. The first one is the security strategy. These security strategies include the smallest password density and the password sensitivity. Although Kingston is already in the configuration file, it can already do these things. However, it is not exposed in the API. When a manager needs to change its password strategy, it needs to provide an API to the portal to use on the ground. There is also the need for a password and a password failure control. There is also the need for a password to be introduced. These are needed. There is also a function called the password strategy. It includes controlling the IP address to our cloud system. There is also a function that does not allow the password to be introduced. There is also the need for a session to idle timeout. There is also the need for a log-in of some policies, including drawing and printing. Kingston does not have this part. We need to provide this function at the top of the list. In fact, besides drawing and printing, you also need to do some work in Kingston. There is also a function that does not allow the password to be introduced to your mobile phone or to your mailbox. You need to do it yourself. Let's take a look. When we have an ISO, there is a kind of scene. This scene is similar, but the only difference is that in this place, in the first place in the log-in, you need to create a token. It needs to be transferred once at night. After transferring the ISO, you can use SAM or OPD Connect to get the token. The next step is to return it to the portal. This is the only disadvantage. In fact, Kingston can also transfer the third place to the third place other than the third place. It can also connect to IL-DAF. When it connects to IL-DAF, it uses IL-DAF as a user system for data balance. In Kingston, it can also connect to Kerberos. Kerberos can also connect to the digital system. For these digital systems, Kerberos can connect to the external Kerberos to make a connection. Of course, this connection has a little bit of a difference in the connection of the ISO. When you connect to the ISO, it is designed to switch at night. When you connect to Kerberos or the digital system, it uses the external as an API. Let's take a look. In the design, we often use the network network. Let's take a look at the network system. In the design, it has a little bit of a difference. When we connect to the network, we don't want to send messages directly to Kingston. We want to send messages directly to Kingston via a gateway. When we use the portal, it also uses the gateway. In the gateway, it will use the token to exchange. When the exchange is done, it will use the gateway to call the service. In the future, it will need to check if there are any changes. In fact, you can decide based on your own safety. There are two ways of changing. The first is whether we need to increase the gateway within the network. This is a choice. There is another way of choosing. When we send a message via the gateway, the token needs to be called now. The latter part is totally trustworthy. The design is totally based on your safety. That's all I'm talking about. If you have any questions, you can contact me after the speech. Thank you for your time.