Kerberos bill confidentiality enhancement method based on HashCorp Vault

Abstract

The invention discloses a Kerberos bill confidentiality enhancement method based on HashCorp Vault, and the method comprises the following steps: 1), building a docker cloud environment, building a main Kerberos server side, a standby Kerberos server side and a Kerberos client side, and adding a database management main body; (2) distributing users and keytab key files based on a kernel domain at the main Kerberos server and the standby Kerberos server, creating a host main body of the KDC server, and authorizing the users; 3) configuring a KDC server, creating a total node host main body, configuring a file to a standby node, creating an access control list file, starting a KDC daemon process, and transmitting a kernel database to a subordinate KDC server; (4), a HashCorp Vault is installed and verified on a Kerberos client side, and a Transsit engine and an encryption key are self-defined; (5) the Kerberos client side carries out bill request operation on the Kerberos server side, encrypts a TGT bill, sends the encrypted TGT bill to an encryption API of Vault and analyzes a returned ciphertext, and when the Kerberos client side carries out next request operation on the Kerberos server side through the bill, the bill is decrypted and verified and then sent to the Kerberos server side; the method has the characteristics of low single-point failure rate and high bill confidentiality.

Description

Technical Field

[0001] The present invention belongs to the technical field of bill encryption, and particularly relates to a method for enhancing the confidentiality of kerberos bills based on HashiCorp Vault. Background Art

[0002] In the field of information technology, with the continuous expansion and complication of various application scenarios, the requirements for data security and identity authentication management are becoming increasingly stringent.

[0003] HashiCorp Vault, as an advanced dynamic key management system, focuses on the management of sensitive information such as passwords, keys, and certificates, and at the same time provides encryption services with identity authentication and authorization protection. It constructs a centralized key management system, helping developers to encrypt, access control, and automate the management process of sensitive data, significantly improving the security and compliance standards of data. With the Traisit secret engine, command-line interface (CLI), certificates, or user interface (UI) provided by Vault, sensitive data can be securely stored and managed under a strict control mechanism. Vault creates a unified operation interface for various secret information, simultaneously implements strict access control policies, and detailedly records audit logs. By providing a secure encrypted storage platform, it builds a solid security defense line for data access. This system supports the storage of various data types, such as API keys, database passwords, and certificates, etc., which can be safely saved. It is worth mentioning that Vault can dynamically generate short-term valid access credentials. Taking the database user scenario as an example, it can generate credentials with a short validity period, greatly reducing the security risks caused by the abuse of long-term credentials. Moreover, Vault can also properly manage the temporary credentials of mainstream cloud platforms such as AWS, Azure, and GCP. Its "encryption as a service" function can perform encryption and decryption operations on sensitive data within the application, eliminating the burden on developers to build complex encryption logics by themselves. Vault supports symmetric encryption and asymmetric encryption at the encryption technology level, and can also perform data signing and verification. In terms of key management, it supports generating independent keys for each application and automatically rotating them regularly, effectively reducing the potential risks caused by key leakage and the use of expired keys. In addition, Vault is compatible with multiple authentication methods, covering LDAP, OAuth, Kubernetes, AWS IAM, etc., facilitating users to flexibly choose the appropriate authentication means according to different application environments.

[0004] As a classic network authentication protocol, Kerberos plays an important role in computer network environments in achieving secure authentication and authorization management. This protocol uses symmetric key cryptography technology and completes the authentication process through a ticket exchange mechanism. It encrypts and decrypts tickets with pre-shared keys, effectively ensuring the security of the authentication process. When a user logs in to the system, the Kerberos server generates an encrypted ticket for the user to access network services based on this architecture. Kerberos adopts a centralized identity management model and relies on a trusted third-party authentication server - the Key Distribution Center (KDC) to issue tickets and verify user identities. Among them, the KDC consists of two parts: the Ticket Granting Ticket (TGS) and the Authentication Server (AS). The AS is responsible for authenticating the client's identity and issuing the Ticket Granting Ticket (TGT) for the client to access the TGS. This centralized management model simplifies the complexity of identity management work to a certain extent.

[0005] Docker container technology was developed and launched by Google. It realizes the encapsulation and isolation of processes based on cgroup and namespaces of the Linux kernel and is developed using the GO language. This technology greatly reduces the cost of container creation and maintenance and shows more significant advantages in portability and speed compared with traditional virtual machine technology. Docker has a series of outstanding features: in terms of resource utilization, it can allocate system resources more efficiently; in terms of startup speed, it has a shorter startup time; in terms of the running environment, it provides highly consistent environment configurations, facilitating maintenance and expansion operations; and it performs well in the continuous delivery and deployment process and is easy to implement migration operations.

[0006] However, the traditional Kerberos protocol has exposed many drawbacks in actual applications. On the one hand, its authentication mechanism highly depends on a single centralized KDC (authentication center), which makes the system have a single point of failure risk. More seriously, there are currently "Golden Tickets" and "Silver Tickets" forged for the Kerberos protocol.

[0007] (Silver Ticket) means are difficult to be effectively identified. In an Active Directory (AD) environment, attackers can use these forged tickets to impersonate legitimate users, successfully bypass the authentication process, and obtain unauthorized access rights. These two types of forged tickets make the traditional Kerberos system that relies on tickets for interaction vulnerable to attacks, resulting in a reduction in the security level of this authentication protocol and affecting the security of the entire system architecture. Specifically, a golden ticket is a forged ticket for the Ticket Granting Ticket (TGT), and the TGT is issued by the AS server of Kerberos and is used for a user to request access to a specific service from the Ticket Granting Service (TGS). Attackers can use the golden ticket to generate TGTs without limit within the domain, and then impersonate any user to obtain domain permissions, achieving long-term and persistent control within the domain. A silver ticket is a forgery of the Service Ticket, which is issued by the TGS and is used for user authentication when calling a service. Attackers can bypass the KDC verification with the silver ticket and directly interact with the target service. Although the scope of permissions is more limited than that of the golden ticket, due to bypassing the logging and auditing mechanisms, it has stronger concealment and poses a great threat to system security. Tracing back to the root cause, the emergence of these security risks stems from the lack of a dynamic security encryption and storage mechanism during the operation of Kerberos.

[0008] Meanwhile, with the wide popularization of cloud computing, containerization (such as Docker), and microservices architecture, the traditional Kerberos protocol faces a series of new challenges. In a dynamic environment, key management work becomes extremely complex and difficult to adapt to the dynamic change requirements of the environment; in terms of container lifecycle management, it cannot be well adapted to the containerized environment; in the service expansion scenario, it is difficult to effectively cope with the management problems brought about by the expansion of the service scale. Summary of the Invention

[0009] To overcome the deficiencies of the above-mentioned prior art, the purpose of the present invention is to provide a method for enhancing the confidentiality of Kerberos tickets based on HashiCorp Vault, which adopts a distributed Kerberos ticket management system and a method for dynamically encrypting Kerberos tickets based on the Transit engine in HashiCorp Vault, and has the characteristics of solving the single point of failure of the Kerberos protocol and the confidentiality of tickets.

[0010] To achieve the above purpose, the technical solution adopted by the present invention is: a method for enhancing the confidentiality of Kerberos tickets based on HashiCorp Vault, including the following steps:

[0011] The technical solution adopted by the present invention is a method for enhancing the confidentiality of Kerberos tickets based on HashiCorp Vault, which specifically includes the following steps:

[0012] Step 1, build a Docker cloud environment, establish a primary Kerberos server, a standby Kerberos server, and a Kerberos client, configure the primary Kerberos server, the standby Kerberos server, and the Kerberos database, and add a database management principal;

[0013] Step 2, operate on the primary Kerberos server and the standby Kerberos server established in Step 1, allocate users based on the Kerberos domain and keytab key files, create a KDC server host principal, and authorize the users;

[0014] Step 3, configure the KDC servers of the primary Kerberos server and the standby Kerberos server, create a full set of node host principals, synchronize the configuration files to the standby nodes, create an access control list file, configure and start the KDC daemon process, and the Kerberos database is propagated from the primary KDC server to the subordinate KDC server through the Kerberos daemon process;

[0015] Configure scheduled full synchronization, write a synchronization shell script, and configure a crontab scheduled task for the primary Kerberos server;

[0016] Step 4, install and verify HashiCorp Vault on the Kerberos client, enable the Transit secret engine, and customize the Transit engine and encryption keys;

[0017] Step 5, use the Kerberos client to perform a TGT ticket request operation on the Kerberos server, interact with the HTTP API of Vault using the HTTP library of C++, monitor the files in the / tmp / directory. When the Kerberos client requests and obtains the ticket, read the ticket, encode the TGT ticket using Base64, call the Transit engine of Vault to encrypt the TGT, send the encrypted TGT ticket data to the encryption API of Vault, and parse the returned ciphertext. This ciphertext is loaded into the memory of the program. When the Kerberos client uses the ticket to perform the next request operation on the primary Kerberos server, decrypt and verify the ticket and then send it to the Kerberos server.

[0018] The key management of the Transit engine supports dynamic key rotation.

[0019] For the described secret key, centralized key management of Vault is adopted.

[0020] For the described HashiCorp Vault, its API is encapsulated in a function.

[0021] The beneficial effects of the present invention are as follows: The traditional Kerberos protocol uses a single centralized KDC (authentication center) and the symmetric encryption algorithm DES to solve the problems of ticket request distribution and encryption. There are limitations such as single point of failure and low stability and security due to the vulnerability of tickets to be forged. Different from the ticket request distribution architecture and encryption method of the traditional Kerberos protocol, the present invention adopts a distributed Kerberos ticket management system and a method of dynamically encrypting Kerberos tickets based on the Transit engine in HashiCorp Vault to solve the problems of single point of failure and low confidentiality of Kerberos tickets in the Kerberos protocol. The deployed distributed Kerberos ticket management system uses HashiCorp Vault to dynamically encrypt and confidentially store Kerberos tickets. The distributed architecture design allows Vault to be deployed on multiple nodes, thereby enhancing high availability and fault tolerance. Even if a certain node fails, the system can still continue to run, and provide Kerberos ticket and key management functions through other nodes. Vault can be deployed across multiple data centers or cloud environments to improve the reliability of the system. Vault provides dynamic credential and key rotation functions, making key management more automated and efficient. Each container can dynamically obtain Kerberos tickets from Vault as needed and can be updated regularly (for example, automatically rotate Kerberos keys and tickets). This dynamic management can effectively reduce the risk of key leakage and ensure that tickets are always kept up-to-date and secure. It solves the problem that in the current Kerberos ticket encryption and storage process, if an attacker needs to obtain the administrator account of the Domain Controller, KRBTGT is the key used to issue TGT in Active Directory. If it is obtained by the attacker, any valid TGT can be generated. Or the attacker needs to obtain the service account hash of the target service (usually the NTLM hash or password), such as the service account of a specific service. Obtaining the hash of the service account allows the attacker to generate a forged Service Ticket. It provides a defense method against the above two behaviors of forging tickets, and through the distributed KDC architecture, the single point of failure (SPOF) can be effectively reduced, and failover and master-slave switching can be carried out in a timely manner, enhancing the reliability and disaster tolerance of the system.

[0022] The present invention relates to a method for enhancing the confidentiality of Kerberos tickets based on HashiCorp Vault, which is an improvement and optimization of the ticket interaction and security encryption of the traditional Kerberos architecture, and improves the security of the traditional tickets in encryption and storage. The Docker container environment can ensure the consistency of the master-slave KDC configuration. By mounting the configuration file and setting environment variables, centralized management of the master-slave KDC configuration files can be achieved. The slave KDC will regularly synchronize the data in the master KDC, including user identity information, keys, and other information. Even if the master KDC fails, as long as the slave KDC maintains the latest data, it can quickly resume the authentication service. Vault provides an "encryption as a service" function, and applications can directly use the encryption and decryption services of Vault Transit through the API, making the protection of sensitive data at the application layer more convenient and secure. The encryption as a service of Vault is combined with Kerberos authentication to increase the encryption and storage security of tickets.

[0023] Compared with the traditional Kerberos operation process that fails to add dynamic security encryption and storage of tickets, the method for enhancing the confidentiality of Kerberos tickets based on HashiCorp Vault of the present invention includes at least two KDC containers responsible for account generation, key distribution, and certificate signing, and a client storage host for requesting and dynamically encrypting tickets. Based on this distributed KDC database, at least two KDC servers implement synchronization daemon services, as well as operations such as synchronization configuration, listening to each node service, and database "propagation". The Kerberos client adds support for ticket functions based on HashiCorp Vault, converts the ticket binary data into text format, confuses the data, customizes dynamic encryption algorithms and modes, and performs dynamic encryption and decryption operations by calling the Transit API. The overall architecture deploys the KDC of distributed Kerberos, calls the Transit encryption engine to dynamically encrypt and store the obtained tickets, improving the overall reliability and security of the architecture.

[0024] The main technical pain point to be solved is that compared with the encrypted storage of traditional bills, the Kerberos TGT bill is encrypted through the Transit engine of HashiCorp Vault, encrypted before storing or transmitting sensitive credentials, and unauthorized access is prevented. The Transit engine key management supports dynamic key rotation, enhancing the security of the key. Encapsulating the calls to the Vault API in functions makes the code more modular. HashiCorp Vault provides management functions such as access logs and access control policies, facilitating administrators to monitor the encrypted use of Kerberos tickets and meet compliance requirements. The Transit engine supports dynamic key rotation. Without affecting the Kerberos authenticator, key rotation can be smoothly implemented through Vault to ensure the continuity and security of data protection. In the master-slave KDC mode, when the master KDC fails, the system can automatically forward authentication requests to the slave KDC. In this way, the authentication service will not be interrupted, and users and services can still continue to obtain authentication support, avoiding system downtime and service unavailability.

[0025] The solution to the technical problem of the present invention is that since the current Kerberos ticket is easily forged into a golden ticket and a silver ticket to attack the entire domain or a specific service, a distributed master-slave KDC is used for ticket granting. Docker containers can provide an independent running environment, isolating the Kerberos server from the host system and avoiding dependency conflicts between different applications. The Kerberos ticket is encrypted through the Transit engine of HashiCorp Vault, and the encryption operation is completed before storing or transmitting sensitive credentials, preventing attackers from achieving unauthorized access and enhancing the data security during network transmission.

[0026] The method of the present invention can enhance and optimize the ticket security of the Kerberos architecture, and improve the availability and fault tolerance of the Kerberos server. In the master-slave KDC mode, when the master KDC fails, the system can automatically forward the authentication request to the slave KDC. In this way, the authentication service will not be interrupted, and users and services can still continue to obtain authentication support, avoiding the situation where service requests cannot be obtained due to system downtime. Encrypt the Kerberos TGT ticket through the Transit engine of HashiCorp Vault, and encrypt it before storing or transmitting sensitive credentials to prevent unauthorized access. The Transit engine key management supports dynamic key rotation, enhancing the security of the key. Through the encryption support of an external service (Vault), the Kerberos client code does not directly manage the encryption key. The Transit engine supports dynamic key rotation. Without affecting the Kerberos verifier, key rotation can be smoothly implemented through Vault to ensure the continuity and security of data protection. BRIEF DESCRIPTION OF THE DRAWINGS

[0027] Figure 1 It is a flowchart of a method for enhancing the confidentiality of Kerberos tickets based on HashiCorp Vault according to the present invention.

[0028] Figure 2 It is an implementation architecture diagram of Kerberos ticket security enhancement based on HashiCorp Vault in a highly available cloud environment. DETAILED DESCRIPTION OF THE EMBODIMENTS

[0029] The following further details the method for enhancing Kerberos tickets based on HashiCorp Vault according to the present invention in conjunction with the accompanying drawings and specific implementation manners.

[0030] As shown in Figure 1As shown in the figure, in step 1, build a Docker cloud environment. Based on the basic container image, establish a primary Kerberos server, a standby Kerberos server, and a Kerberos client. Configure the primary Kerberos server, the standby Kerberos server, and the Kerberos database. Download and install the Kerberos server software (krb5-admin-server) and kdc (krb5-kdc) in both the primary Kerberos server and the standby Kerberos server. Create a new domain, add a database management principal, set permissions for the database management principal, restart the Kerberos management service, and use kinit to test the new management principal. Install Docker containers and Docker Compose in both the primary Kerberos server and the standby Kerberos server. Create a custom Docker-kerberos image. To enable communication between the Docker containers where the primary Kerberos server and the standby Kerberos server are located and the Kerberos client container, create a custom Docker network, assign IPs and hostnames for the required functions. Based on the Docker containers, create the principals corresponding to the primary Kerberos server, the standby Kerberos server, and the Kerberos client.

[0031] In step 2, operate on the primary Kerberos server and the standby Kerberos server established in step 1. Initialize the KDC database, add a database management principal, create the KDC server host principal, authorize users, add the management principal (i.e., the principal with the right to manage the Kerberos database) to the Kerberos database. Add at least one principal for further management communication between the kadmind and kadmin programs over the network. Create a local directory to store the primary KDC configuration file, create the krb5.conf and KDC.conf configuration files, (create the principals corresponding to the primary Kerberos-Server, the standby Kerberos-Server, and the Kerberos client) generate the keytab file, copy the configuration file to the standby node, create an access control list (ACL) file, and add the administrator's Kerberos principal to it. The access control list (ACL) file is used by the Kerberos daemon to control which principals can view and modify the Kerberos database files.

[0032] Step 3: Propagate the main Kerberos server database to the standby Kerberos server. Export the backup data on the primary node, and then synchronize the backup data to the standby node. The standby Kerberos database already has a copy of the main Kerberos database. Start the KDC daemon process of krb5, and configure the standby Kerberos database to propagate from the main Kerberos database through the KDC daemon process. The primary node writes a synchronization script, sets the timestamp variable, defines the IP addresses of the main Kerberos server and the standby Kerberos server, checks and generates a database backup, performs the synchronization operation, and records the synchronization result;

[0033] Step 4: Install HashiCorp Vault and initialize it. Log in to Vault in the Kerberos client, create an encrypted key file, enable the Transit secret engine, set the Vault address and authentication, set the environment variable on the Kerberos client to point to the Vault server address, and the Kerberos client uses the Token to interact with Vault;

[0034] Step 5: The Kerberos client requests a TGT ticket and stores the TGT ticket in the / tmp / directory. The program reads and verifies the TGT ticket from / tmp / krb5cc_tgt. If the verification fails, it requests to read again. If the verification is successful, it uses the C++ HTTP library to interact with the HTTP API of Vault. The Transit engine requires that the input plaintext data must be Base64-encoded. Through Base64 encoding, the ticket is converted into an ASCII string; send an HTTP POST request to the Vault API using libcurl and process the returned JSON response; send the TGT ticket data to the encryption API of Vault and encrypt the TGT using the Transit engine of Vault; parse the returned ciphertext. After calling the encryptWithVault function, the program will get the encrypted ciphertext, which exists in the program's memory; when the Kerberos client needs to send a ticket to the Kerberos server to request the next service, set the Vault transport decryption API URL, prepare the JSON data for Vault, execute the request and parse the JSON response in Vault, decrypt and then verify the ticket, call the Kerberos library (krb5_verify_checksum()) to verify the encrypted signature of the ticket to ensure it has not been tampered with; parse the timestamp fields (starttime, endtime) in the ticket, check whether the current time is within the valid period. If the verification is successful, send the TGT ticket to the Kerberos server. If the verification fails, discard the ticket and perform the request operation again.

[0035] In step 3 described above, the distributed architecture of Kerberos can be redundantly deployed on multiple nodes, enhancing high availability and fault tolerance. If a standby Kerberos server fails, it can quickly switch to other nodes to continue working. In addition, the Kerberos database can achieve disaster recovery and redundancy across data centers, thereby improving the reliability of the system. The distributed Kerberos solution can improve the high availability, security, and flexibility of the system.

[0036] In step 5, the Kerberos TGT ticket is encrypted through the Transit engine of HashiCorp Vault. Encryption is performed before storing or transmitting sensitive credentials to prevent unauthorized access. The Transit engine key management supports dynamic key rotation, enhancing key security. Instead of relying on local key storage or embedding keys in the code, the centralized key management of Vault is used, which simplifies encryption management and improves overall security. Encapsulating the calls to the Vault API in functions makes the code more modular and convenient for subsequent expansion. If other encryption services are used in the future, only the encryption and decryption functions need to be replaced. The Transit engine supports dynamic key rotation. Without affecting the Kerberos verifier, key rotation can be smoothly achieved through Vault, ensuring the continuity and security of data protection.

[0037] As Figure 2 shown, it is an architecture diagram of Kerberos ticket enhancement based on HashiCorp Vault in a distributed architecture in a cloud environment. The architecture diagram is divided into two functions, namely the distributed server (KDC + KADMIN) and the Kerberos ticket security enhancement based on HashiCorp Vault. It is implemented by two servers, a primary and a standby Kerberos server, and at least one Kerberos client.

[0038] The client requests a service ticket from the KDC. The client sends its username to the AS (Authentication Server) of the KDC. After verification, the AS (Authentication Server) generates a TGT and sends it to the client. The client uses the TGT to request a service ticket from the TGS (Ticket Granting Server). The client uses the service ticket to access the service. The client sends the service ticket to the server, and the server provides the service after verifying the ticket. Distributed Kerberos ensures the continuous availability of Kerberos-based services. Each KDC contains a copy of the Kerberos database. The master KDC contains a writable copy of the Realm database, which it replicates periodically. All database changes are created on the master KDC. The slave KDC provides the Kerberos Ticket Granting Service instead of database management in case the master KDC is unavailable.

[0039] For the Kerberos ticket security enhancement system of HashiCorp Vault, the client sends a ticket granting request to the server, listens to the / tmp / directory files. When the Kerberos client requests a ticket, it reads the ticket, encodes the TGT ticket using Base64, and calls the Transit engine of Vault to encrypt the TGT ticket. It sends the data to the encryption API of Vault and parses the returned ciphertext. This ciphertext is loaded into the program's memory. When the client needs to use this TGT ticket to make the next request to the Kerberos server, it decrypts the ticket and then sends it. The distributed Kerberos solution based on Docker and encrypted tickets through HashiCorp Vault can provide higher flexibility, security, and scalability in modern dynamic containerized environments. Its advantages include high availability and fault tolerance, dynamic credential and key management, support for multi-cloud and cross-environment deployment, encrypted storage and ticket security, and flexible access control policies, etc. Compared with traditional Kerberos, it can better adapt to scenarios with higher security requirements.

[0040] HashiCorp Vault provides dynamic credential and key rotation capabilities, enabling automated processes and efficient operation for key management. In a Docker-based distributed environment, each container can dynamically obtain Kerberos credentials from Vault as needed and can be updated regularly. This dynamic management can effectively reduce the risk of key leakage and always ensure that the credentials are freshly obtained, confirming their security. HashiCorp Vault offers an "encryption as a service" function that can encrypt and store Kerberos tickets and credentials and manage them according to policies. Vault stores tickets and keys in an encrypted storage backend, accessible only to authorized users and services, thus avoiding the risk of leakage of credentials and tickets. Through Vault's key management, the encrypted storage and access control of credentials and tickets can be more stringent and fine-grained. Vault provides powerful auditing capabilities that can record every key request, credential acquisition, key rotation, etc. in real time. In addition, Vault's access control system allows role-based access control (RBAC), ensuring that only authorized users and services can access specific keys or credentials, further enhancing security. The system provides a more flexible and fine-grained access control mechanism. Through policy definition and authentication mechanisms, access control policies can be dynamically adjusted according to multiple dimensions such as services, roles, and environments.

Claims

1. A method for enhancing the confidentiality of Kerberos tickets based on HashiCorp Vault, characterized in that: The steps include: Step 1: Build a Docker cloud environment, create a primary Kerberos server, a backup Kerberos server, and a Kerberos client, configure the primary Kerberos server, the backup Kerberos server, and the Kerberos database, and add a database management subject; Step 2: Operate on the primary Kerberos server and the backup Kerberos server established in step 1, allocate users and keytab key files based on the Kerberos domain, create a KDC server host principal, and authorize the user; Step 3: Configure the KDC servers of the primary and backup Kerberos servers, create the host principal of the full node, synchronize the configuration file to the backup node, create the access control list file, configure and start the KDC daemon, and propagate the Kerberos database from the primary KDC server to the slave KDC server through the Kerberos daemon; Configure scheduled full synchronization, write synchronization shell scripts, and configure crontab scheduled tasks on the primary Kerberos server; Step 4: Install and authenticate HashiCorp Vault on the Kerberos client, enable the Transit secret engine, and customize the Transit engine and encryption keys. Step 5, the kerberos client performs a ticket request operation on the kerberos server, uses the C++ HTTP library to interact with the Vault HTTP API, and monitors the / tmp / directory files. After the kerberos client requests and obtains the ticket, it reads the ticket, encodes the TGT ticket using Base64, calls the Vault Transit engine to encrypt the TGT, sends the encrypted TGT ticket data to the Vault encryption API, and parses the returned ciphertext, which is loaded into the program's memory. When the kerberos client uses the ticket to make the next request operation to the primary Kerberos server, the ticket is decrypted and verified and then sent to the Kerberos server.

2. According to claim 1, a method for enhancing confidentiality of kerberos tickets based on HashiCorp Vault, characterized in that: The Transit engine key management supports dynamic key rotation.

3. According to claim 1, a method for enhancing confidentiality of kerberos tickets based on HashiCorp Vault, characterized in that: The secret key described above adopts Vault's centralized key management.

4. The method for enhancing the confidentiality of kerberos tickets based on HashiCorp Vault according to claim 1, characterized in that: The HashiCorp Vault API is encapsulated in functions.

Images