CN114666131A - Certificate management system, certificate management method and certificate management system construction method - Google Patents
Certificate management system, certificate management method and certificate management system construction method Download PDFInfo
- Publication number
- CN114666131A CN114666131A CN202210288028.4A CN202210288028A CN114666131A CN 114666131 A CN114666131 A CN 114666131A CN 202210288028 A CN202210288028 A CN 202210288028A CN 114666131 A CN114666131 A CN 114666131A
- Authority
- CN
- China
- Prior art keywords
- cluster
- manager
- grid
- certificate
- local
- Prior art date
- Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
- Pending
Links
- 238000007726 management method Methods 0.000 title claims abstract description 83
- 238000010276 construction Methods 0.000 title abstract description 8
- 238000000034 method Methods 0.000 claims description 40
- 238000005192 partition Methods 0.000 claims description 4
- 238000005304 joining Methods 0.000 claims description 3
- 238000012423 maintenance Methods 0.000 abstract description 27
- 239000003795 chemical substances by application Substances 0.000 description 57
- 230000006854 communication Effects 0.000 description 33
- 238000004891 communication Methods 0.000 description 33
- 230000006870 function Effects 0.000 description 21
- 238000003860 storage Methods 0.000 description 9
- 238000010586 diagram Methods 0.000 description 8
- 230000008569 process Effects 0.000 description 6
- 230000008878 coupling Effects 0.000 description 5
- 238000010168 coupling process Methods 0.000 description 5
- 238000005859 coupling reaction Methods 0.000 description 5
- 238000005516 engineering process Methods 0.000 description 5
- 239000000243 solution Substances 0.000 description 5
- 238000013475 authorization Methods 0.000 description 4
- 238000004590 computer program Methods 0.000 description 4
- 238000011161 development Methods 0.000 description 4
- 238000012545 processing Methods 0.000 description 4
- 238000012360 testing method Methods 0.000 description 4
- 238000012795 verification Methods 0.000 description 3
- 230000000712 assembly Effects 0.000 description 2
- 238000000429 assembly Methods 0.000 description 2
- 230000005540 biological transmission Effects 0.000 description 2
- 230000036541 health Effects 0.000 description 2
- 238000002347 injection Methods 0.000 description 2
- 239000007924 injection Substances 0.000 description 2
- 238000004519 manufacturing process Methods 0.000 description 2
- 230000007246 mechanism Effects 0.000 description 2
- 230000003287 optical effect Effects 0.000 description 2
- 230000001360 synchronised effect Effects 0.000 description 2
- 239000008186 active pharmaceutical agent Substances 0.000 description 1
- 230000006399 behavior Effects 0.000 description 1
- 230000009286 beneficial effect Effects 0.000 description 1
- 230000007175 bidirectional communication Effects 0.000 description 1
- 230000002457 bidirectional effect Effects 0.000 description 1
- 238000013500 data storage Methods 0.000 description 1
- 238000013461 design Methods 0.000 description 1
- 238000001514 detection method Methods 0.000 description 1
- 239000000835 fiber Substances 0.000 description 1
- 230000003993 interaction Effects 0.000 description 1
- 230000008520 organization Effects 0.000 description 1
- 238000013439 planning Methods 0.000 description 1
- 230000010076 replication Effects 0.000 description 1
- 238000013468 resource allocation Methods 0.000 description 1
- 239000004065 semiconductor Substances 0.000 description 1
- 239000007787 solid Substances 0.000 description 1
- 238000000638 solvent extraction Methods 0.000 description 1
- 230000003068 static effect Effects 0.000 description 1
- 238000006467 substitution reaction Methods 0.000 description 1
- 238000012546 transfer Methods 0.000 description 1
Images
Classifications
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L9/00—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
- H04L9/32—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials
- H04L9/3263—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials involving certificates, e.g. public key certificate [PKC] or attribute certificate [AC]; Public key infrastructure [PKI] arrangements
- H04L9/3268—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials involving certificates, e.g. public key certificate [PKC] or attribute certificate [AC]; Public key infrastructure [PKI] arrangements using certificate validation, registration, distribution or revocation, e.g. certificate revocation list [CRL]
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L63/00—Network architectures or network communication protocols for network security
- H04L63/08—Network architectures or network communication protocols for network security for authentication of entities
- H04L63/0823—Network architectures or network communication protocols for network security for authentication of entities using certificates
Landscapes
- Engineering & Computer Science (AREA)
- Computer Security & Cryptography (AREA)
- Computer Networks & Wireless Communication (AREA)
- Signal Processing (AREA)
- Computer Hardware Design (AREA)
- Computing Systems (AREA)
- General Engineering & Computer Science (AREA)
- Management, Administration, Business Operations System, And Electronic Commerce (AREA)
Abstract
The embodiment of the application provides a certificate management system, a management method and a construction method of the certificate management system. The system comprises: a global CA manager deployed at a control plane of the services grid, at least one cluster deployed at a data plane of the services grid, and a local CA manager contained in each cluster of the at least one cluster; the local CA manager in each cluster is used for managing the CA certificate of each component in the corresponding cluster; the global CA manager is used for managing the CA certificates of the components in each cluster in the at least one cluster. Through the cooperation of the global CA manager and the local CA manager, the hierarchical management of the multi-cluster certificates in a multi-cluster environment is realized, and the operation and maintenance complexity and the operation and maintenance cost are reduced.
Description
Technical Field
The present application relates to the field of computers, and more particularly, to a certificate management system, a certificate management method, and a method of constructing a certificate management system.
Background
The service grid as an infrastructure layer for cloud native application communication has become a common architectural model for transparent communication within user application services. The purpose of the service grid architecture model is to abstract the capabilities of the standard non-functional aspects of microservices and treat them as external Sidecar (Sidecar) components. The service grid schema may be defined by a control plane and a data plane. Among other things, the control plane (control plane) may be responsible for managing policies that will drive micro-service to micro-service communications. The data plane (data plane) may be responsible for implementing and executing the policies described by the control plane. It is an external component that implements all the non-functional functions we describe. The data plane consists of agents deployed as Sidecar. Traffic management, communication, security, and observability among services, etc. may be controlled by the Sidecar proxy per service instance.
The control plane of the service grid includes a certificate manager, which may manage certificates of components in the data plane of the service grid, such as issuing or updating certificates. Any one cluster can be deployed in a service grid mode, and when a plurality of clusters exist, a multi-cluster environment is generated. In a multi-cluster environment, when managing certificates of each component in a data plane of a service grid, a certificate manager of each cluster is responsible for issuing or updating certificates for local components. Therefore, the certificate managers need to be deployed for respective clusters, the workload of certificate management and maintenance is large, the operation and maintenance complexity is high, and higher operation and maintenance cost needs to be invested.
Disclosure of Invention
The application provides a certificate management system, a certificate management method and a certificate management system construction method, which aim to reduce workload, operation and maintenance complexity and cost of certificate management in a multi-cluster environment.
In a first aspect, the present application provides a certificate management system, comprising: a global Certificate Authority (CA) manager deployed at a control plane of the services grid, at least one cluster deployed at a data plane of the services grid, and a local CA manager included in each cluster of the at least one cluster; the local CA manager in each cluster is used for managing the CA certificate of each component in the corresponding cluster; the global CA manager is used for managing the CA certificates of the components in each cluster in the at least one cluster.
In a second aspect, the present application provides a certificate management method, which is applied to a certificate management system, where the certificate management system includes: a global CA manager deployed at a control plane of the services grid, at least one cluster deployed at a data plane of the services grid, and a local CA manager contained in each cluster of the at least one cluster; the method comprises the following steps: the global CA manager manages CA certificates of the components in each cluster in the at least one cluster; and the local CA manager in each cluster manages the CA certificate of each component in the corresponding cluster.
In a third aspect, the present application provides a method for constructing a certificate management system, which is applied in a service grid, where the service grid includes a data plane and a control plane, and the data plane of the service grid includes at least one cluster, and the method includes: deploying a local CA manager in each cluster of at least one cluster, wherein the local CA manager in each cluster is used for managing CA certificates of all components in the corresponding cluster; a global CA manager is deployed at a control plane of the services grid, the global CA manager being configured to manage CA certificates for components in each of the at least one cluster.
Based on the above solution, in one aspect, the CA certificates of the components in each cluster of at least one cluster are managed by a global CA manager deployed in a control plane of the service grid. On the other hand, by deploying a local CA manager in each of at least one cluster of the data plane of the service grid, the CA certificates of the respective components in the corresponding cluster are managed by the local CA manager. Therefore, by matching the global CA manager with the local CA manager, the multi-cluster certificate can be managed in a multi-cluster environment in a grading way, the workload of the local CA manager for certificate management can be reduced, the operation and maintenance complexity of a user is reduced, and the operation and maintenance cost is also reduced. Meanwhile, the convenience of CA certificate management can be improved through global unified management.
Drawings
Fig. 1 is a schematic view of a scenario of certificate management provided in an embodiment of the present application;
FIG. 2 is a diagram of a service grid architecture provided by an embodiment of the present application;
fig. 3 is a schematic block diagram of a certificate management system provided by an embodiment of the present application;
FIG. 4 is another schematic block diagram of a certificate management system provided by an embodiment of the present application;
fig. 5 is a flowchart illustrating a certificate management method according to an embodiment of the present application;
fig. 6 is a flowchart illustrating a method for constructing a certificate management system according to an embodiment of the present application;
fig. 7 is a schematic block diagram of an apparatus provided by an embodiment of the present application.
Detailed Description
The technical solution in the present application will be described below with reference to the accompanying drawings.
The technical scheme provided by the application can be applied to the field of cloud generation. The cloud is a distributed cloud based on distributed deployment and unified operation, a set of cloud technology product system established on the basis of technologies such as containers and micro services is a novel technology system, and the cloud is a future development direction of cloud computing.
The following is a brief explanation of the relevant terms to which this application relates.
1. Microservice (microservice): when a single application is divided into a set of small service components, it is called a microservice. Compared with the traditional single application mode, the micro-service architecture treats each micro-service as an independent entity/module, thereby fundamentally contributing to simplifying the maintenance of the code and the related infrastructure. Cloud native applications running on a microservice architecture may rely on the following components: container (docker) for efficient management and deployment by dividing services into multiple processes; orchestration, such as the kubernets platform, of available system resources for configuring, allocating, and managing services; a service mesh (service mesh), e.g., Istio, communicates between services through a service proxy mesh to connect, manage, and protect microservices. The micro-service architecture can develop and deploy each micro-service in the application program through different technology stacks, each micro-service can be optimized, deployed or expanded independently, and fault and error detection can be better processed. Therefore, the micro-service architecture is beneficial to the construction of complex large-scale application programs, is widely applied to the construction of small-scale application programs, and can meet the requirement of further expansion. In the embodiments of the present application, the micro service is referred to as an application service instance.
Since when a large application is decomposed into multiple micro-services, each micro-service may use a different technology stack, such as development language, database, etc., these environments need to form a complex architecture for management. While containerization helps manage and deploy individual microservices by partitioning each microservice to run in a separate container, communication between services is still very complex as the overall system operating conditions, fault tolerance, and multiple points of failure must be addressed. Thus, while these services theoretically remain as separate micro-modules, they need to interact with each other.
2. Kubernetes: abbreviated as K8s, is an open source container orchestration engine for managing containerized applications on multiple hosts in a cloud platform. The goal of K8s is to make deploying containerized applications simple and efficient, and K8s provides a mechanism for application deployment, planning, updating, and maintenance. In K8s, multiple containers can be created, each of which runs an application instance, and then management, discovery, and access to a group of application instances are realized through a built-in load balancing policy, and these details do not require complex manual configuration and processing by operation and maintenance personnel. K8s has the following characteristics: portability: support for public, private, hybrid, and multiple clouds (multi clouds); and (3) expandable: modularization, plug-in, mounting and combination; automation: automatic deployment, automatic restart, automatic replication, and automatic scaling/expansion.
3. Serving the grid: to ensure controlled service-to-service communication through multiple service grid proxies. In a service grid, service grid agents deployed with a single service may enable communication between services, which is widely referred to as a sidecar (sidecar) model, and are designed to handle any function of inter-service communication, such as load balancing, routing, service discovery, etc. In other words, the service grid deploys one service grid agent for each service, each service initiates a request using basic network functions and connects with the corresponding service grid agent, and communication between services is indirectly achieved through communication between the service grid agents and the service grid agents. For example, in the Istio service grid, Istio deploys one Istio agent next to each service, and the code of the service itself changes little or no. All inter-service traffic is directed to flow to the Istio agent, which uses policies to control inter-service communication while enforcing the basic policies of deployment, fault injection, and breakers. The Istio has the following core capabilities: securing inter-service communication by authentication and authorization; a policy layer supporting access control, resource quota and resource allocation; support for a hypertext transfer protocol (HTTP), a Transmission Control Protocol (TCP), a full duplex communication protocol based on TCP, and the like; metrics, logging and tracking of all traffic within a cluster, including ingress and egress of the cluster; inter-service communication is configured and controlled through failover, fault injection, and routing rules. The Istio is independent of any platform and can operate in a variety of environments, such as cloud, local, Kubernets, etc.
The services grid is composed of a control plane of the services grid and a data plane of the services grid. The data plane of the service grid may include at least one service and a service grid agent corresponding to the service. The control plane of the services grid may manage and maintain the components in the data plane of the services grid. Communication between services is enabled in the data plane of the services grid through communication between service grid agents. In the embodiments of the present application, the service grid agent is simply referred to as a grid agent.
When communication between services is indirectly achieved through communication between service grid agents, security of transmitted information needs to be ensured. Therefore, security authentication in the services grid is particularly important. The services grid may provide two types of identity authentication. One is transport identity authentication, also known as inter-service identity verification, which can be performed by a Transport Layer Security (TLS) protocol as a verification of transport identity. The other is source authentication, also known as end-user authentication. The two-way TLS authentication process comprises the following steps: the service grid rerouting outbound traffic from the client to the client agent; the client agent and the server agent start two-way TLS handshake, and during the handshake, the client agent also performs security naming check to verify a service account displayed in the server certificate; the client agent and the server agent establish bidirectional TLS connection, and the service grid forwards the flow from the client agent to the server agent; after authorization, the server proxy forwards traffic to the server's service over the local TCP connection.
4. The CA, a network organization that manages and issues security credentials and encryption information security keys. The registration center verifies the digital certificate provided by the applicant, and after CA verification, the certificate is issued, and the content includes the personal information, public key and authentication validity period of the applicant, which are used as the basis of the online identity certificate.
Fig. 1 is a schematic view of a scenario applicable to certificate management provided in an embodiment of the present application. In the scenario shown in fig. 1, a plurality of clusters, such as cluster a and cluster B, are included. Each cluster includes a control plane of the service grid and a data plane of the service grid, a control plane of the service grid is deployed with a service grid control plane component, and the service grid control plane component may include components such as a CA manager, network configuration, identity authentication, Application Programming Interface (API) service, and the like. Wherein the CA manager is used for managing CA certificates of each component in the data plane of the service grid. The data plane of the services grid is deployed with at least one workload, each workload comprising a plurality of components, such as grid agents and application service instances. For example, the data plane of cluster a includes workload a and workload B, where workload a includes grid agent a and application service instance a, and workload B includes grid agent B and application service instance B. Similarly, the data plane of the cluster B comprises a workload C and a workload D, the workload C comprises a grid agent C and an application service instance C, and the workload D comprises a grid agent D and an application service instance D. For any cluster, the application service instances in the cluster are connected with the corresponding grid agents through the basic network function, and the communication between the application service instances can be realized through the communication between the grid agents.
It should be understood that the clusters a and B and the workloads a to D shown in fig. 1 are only exemplary, and in this scenario, more or fewer clusters may be included, and more or fewer workloads may be included in each cluster, which is not limited in this application.
Figure 2 is a diagram of a service grid architecture suitable for use with embodiments of the present application. The service grid is mainly used for facilitating safe and reliable communication among a plurality of micro-services, and the micro-services are used for decomposing an application program into a plurality of smaller services or instances and are distributed on different clusters/machines to operate. It should be understood that any one of the clusters in FIG. 1 may be deployed under the services grid architecture shown in FIG. 2.
As shown in FIG. 2, a microservice may include an application service instance A and an application service instance B, which form a functional application layer of a service grid. In one embodiment, application service instance A runs on machine/workload container group A in the form of container/process A2 and application service instance B runs on machine/workload container group B in the form of container/process B2. In one possible implementation, the application service instance a may be, for example, a commodity inquiry service, and the application service instance B may be, for example, a commodity ordering service.
Further, application service instance A and grid agent A coexist in machine/workload container group A, and application service instance B and grid agent B coexist in machine/workload container group B. Mesh agent a and mesh agent B form the data plane layer of the service mesh. Grid agent A and grid agent B are operated in the form of container/process A1 and container/process A2, respectively, and can communicate with each other in two directions, and grid agent A and application service instance A can communicate with each other in two directions. In addition, there may be two-way communication between mesh agent a and mesh agent B.
In one embodiment, all traffic for application service instance A is routed through grid proxy A to the appropriate destination and all network traffic for application service instance B is routed through grid proxy B to the appropriate destination. It should be noted that the network traffic mentioned herein includes, but is not limited to, HTTP, REST, gRPC, Redis, and the like.
In one embodiment, the function of extending the data plane layer may be implemented by writing a custom filter for an agent (envoy) in the service grid, and the service grid agent configuration may be to enable the service grid to properly proxy service traffic, implement service interworking and service governance. Grid agent a and grid agent B may be configured to perform at least one of the following functions: service discovery (service discovery), health checking (health checking), routing (routing), load balancing (load balancing), authentication and authorization (authentication and authorization), and observability (observability).
Further, the service grid also includes a control plane layer. Where the control plane layer may be a group of services running in a dedicated namespace, these services are hosted by the control plane component at the machine/workload container group E. Wherein the control plane component is in bidirectional communication with mesh agent a and mesh agent B. The control plane components are configured to perform some of the functions of control management. For example, the control plane component receives telemetry data transmitted by mesh agent a and mesh agent B, which may be further aggregated. The control plane component may also provide user-oriented APIs to more easily manipulate network behavior, provide configuration data to grid agent a and grid agent B, and the like.
At present, when managing CA certificates of components in a data plane of each cluster, a CA manager of each cluster generally issues and maintains CA certificates for local components corresponding to each cluster, such as a grid agent and an application service instance. Since the management of the CA certificates of each component in the data plane is responsible for the CA managers of each cluster, users need to deploy the CA managers for each cluster, the workload of certificate management is large, and the operation and maintenance complexity is high, which means that users need to invest in high operation and maintenance cost.
In view of this, the present application provides a certificate management system, a management method, and a method for constructing a certificate management system. In one aspect, a CA certificate for each component in each cluster in at least one cluster in a services grid is managed with a global CA manager deployed in a control plane of the services grid. On the other hand, by deploying a local CA manager in each cluster of the data plane of the service grid, the CA certificates of the components in the corresponding cluster are managed by the local CA manager. Therefore, by matching the global CA manager with the local CA manager, the multi-cluster certificate can be managed in a multi-cluster environment in a grading way, the workload of the local CA manager for certificate management can be reduced, the operation and maintenance complexity of a user is reduced, and the operation and maintenance cost is also reduced. Meanwhile, the convenience of CA certificate management can be improved through global unified management.
The certificate management system provided by the embodiment of the present application will be described in detail below with reference to the accompanying drawings.
Fig. 3 is a schematic block diagram of a certificate management system according to an embodiment of the present application. As shown in fig. 3, the certificate management system includes: the CA manager system includes a global CA manager 111 deployed at a control plane 10 of the service grid, at least one cluster, e.g., cluster 21 and cluster 22, deployed at a data plane 20 of the service grid, and a local CA manager included in each cluster of the at least one cluster, e.g., the cluster 21 includes a local CA manager 211, and the cluster 22 includes a local CA manager 221. Wherein, at least one cluster deployed on the data plane of the service grid is uniformly managed by the control plane of the service grid, and the cluster can be a Kubernetes cluster.
It should be understood that the clusters 21 and 22 in the data plane 20 shown in fig. 3 are only exemplary, a greater number of clusters may be included in the data plane 20, and a lesser number of clusters may also be included, and the present application does not limit the number of clusters in the data plane 20.
Wherein the global CA manager 111 is configured to manage CA certificates of components in each cluster of at least one cluster.
In particular, the global CA manager 111 may manage CA certificates for components in each cluster in the data plane 20.
Alternatively, the global CA manager 111 may issue CA certificates for a first cluster newly added to the service grid and/or delete CA certificates for a second cluster removed from the service grid.
The first cluster is one instance of a cluster that newly joins the services grid and the second cluster is one instance of a cluster that is removed from the services grid. It is to be appreciated that the cluster newly added to the services grid can be one or more, as can the cluster removed from the services grid. This is not a limitation of the present application.
That is, the global CA manager 111 may issue CA certificates for the components in the cluster when a new cluster is added to the data plane 20, and/or the global CA manager 111 may delete CA certificates issued for the components in the cluster when an old cluster is removed from the data plane 20. For example, upon the cluster 22 joining the data plane 20, the global CA manager 111 may issue CA certificates for the components in the cluster 22. When the cluster 22 is removed from the data plane 20, the global CA manager 111 may delete the CA certificates issued to the components in the cluster 22.
The local CA manager in each cluster is used for managing the CA certificate of each component in the corresponding cluster.
In particular, the local CA manager may manage CA certificates for components in the local cluster. For example, the local CA manager 211 in the cluster 21 is used for managing CA certificates of components in the cluster 21, and the local CA manager 221 in the cluster 22 is used for managing CA certificates of components in the cluster 22. The management of the local CA manager on the CA certificate may be updating the CA certificate, or issuing the CA certificate for the components in the local cluster again when the CA certificate of the components is lost.
In the present application, the local CA manager may be a CA server maintained by the user, or may be a kubernets CA server operating in a cluster. The global CA manager may be a CA manager provided by a vendor, for example may be a CA manager provided by a cloud vendor. The local CA manager and the global CA manager are independent. For example, it may be deployed on different physical devices, and may even be deployed in different geographical locations. This is not a limitation of the present application.
Based on the above, in one aspect, the CA certificates of components in each cluster in the data plane of the services grid are managed by a global CA manager in the control plane of the services grid. On the other hand, the CA certificates of the components in the corresponding cluster are managed by a local CA manager in the data plane of the service grid. Therefore, by the cooperation of the global CA manager and the local CA manager, the hierarchical management of the multi-cluster certificate can be realized, the workload of the local CA manager for managing the certificate is reduced, the operation and maintenance complexity of the user is reduced, and the operation and maintenance cost is also reduced. Meanwhile, the convenience of CA certificate management can be improved through global unified management.
Fig. 4 is another schematic block diagram of a certificate management system according to an embodiment of the present application. As shown in fig. 4, the certificate management system may include the following components in addition to the aforementioned global CA manager 111, local CA managers, such as the local CA manager 211 and the local CA manager 221.
Optionally, the certificate management system further comprises a cluster manager 12 deployed at the control plane 10 of the services grid for generating a context of the first cluster when the first cluster joins the services grid and/or for deleting a context of the second cluster when the second cluster is removed from the services grid.
In particular, cluster manager 12 may include: a cluster adder 121, a cluster remover 122, and a cluster context 123. The cluster adder 121 is configured to add a new first cluster to the data plane 20, generate a context of the first cluster, and write the context of the first cluster into the cluster context 123. The cluster remover 122 is used to remove the old second cluster from the data plane 20 and remove the context of the second cluster from the cluster context 123. Cluster context 123 is used to store the context of each cluster.
The context may include configuration information of the cluster, such as an access address (e.g., an IP address) for accessing the cluster, access credentials, and the like, or may include other attribute information of the cluster, such as information of a region, a network, a security group, and the like where the cluster is located, or may even include an operating state of the cluster.
For example, when the cluster 22 is not included in the data plane 20 of the service grid, if the cluster 22 is added to the data plane 20, the cluster 22 may be added to the data plane 20 through the cluster adder 121. If it is desired to remove cluster 22 from data plane 20, then cluster 22 may be removed from data plane 20 by cluster remover 122.
Optionally, cluster manager 12 is also operative to provide an interface for users to add and/or remove clusters from the service grid.
Exemplary interface usage patterns include, but are not limited to, a User Interface (UI), a Command Line Interface (CLI), or an API, among others.
For example, cluster adder 121 may provide a cluster addition UI and cluster remover 122 may provide a cluster removal UI. When a new cluster is to be added to data plane 20, the user may join the new cluster to data plane 20 by triggering cluster adder 121 to cause the cluster addition UI to be displayed, entering the context of the desired cluster in the cluster addition UI. When an old cluster is to be removed from the data plane 20, the user may remove the old cluster from the data plane 20 by triggering the cluster remover 122 to cause the cluster removal UI to be displayed, entering the context of the cluster desired to be removed in the cluster removal UI.
It should be understood that the specific implementation of providing cluster addition or cluster removal functionality via CLI or API is similar to that described above and will not be described in detail herein.
Optionally, the local CA manager in each cluster is further configured to update the certificates of the components in the corresponding cluster based on the certificate life cycle of the components.
The certificate life cycle is understood to be the life of the certificate. When the usage period is exceeded, the certificate needs to be updated.
Specifically, the local CA manager may monitor the life cycle of the CA certificate of each component in the local cluster, update the expired CA certificate when the life cycle of the CA certificate of the component is found to be expired, and issue the updated CA certificate to the corresponding component. Or, when the life cycle of the CA certificate of the component expires, the component may send a certificate update request to the local CA manager, and the local CA manager, after receiving the request, issues the updated CA certificate to the corresponding component.
For example, assuming that the lifetime of a CA certificate of a certain component in the cluster 21 is from 2022 to 2022, and if the current lifetime of the CA certificate is 2022 and 3 months, the local CA manager 211 monitors that the CA certificate of the component exceeds the lifespan, the lifetime of the CA certificate corresponding to the component may be updated to be from 2022 to 2022 and 4 months, and then the updated CA certificate is issued to the corresponding component.
Optionally, the components in each cluster include one or more of: a grid proxy, an application service instance, and a local webhook controller.
The local webhook controller is used for checking the components in the local cluster, and determining whether the components meet the specification through checking.
Illustratively, the components in cluster 21 may include: a local webhook controller 213, a grid proxy 214, and an application service instance 215. The components in cluster 22 may include: a local webhook controller 223, a grid agent 224, and an application service instance 225.
It should be understood that the aforementioned global CA manager and local CA manager issue certificates for components in the cluster, which may be issued for local webhook controllers, grid agents, and application service instances in the cluster.
Optionally, the global CA manager 111 is further configured to, in the event that the local CA manager of the third cluster fails, update the certificate for each component in the third cluster based on the certificate life cycle of each component in the third cluster, where the third cluster is any one of the at least one cluster.
The third cluster is a cluster which fails to issue a CA certificate for the local component because the local CA manager in the cluster fails.
Specifically, although the local CA manager may guarantee maintenance of the CA certificate of the local component, when the local CA manager fails and fails to maintain the CA certificate of the local component, for example, fails to issue an updated CA certificate, the updated CA certificate may be issued by the global CA manager.
For example, the CA certificate of the grid agent 224 in the cluster 22 has exceeded the lifespan, but the local CA manager 221 happens to have failed, and cannot issue the updated CA certificate for the grid agent 224. At this time, the local CA manager 221 may send a certificate acquisition request to the global CA manager 111 to request the global CA manager 111 to issue an updated CA certificate for the grid agent 224. Since the cluster 22 is just joining the data plane 20 of the services grid, the CA certificates for the components in the cluster 22 are issued by the global CA manager 111. Therefore, the global CA manager 111 stores the old CA certificate issued to the grid agent 224, and after the global CA manager 111 updates based on the old CA certificate, the updated CA certificate can be issued to the grid agent 224.
Optionally, each cluster further includes a local controller connected to the global CA controller; the local CA manager of the third cluster is specifically configured to, in the event of a failure, obtain, by the local controller of the third cluster, the updated CA certificate from the global CA controller.
The local controller may serve as an interface between the local CA manager and the global CA manager, so that the local CA manager and the global CA manager communicate with each other. For example, the cluster 21 further includes a local controller 212, and the local controller 212 may serve as a communication interface between the local CA manager 211 and the global CA manager 111; also included in the cluster 22 is a local controller 222, which local controller 222 may act as a communication interface between the local CA manager 221 and the global CA manager 111.
Specifically, when the local CA manager does not fail, it is not connected to the local controller; the connection to the local controller is made only if the local CA manager fails. And when the local CA manager fails, the local CA manager can be connected with the local controller. Since the global CA manager remains connected to the local controller, the local CA manager can obtain updated CA certificates of corresponding components from the global CA manager through the local controller. For example, when the local CA manager 221 in the cluster 22 fails to issue the updated CA certificate to the grid agent 224, the local CA manager 221 switches to connect with the local controller 222, and sends a certificate acquisition request to the global CA manager 111 through the local controller 222, so that the global CA manager 111 issues the updated CA certificate to the grid agent 224 according to the certificate acquisition request.
It should be understood that the failure of the local CA manager means that the CA certificate cannot be issued for the local component, but its communication function is normal.
Optionally, the certificate management system further includes a global namespace manager 112 deployed at the control plane 10 of the service grid, and configured to divide the components in at least one cluster according to at least one preset namespace, so as to obtain a component belonging to each namespace in the at least one namespace, where each namespace in the at least one namespace corresponds to one service capability.
Therein, the global namespace manager 112 and the global CA manager 111 are both deployed in the global grid controller 11. The global grid controller 11 is used to divide the components in a plurality of clusters and manage the CA certificates of the components in each cluster in at least one cluster.
Specifically, the user may define at least one namespace in advance, for example, three namespaces of development (dev), test (test), and production environment (production) may be set in advance. The global namespace manager 112 can partition the components into corresponding namespaces based on the characteristics of the components in the cluster. For example, the namespace manager 112 performs namespace partition on the application service instances in the cluster 21 and the cluster 22, and if the application service instance 215 belongs to an instance in a development phase, the application service instance 215 is partitioned into "dev", and if the application service instance 225 belongs to an instance in a test phase, the application service instance 225 is partitioned into "test". For another example, the user may also define two namespaces of finance (finance) and sales (sales) in advance, and divide the components belonging to the finance type into "finance" and the components belonging to the sales type into "sales".
Further, after the user defines a plurality of namespaces in advance, the service capability of each namespace can be set. The service capability may refer to a Central Processing Unit (CPU) size, a memory size, an access right, and the like. After the global namespace manager 112 partitions the components in the plurality of clusters, the size of the CPU, the size of the memory, the access rights, and the like may be set for the components according to the service capabilities corresponding to the namespaces. It should be understood that the service capabilities of each namespace can be the same or different.
Optionally, the certificate management system further comprises one or more of the following components deployed at the control plane 10 of the services grid: API services, network configuration, identity authentication, and a global webhook controller.
In particular, the control plane 10 of the service grid may further comprise a service grid control plane component 13, the service grid control plane component 13 may at least comprise: API services, network configuration, identity authentication, and a global webhook controller.
The global webhook controller is used for checking other service grid control surface assemblies to judge whether the other service grid control surface assemblies meet the specification. Other services grid control plane components may be API services, network configuration, and identity authentication.
Optionally, the global CA manager 111 is also used to manage CA certificates of one or more components of the control plane.
In particular, global CA manager 111 may also issue and maintain CA certificates for each of the serving grid control plane components 13. For example, the global CA manager issues CA certificates for the global webhook controller and maintains updates of the CA certificates.
Based on the above solution, in one aspect, the CA certificates of the components in each cluster of at least one cluster are managed by a global CA manager deployed in a control plane of the service grid. In another aspect, the CA certificates for the components in the corresponding cluster are managed by a local CA manager deployed in each of at least one cluster of the data plane of the service grid. Therefore, through the cooperation of the global CA manager and the local CA manager, the hierarchical management of the multi-cluster certificate can be realized, the workload of the local CA manager for managing and maintaining the certificate is reduced, the operation and maintenance complexity of the user is reduced, and the operation and maintenance cost is also reduced. Meanwhile, the convenience of CA certificate maintenance can be improved through global unified management. And when the local CA manager fails, the global CA manager can be used for issuing the updated certificate for the component through the local controller, so that the timely issuing of the certificate is guaranteed.
In the above, the certificate management system provided in the embodiment of the present application is introduced, and the certificate management method provided in the embodiment of the present application is described below with reference to fig. 5.
Fig. 5 is a flowchart illustrating a certificate management method 500 according to an embodiment of the present application. The method 500 may include:
It should be understood that the present application does not limit the execution order of step 501 and step 502.
It should also be understood that the specific implementation of the method can refer to the foregoing description of fig. 3 and 4, and will not be described herein again.
It should also be understood that the certificate management method provided by the present application can be implemented based on the architecture shown in fig. 3 and 4, but the components shown in the drawings are merely divided for the convenience of distinguishing different functions, and should not constitute any limitation on the specific physical form.
Based on the above, in one aspect, the CA certificates of components in each cluster in the data plane of the services grid are managed by a global CA manager in the control plane of the services grid. On the other hand, the CA certificates of the components in the corresponding cluster are managed by a local CA manager in the data plane of the service grid. Therefore, by the cooperation of the global CA manager and the local CA manager, the hierarchical management of the multi-cluster certificate can be realized, the workload of the local CA manager for managing and maintaining the certificate is reduced, the operation and maintenance complexity of the user is reduced, and the operation and maintenance cost is also reduced. Meanwhile, the convenience of CA certificate maintenance can be improved through global unified management.
The method for constructing the certificate management system according to the embodiment of the present application is further described below with reference to fig. 6.
Fig. 6 is a flowchart illustrating a method for constructing a certificate management system according to an embodiment of the present application. It should be understood that the method illustrated in FIG. 6 may be performed by a deployment platform. The method may be applied in a services grid comprising a data plane 20 and a control plane 10, the data plane 20 of the services grid comprising at least one cluster.
As shown in fig. 6, the method includes:
at step 602, a global CA manager is deployed at a control plane of a services grid.
The local CA manager in each cluster is used for managing the CA certificate of each component in the corresponding cluster; the global CA manager is used for managing CA certificates of components in each cluster of the at least one cluster.
Optionally, the global CA manager is configured to issue a CA certificate for a first cluster newly added to the service grid, and/or delete a CA certificate for a second cluster removed from the service grid.
Optionally, the method further comprises: the deployment platform deploys a cluster manager at a control plane of the services grid, the cluster manager for generating a context for the first cluster when the first cluster joins the services grid and/or for deleting a context for the second cluster when the second cluster is removed from the services grid.
Optionally, the cluster manager is further configured to provide an interface for a user to add and/or remove clusters from the service grid.
Optionally, the interface using method includes: UI, API, or CLI.
Optionally, the local CA manager in each cluster is further configured to update the certificates of the components in the corresponding cluster based on the certificate life cycle of the components.
Optionally, the global CA manager is further configured to, in the event that the local CA manager of the third cluster fails, perform a certificate update on each component in the third cluster based on a certificate lifecycle of each component in the third cluster, where the third cluster is any one of the at least one cluster.
Optionally, the method further comprises: the deployment platform deploys a local controller in each cluster, and the local controller is connected with the global CA controller; the local CA manager of the third cluster is specifically configured to, in the event of a failure, obtain, by the local controller of the third cluster, an updated CA certificate from the global CA controller.
Optionally, the method further comprises: the deployment platform deploys a global namespace manager on a control surface of the service grid, the global namespace manager is used for dividing components in at least one cluster according to at least one preset namespace so as to obtain the components belonging to each namespace in the at least one namespace, and each namespace in the at least one namespace corresponds to one service capability.
Optionally, the method further comprises: the deployment platform deploys a service grid control plane component at a control plane of a service grid, the service grid control plane component including one or more of: API services, network configuration, identity authentication mechanisms, and global webhook controllers.
Optionally, the global CA manager is further configured to manage CA certificates of one or more components of the control plane.
Optionally, the method further comprises: the deployment platform deploys one or more of the following components in each cluster: a grid proxy, an application service instance, and a local webhook controller.
It should be understood that the present application does not limit the execution sequence of the above steps.
Based on the scheme, the global CA manager is deployed on the control plane of the service grid, and the local CA manager is deployed in each cluster on the data plane of the service grid, so that the global CA manager and the local CA manager can work cooperatively to realize the hierarchical management of the multi-cluster certificate. In one aspect, management of CA certificates is performed by a global CA manager in a control plane of a services grid for components in clusters in a data plane of the services grid. On the other hand, the CA certificates of the components in the corresponding cluster are managed by a local CA manager in the data plane of the service grid. Therefore, the workload of the local CA manager for managing and maintaining the certificate can be reduced, and the operation and maintenance complexity of the user, namely the operation and maintenance cost, can be reduced. Meanwhile, the convenience of CA certificate maintenance can be improved through global unified management.
Next, a certificate management apparatus and a certificate management system construction apparatus provided in an embodiment of the present application are described with reference to fig. 7.
Fig. 7 is a schematic block diagram of an apparatus provided by an embodiment of the present application. The device 700 may be used to implement the functions of the control plane of the service grid or the data plane of the service grid in the certificate management system described above; the method can also be used for realizing the function of the deployment platform in the construction method of the certificate management system.
As shown in fig. 7, the apparatus 700 may include at least one processor 710, configured to implement a function of a control plane of a service grid or a function of a data plane of the service grid in the certificate management system or the certificate management method provided in the embodiment of the present application; or, the method is used to implement the function of the deployment platform in the method for constructing the certificate management system provided in the embodiment of the present application.
Illustratively, when the apparatus 700 is used to implement the function of providing the data plane of the service grid according to the embodiment of the present application, the processor 710 may be configured to manage CA certificates of components in a corresponding cluster; when the apparatus 700 is used to implement the function of the service grid control plane provided by the embodiment of the present application, the processor 710 may be configured to manage CA certificates of components in each cluster of at least one cluster. For details, reference is made to the detailed description in the foregoing embodiments, which are not repeated herein.
Illustratively, when the apparatus 700 is used to implement the functions of a deployment platform in the method for constructing a certificate management system provided by the embodiment of the present application, the processor 710 may be configured to deploy a local CA manager in each cluster of at least one cluster; and may be used to deploy a global CA manager at the control plane of the services grid. For details, reference is made to the detailed description in the foregoing embodiments, which are not repeated herein.
The device 700 may also include at least one memory 720 for storing program instructions and/or data. A memory 720 is coupled to the processor 710. The coupling in the embodiments of the present application is an indirect coupling or a communication connection between devices, units or modules, and may be an electrical, mechanical or other form for information interaction between the devices, units or modules. The processor 710 may operate in conjunction with the memory 720. Processor 710 may execute program instructions stored in memory 720. At least one of the at least one memory may be included in the processor.
The apparatus 700 may also include a communication interface 730 for communicating with other devices over a transmission medium, such that the apparatus 700 may communicate with other devices. When the apparatus 700 is used to implement the functionality of a serving mesh control plane, other devices may be serving mesh data planes; when the apparatus 700 is used to implement the functionality of the serving mesh data plane, the other device may be the serving mesh control plane. The communication interface 730 may be, for example, a transceiver, an interface, a bus, a circuit, or a device capable of performing a transceiving function. Processor 710 may utilize communication interface 730 to send and receive data and/or information and may be used to implement the functionality of the services grid control plane or services grid data plane in the embodiments corresponding to fig. 3-5 or the functionality of the deployment platform in the embodiments corresponding to fig. 6.
The specific connection medium among the processor 710, the memory 720 and the communication interface 730 is not limited in the embodiments of the present application. In fig. 7, the processor 710, the memory 720 and the communication interface 730 are connected by a bus. The bus lines are shown in fig. 7 by thick lines, and the connection manner between other components is merely illustrative and not limited thereto. The bus may be divided into an address bus, a data bus, a control bus, etc. For ease of illustration, only one thick line is shown in FIG. 6, but this is not intended to represent only one bus or type of bus.
It should be understood that the processor in the embodiments of the present application may be an integrated circuit chip having signal processing capability. In implementation, the steps of the above method embodiments may be performed by integrated logic circuits of hardware in a processor or instructions in the form of software. The processor may be a general purpose processor, a Digital Signal Processor (DSP), an Application Specific Integrated Circuit (ASIC), a Field Programmable Gate Array (FPGA) or other programmable logic device, discrete gate or transistor logic device, or discrete hardware components. The various methods, steps, and logic blocks disclosed in the embodiments of the present application may be implemented or performed. A general purpose processor may be a microprocessor or the processor may be any conventional processor or the like. The steps of the method disclosed in connection with the embodiments of the present application may be directly implemented by a hardware decoding processor, or implemented by a combination of hardware and software modules in the decoding processor. The software module may be located in ram, flash memory, rom, prom, or eprom, registers, etc. storage media as is well known in the art. The storage medium is located in a memory, and a processor reads information in the memory and completes the steps of the method in combination with hardware of the processor.
It will also be appreciated that the memory in the embodiments of the subject application can be either volatile memory or nonvolatile memory, or can include both volatile and nonvolatile memory. The non-volatile memory may be a read-only memory (ROM), a Programmable ROM (PROM), an Erasable PROM (EPROM), an electrically Erasable EPROM (EEPROM), or a flash memory. Volatile memory can be Random Access Memory (RAM), which acts as external cache memory. By way of example, but not limitation, many forms of RAM are available, such as Static Random Access Memory (SRAM), Dynamic Random Access Memory (DRAM), Synchronous Dynamic Random Access Memory (SDRAM), double data rate SDRAM, enhanced SDRAM, SLDRAM, Synchronous Link DRAM (SLDRAM), and direct rambus RAM (DR RAM). It should be noted that the memory of the systems and methods described herein is intended to comprise, without being limited to, these and any other suitable types of memory.
The present application also provides a computer-readable storage medium having stored thereon a computer program (also referred to as code, or instructions). When executed, cause the computer to perform the functions of the service grid control plane 10 or the service grid data plane 20 of the embodiments shown in figures 3 to 4.
As used in this specification, the terms "unit," "module," and the like are intended to refer to a computer-related entity, either hardware, firmware, a combination of hardware and software, or software in execution.
Those of ordinary skill in the art will appreciate that the various illustrative logical blocks and steps (step) described in connection with the embodiments disclosed herein may be implemented as electronic hardware or combinations of computer software and electronic hardware. Whether such functionality is implemented as hardware or software depends upon the particular application and design constraints imposed on the implementation. Skilled artisans may implement the described functionality in varying ways for each particular application, but such implementation decisions should not be interpreted as causing a departure from the scope of the present application. In the several embodiments provided in the present application, it should be understood that the disclosed apparatus, device and method may be implemented in other ways. For example, the above-described apparatus embodiments are merely illustrative, and for example, the division of the unit is only one logical functional division, and other divisions may be realized in practice, for example, a plurality of units or components may be combined or integrated into another system, or some features may be omitted, or not executed. In addition, the shown or discussed mutual coupling or direct coupling or communication connection may be an indirect coupling or communication connection through some interfaces, devices or units, and may be in an electrical, mechanical or other form.
The units described as separate parts may or may not be physically separate, and parts displayed as units may or may not be physical units, may be located in one place, or may be distributed on a plurality of network units. Some or all of the units can be selected according to actual needs to achieve the purpose of the solution of the embodiment.
In addition, functional units in the embodiments of the present application may be integrated into one processing unit, or each unit may exist alone physically, or two or more units are integrated into one unit.
In the above embodiments, the functions of the functional units may be wholly or partially implemented by software, hardware, firmware, or any combination thereof. When implemented in software, may be implemented in whole or in part in the form of a computer program product. The computer program product includes one or more computer instructions (programs). The procedures or functions according to the embodiments of the present application are wholly or partially generated when the computer program instructions (program) are loaded and executed on a computer. The computer may be a general purpose computer, a special purpose computer, a network of computers, or other programmable device. The computer instructions may be stored in, or transmitted from, a computer-readable storage medium to another computer-readable storage medium, for example, from one website, computer, server, or data center, over a wired (e.g., coaxial cable, fiber optics, Digital Subscriber Line (DSL), or wireless (e.g., infrared, wireless, microwave, etc.) network, the computer-readable storage medium may be any available medium that can be accessed by a computer or a data storage device including one or more integrated servers, data centers, etc., the available medium may be magnetic media (e.g., floppy disks, hard disks, magnetic tapes), optical media (e.g., digital video disks, DVD), or a semiconductor medium (e.g., a Solid State Disk (SSD)), etc.
This functionality, if implemented in the form of software functional units and sold or used as a stand-alone product, may be stored in a computer readable storage medium. Based on such understanding, the technical solution of the present application or portions thereof that substantially contribute to the prior art may be embodied in the form of a software product stored in a storage medium and including instructions for causing a computer device (which may be a personal computer, a server, or a network device) to execute all or part of the steps of the method according to the embodiments of the present application. And the aforementioned storage medium includes: various media capable of storing program codes, such as a U disk, a removable hard disk, a ROM, a RAM, a magnetic disk, or an optical disk.
The above description is only for the specific embodiments of the present application, but the scope of the present application is not limited thereto, and any person skilled in the art can easily conceive of the changes or substitutions within the technical scope of the present application, and shall be covered by the scope of the present application. Therefore, the protection scope of the present application shall be subject to the protection scope of the claims.
Claims (12)
1. A certificate management system, comprising: a global Certificate Authority (CA) manager deployed at a control plane of a services grid, at least one cluster deployed at a data plane of the services grid, and a local CA manager included in each cluster of the at least one cluster; wherein,
the local CA manager in each cluster is used for managing the CA certificate of each component in the corresponding cluster;
the global CA manager is used for managing CA certificates of components in each cluster in the at least one cluster.
2. The system of claim 1, wherein the global CA manager is to issue CA certificates for first clusters newly joining the service grid and/or delete CA certificates for second clusters removed from the service grid.
3. The system of claim 1 or 2, wherein the system further comprises: a cluster manager deployed at a control plane of the services grid, the cluster manager to generate a context for the first cluster when the first cluster joins the services grid and/or to delete a context for the second cluster when the second cluster is removed from the services grid.
4. The system of claim 3, wherein the cluster manager is further configured to provide an interface for a user to add and/or remove clusters from the service grid.
5. The system of claim 4, wherein the interface usage pattern comprises: a user interface UI, an application program interface API, or a command line interface CLI.
6. The system of claim 1, wherein the local CA manager in each cluster is further configured to perform a certificate update on components in the corresponding cluster based on their certificate life cycles.
7. The system of claim 6, wherein the global CA manager is further configured to perform a certificate update for each component in a third cluster based on a certificate lifecycle of each component in the third cluster in the event of a failure of a local CA manager of the third cluster, the third cluster being any one of the at least one cluster.
8. The system of claim 7, wherein each cluster further comprises a local controller, the local controller connected to the global CA controller; wherein,
the local CA manager of the third cluster is specifically configured to, in the event of a failure, obtain, by the local controller of the third cluster, an updated CA certificate from the global CA controller.
9. The system of claim 1, further comprising a global namespace manager deployed at a control plane of the services grid, the global namespace manager configured to partition the components in the at least one cluster according to a preset at least one namespace to obtain components belonging to each of the at least one namespace, each of the at least one namespace corresponding to a service capability.
10. The system of claim 1, wherein the global CA manager is further to manage CA certificates for one or more components of the control plane.
11. A certificate management method, applied to a certificate management system, the certificate management system comprising: a global Certificate Authority (CA) manager deployed at a control plane of a services grid, at least one cluster deployed at a data plane of the services grid, and a local CA manager included in each cluster of the at least one cluster;
the method comprises the following steps:
the global CA manager manages CA certificates for components in each of the at least one cluster; and
and the local CA manager in each cluster manages the CA certificate of each component in the corresponding cluster.
12. A method for constructing a certificate management system, applied to a service grid, wherein the service grid includes a data plane and a control plane, and the data plane of the service grid includes at least one cluster, the method comprising:
deploying a local Certificate Authority (CA) manager in each cluster of the at least one cluster, wherein the local CA manager in each cluster is used for managing CA certificates of all components in the corresponding cluster;
deploying a global CA manager at a control plane of the service grid, the global CA manager for managing CA certificates of components in each cluster of the at least one cluster.
Priority Applications (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| CN202210288028.4A CN114666131A (en) | 2022-03-22 | 2022-03-22 | Certificate management system, certificate management method and certificate management system construction method |
Applications Claiming Priority (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| CN202210288028.4A CN114666131A (en) | 2022-03-22 | 2022-03-22 | Certificate management system, certificate management method and certificate management system construction method |
Publications (1)
| Publication Number | Publication Date |
|---|---|
| CN114666131A true CN114666131A (en) | 2022-06-24 |
Family
ID=82031721
Family Applications (1)
| Application Number | Title | Priority Date | Filing Date |
|---|---|---|---|
| CN202210288028.4A Pending CN114666131A (en) | 2022-03-22 | 2022-03-22 | Certificate management system, certificate management method and certificate management system construction method |
Country Status (1)
| Country | Link |
|---|---|
| CN (1) | CN114666131A (en) |
Citations (9)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| US20120166796A1 (en) * | 2010-12-28 | 2012-06-28 | Motorola Solutions, Inc. | System and method of provisioning or managing device certificates in a communication network |
| CN109361753A (en) * | 2018-11-02 | 2019-02-19 | 上海帆尚行科技有限公司 | A kind of Internet of things system framework and encryption method |
| CN110944330A (en) * | 2018-09-21 | 2020-03-31 | 华为技术有限公司 | MEC platform deployment method and device |
| CN111130892A (en) * | 2019-12-27 | 2020-05-08 | 上海浦东发展银行股份有限公司 | Enterprise-level microservice management system and method |
| US20210328971A1 (en) * | 2020-04-20 | 2021-10-21 | Fortanix, Inc. | Secure service mesh |
| WO2021249268A1 (en) * | 2020-06-09 | 2021-12-16 | 阿里巴巴集团控股有限公司 | Method for creating service mesh instance, service mesh system, and multi-cluster system |
| CN113886794A (en) * | 2021-09-28 | 2022-01-04 | 阿里巴巴（中国）有限公司 | Computing cluster system, security authentication method, node device and storage medium |
| US20220006654A1 (en) * | 2020-07-02 | 2022-01-06 | EMC IP Holding Company LLC | Method to establish an application level ssl certificate hierarchy between master node and capacity nodes based on hardware level certificate hierarchy |
| CN113934550A (en) * | 2020-06-26 | 2022-01-14 | 红帽公司 | Joint operation and maintenance device for edge computing network |
-
2022
- 2022-03-22 CN CN202210288028.4A patent/CN114666131A/en active Pending
Patent Citations (9)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| US20120166796A1 (en) * | 2010-12-28 | 2012-06-28 | Motorola Solutions, Inc. | System and method of provisioning or managing device certificates in a communication network |
| CN110944330A (en) * | 2018-09-21 | 2020-03-31 | 华为技术有限公司 | MEC platform deployment method and device |
| CN109361753A (en) * | 2018-11-02 | 2019-02-19 | 上海帆尚行科技有限公司 | A kind of Internet of things system framework and encryption method |
| CN111130892A (en) * | 2019-12-27 | 2020-05-08 | 上海浦东发展银行股份有限公司 | Enterprise-level microservice management system and method |
| US20210328971A1 (en) * | 2020-04-20 | 2021-10-21 | Fortanix, Inc. | Secure service mesh |
| WO2021249268A1 (en) * | 2020-06-09 | 2021-12-16 | 阿里巴巴集团控股有限公司 | Method for creating service mesh instance, service mesh system, and multi-cluster system |
| CN113934550A (en) * | 2020-06-26 | 2022-01-14 | 红帽公司 | Joint operation and maintenance device for edge computing network |
| US20220006654A1 (en) * | 2020-07-02 | 2022-01-06 | EMC IP Holding Company LLC | Method to establish an application level ssl certificate hierarchy between master node and capacity nodes based on hardware level certificate hierarchy |
| CN113886794A (en) * | 2021-09-28 | 2022-01-04 | 阿里巴巴（中国）有限公司 | Computing cluster system, security authentication method, node device and storage medium |
Similar Documents
| Publication | Publication Date | Title |
|---|---|---|
| US9432350B2 (en) | System and method for intelligent workload management | |
| US11770381B2 (en) | Managing security groups for data instances | |
| US9614737B1 (en) | Appliance backnets in dedicated resource environment | |
| CN102947797B (en) | The online service using directory feature extending transversely accesses and controls | |
| US20180225584A1 (en) | System and method for determining fuzzy cause and effect relationships in an intelligent workload management system | |
| US20170293501A1 (en) | Method and system that extends a private data center to encompass infrastructure allocated from a remote cloud-computing facility | |
| US9483289B2 (en) | Operating system in a commodity-based computing system | |
| US20120066487A1 (en) | System and method for providing load balancer visibility in an intelligent workload management system | |
| US20030005090A1 (en) | System and method for integrating network services | |
| US9270703B1 (en) | Enhanced control-plane security for network-accessible services | |
| US20120102480A1 (en) | High availability of machines during patching | |
| US11909599B2 (en) | Multi-domain and multi-tenant network topology model generation and deployment | |
| WO2020106845A1 (en) | Enabling access across private networks for a managed blockchain service | |
| CN101594386A (en) | Reliable virtual organization construction method and device based on distributed strategy verification | |
| Bessani et al. | A look to the old-world_sky: EU-funded dependability cloud computing research | |
| CN114666131A (en) | Certificate management system, certificate management method and certificate management system construction method | |
| Jain et al. | The Role of Intelligent Grid Technology in Cloud Computing | |
| Rostami | Cloud Service Models-IaaS, PaaS, and SaaS | |
| US11829779B2 (en) | Scalable specification and self-governance for autonomous databases, cluster databases and multi-tenant databases in cloud and on-prem environment | |
| US20220329583A1 (en) | On demand operations access to cloud customer resources | |
| Santangelo | Cloud-native Kubernetes application to efficiently and securely stream and collect real-time data | |
| Cloud | DEEP-Hybrid Data Cloud | |
| MOLÍK | High-Performance Object Storage in Kubernetes Cluster |
Legal Events
| Date | Code | Title | Description |
|---|---|---|---|
| PB01 | Publication | ||
| PB01 | Publication | ||
| SE01 | Entry into force of request for substantive examination | ||
| SE01 | Entry into force of request for substantive examination |