WO2023051498A1 - 身份管理方法及装置、电子设备、计算机可读介质 - Google Patents

身份管理方法及装置、电子设备、计算机可读介质 Download PDF

Info

Publication number
WO2023051498A1
WO2023051498A1 PCT/CN2022/121580 CN2022121580W WO2023051498A1 WO 2023051498 A1 WO2023051498 A1 WO 2023051498A1 CN 2022121580 W CN2022121580 W CN 2022121580W WO 2023051498 A1 WO2023051498 A1 WO 2023051498A1
Authority
WO
WIPO (PCT)
Prior art keywords
workload
identity
information
node
server
Prior art date
Application number
PCT/CN2022/121580
Other languages
English (en)
French (fr)
Inventor
侯芳
王江
Original Assignee
中兴通讯股份有限公司
Priority date (The priority date 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 date listed.)
Filing date
Publication date
Application filed by 中兴通讯股份有限公司 filed Critical 中兴通讯股份有限公司
Publication of WO2023051498A1 publication Critical patent/WO2023051498A1/zh

Links

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
    • 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/40—Network security protocols

Definitions

  • This application involves but is not limited to the technical fields of cloud security and identity security.
  • CA Certificate Authority
  • PKI Public Key Infrastructure
  • the present application provides an identity management method, including: obtaining the startup information of the workload based on the identity file request initiated by the workload; wherein, the identity file request is when the workload enters an initial state The request initiated under: match the registration information of the workload based on the startup information of the workload; wherein, the registration information is the information provided to the server when the workload is registered; the startup information and the registration If the information is successfully matched, the workload identity file is sent to the workload for the workload to enter the working state.
  • the present application provides an identity management device, including: an acquisition module configured to acquire the startup information of the workload based on the identity file request initiated by the workload; wherein the identity file request is the workload A request initiated when entering the initial state; a matching module configured to match the registration information of the workload based on the startup information of the workload; wherein the registration information is information provided to the server when the workload is registered ; A sending module configured to send the workload identity file to the workload when the startup information matches the registration information successfully, so that the workload can enter work based on the workload identity file state.
  • the present application provides an electronic device, including: one or more processors; a storage device, on which one or more programs are stored, when the one or more programs are When the processor executes, the one or more processors implement any one of the methods described herein; one or more I/O interfaces, connected between the processor and the memory, are configured to implement the processing Information exchange between the device and the memory.
  • the present application provides a storage medium on which a computer program is stored, and when the computer program is executed by a processor, any one of the methods described herein is implemented.
  • FIG. 1 is a schematic diagram of hardware devices used in the identity management method provided by the present application.
  • Fig. 2 is the structural representation of agent end in the present application
  • FIG. 3 is a flowchart of an identity management method provided by the present application.
  • FIG. 4 is a flow chart of a node authentication provided by the present application.
  • FIG. 5 is a flowchart of a workload authentication provided by the present application.
  • FIG. 6 is a flow chart of server startup provided by the present application.
  • FIG. 7 is a flowchart of interaction between a server, an agent, and a workload provided by the present application
  • FIG. 8 is a functional block diagram of an identity management device provided by the present application.
  • FIG. 9 is a functional block diagram of an electronic device provided by the present application.
  • Embodiments described herein may be described with reference to plan views and/or cross-sectional views by way of idealized schematic representation of the application. Accordingly, the example illustrations may be modified according to manufacturing techniques and/or tolerances. Therefore, the embodiments are not limited to those shown in the drawings but include modifications of configurations formed based on manufacturing processes. Accordingly, the regions illustrated in the figures have schematic properties, and the shapes of the regions shown in the figures illustrate the specific shapes of the regions of the elements, but are not intended to be limiting.
  • Cloud computing-based east-west identity authentication has some open source projects in certificate management, such as kubernetes cert-manger or cert-manager-istio-csr. These open source projects are combined with east-west traffic management plane or control plane nodes to Associate the superior root CA (Certificate Authority, certificate authority) and manage the life cycle of the identity certificate file.
  • the request identity ID of the default workload of this open source project is credible.
  • the microservice identity service account in the kubernetes (K8S) cluster is credible by default. The private key is not stored securely and is easily leaked.
  • the identity management method provided by this application is an identity management solution based on the cloud-native orchestration deployment or service grid management architecture. Only the workloads allowed in the deployment blueprint or orchestration deployment plan can get uniformly assigned identities. Only when it is powered on can it enter the working state, avoiding malicious implantation of untrusted workloads into the intranet operating environment.
  • the identity management method provided by this application is to deploy or embed the server and agent in the intranet environment.
  • the server can identify the trusted environment of the agent and the application workload, and automatically build identity credentials consistent with the orchestration and deployment information for the workload. After the workload obtains the identity and passes the authentication, it can ensure that it can communicate with other entities. Security of access, for example, using the identity to implement handshake authentication when establishing a two-way transport encrypted tunnel (mTLS) between entities.
  • MTLS two-way transport encrypted tunnel
  • FIG. 1 is a schematic diagram of hardware devices used in the identity management method provided by this application.
  • the service end 11 can be deployed in the cloud platform management system as an independent logic component, and the agent end 12 is deployed on the node, and the agent end 12 passes through the agent interface, that is, the node API (Node API) 13 and the server end signal connection.
  • a first node certifier 111, a node resolver 112, a data store (data store) 113, a first key manager (key manager) 114, and an upstream authority center 115 are provided in the server 11.
  • CLI means a command line interface operated manually, such as a network management EMS client, for initiating a request or registering.
  • the data store (data store) 113 is connected with the configuration storehouse 16, the identity database (identify SQL) 17 signals of the background, so that the data store 113 can obtain the data in the configuration storehouse 16 and the identity database 17 of the background.
  • the cloud platform management system is connected with the background configuration library 16 and the identity database (identify SQL) 17 signal through the registration interface (register API).
  • Upward authorization (upstream Authority) center 115 is connected with digital certificate authority (CA) 18 signals.
  • CA digital certificate authority
  • the agent 12 is provided with a workload interface 14 for information exchange with the workload 15 , and each agent 12 can be signally connected to one or more workloads 15 .
  • the first node certifier 111 is used to cooperate with the second node certifier 21 to certify the node for authentication.
  • the node resolver 112 is an extension component. After the identity of the node is authenticated, the node resolver 112 is used to obtain the attribute label based on the selector.
  • the data store 113 belongs to the data interface component and is used to store, query and update various information. For example, registry entries, which nodes are attested, what is the selector for attested nodes, etc.
  • the data store 113 can have a built-in memory database SQLite, and can also be connected to the background database of the cloud platform, such as the configuration library 16 and the identity database 17 .
  • the first key manager 114 is used to manage or store the private key used based on x.509 or JWT (Json web token, Jason webpage token), and the private key is stored in the local area connected with the first key manager signal In the memory Mem.
  • the upward authorization center 115 is used to expand and connect to other external PKI (Public Key Infrastructure, public key structure) components.
  • Fig. 2 is a schematic diagram of the structure of the agent in this application.
  • the proxy side includes a second node prover 21 , a workload parser 22 and a second key manager 23 .
  • the second node certifier 21 is used to cooperate with the first node certifier 111 to authenticate the node.
  • the workload resolver 22 verifies the identity of the workload process on the node by querying the information about the process from the node operating system and comparing the process information with the information provided to the server when registering the attribute of the workload using the selector. available.
  • the second key manager 23 is used to generate and use X.509-based private keys issued to workloads.
  • the configuration library 16 is used to deploy blueprints, and after the physical workload is powered on, the cloud platform can see configuration information, model views, or scripts in the background database.
  • the identity database 17 is used to store spiffe id and views of other databases associated with the spiffe id, and query and index asset information according to identity.
  • Fig. 3 is a flow chart of an identity management method provided by this application. As shown in FIG. 3 , the identity management method provided by this application may include steps S301 to S303.
  • step S301 based on the identity file request initiated by the workload, start information of the workload is obtained; wherein, the identity file request is a request initiated when the workload enters an initial state.
  • step S302 the registration information of the workload is matched based on the startup information of the workload; wherein, the registration information is the information provided to the server when the workload is registered.
  • step S303 if the startup information matches the registration information successfully, the workload identity file is sent to the workload for the workload to enter the working state.
  • the identity credential (certificate) of the workload instance is generated when the workload instance starts (it can be obtained through the security service based on HSM (hardware security module) and PKI provided by the cloud platform), and is exposed to the public through the server.
  • a workload instance can have multiple identities (IDs), and the format of the ID can be defined by spiffe, but there is only one identity credential, and the asset attributes carried in the identity ID can be extracted from the identity credential at any time according to the scenario , at the same time, because when issuing the identity credential certificate file, at least the ownership of the domain is verified; based on this, the identity certificate of the instance adopts the x.509-SVID format.
  • an identity file request is sent to the agent.
  • the agent After receiving the identity file request, the agent obtains the startup information of the workload.
  • the startup information of the workload includes but not limited to the type of the workload, the running region and other information.
  • the workload's registration information includes asset information metadata.
  • the asset information metadata of the workload can be extracted from the deployment blueprint or orchestration and resource files by using script tools, and the metadata can be abstracted into a set of labels according to the purpose, owner or environment.
  • the metadata is composed of a A key and an optional value. Considering the need for future runtime control or authorization, construct one or more identity IDs that follow the SPIFFE specification form for each workload instance, and create a many-to-one index relationship between the identity ID and the assets of the workload, and then store the identity database.
  • the metadata information of the workload has been structured in the (backend) configuration library and the identity CNC of the cloud platform, and a workload entity can be uniquely identified externally; Physical or virtual resources in the NMS to synchronize the asset information of the workload.
  • the asset information of the workload may be host, VIM, virtual machine, POD, container (docker), APP.
  • the workload is still in the initial state, and the identity file cannot be obtained until the matching is successful, and enters the working state.
  • step S301 obtaining the startup information of the workload includes: identifying the process ID of the workload through the kernel mode or user mode of the current node according to the process control symbol; determining the startup information based on the process ID.
  • the node may also be authenticated, that is, the node shall be authenticated first, and then the workload set on the node shall be authenticated.
  • the agent needs to perform identity authentication when connecting to the server for the first time, and this authentication process is also called node authentication.
  • node authentication the agent and server work together to verify the identity of the node running the agent. Enforcement is via the node prover component deployed in the node. All node provers ask the node and its environment for pieces of information that only the node possesses to prove the node's identity. The result of node authentication is that the agent receives the unique ID assigned by the server.
  • both the node identity ID and the workload ID are issued and managed by the server in a unified manner, which reduces static identity credentials scattered among the workloads of each cloud-based node, and improves security.
  • the authentication process of a node includes: obtaining node identity information; wherein, the node identity information is information that can prove the identity of the current node; based on the node identity information, a node identity authentication request is initiated to the server; receiving the node identity file, the node The identity file includes the node identity ID.
  • the node identity ID acts as the "parent" of the workload that the agent is responsible for. There can be multiple workload identity IDs. Multiple workload identity IDs can be combined into a structural linked list, and can be constructed together with the node identity ID to form a new The identity ID of the SPIFFE structure.
  • the agent and the server obtain the metadata of the nodes from the cloud platform through the first node certifier and the second node certifier.
  • the nodes can verify other attributes of the relevant nodes through the node resolver. Identify other identities of nodes (such as network function virtualization interfaces).
  • FIG. 4 is a flow chart of node authentication provided by this application.
  • VNFI represents a virtualized network function module instance
  • VIM represents a virtualized infrastructure manager
  • NFVO represents a network function virtualization orchestrator
  • VNFM represents a virtualized network function module manager.
  • the node authentication step may include steps S401 to S404.
  • step S401 the second node prover at the proxy side obtains node identity meta information through a cloud base (mainly network function virtualization infrastructure, NFVI).
  • a cloud base mainly network function virtualization infrastructure, NFVI.
  • step S402 the second node certifier sends node identity meta information to the first node certifier at the server.
  • step S403 the first node certifier at the server side parses the node identity meta-information.
  • step S404 when the authentication node is legal and valid, a node authentication, such as an x.509 node certificate, is issued to the agent.
  • a node authentication such as an x.509 node certificate
  • the agent obtains the host and virtual machine instance IDs, as well as the node information of the cluster members in the initial state of power-on. For example, in the initial state of power-on, the agent uses the Kubernetes Service Account token to obtain the host and virtual machine instance IDs, as well as the node information of the cluster members.
  • the agent can be authenticated using the preset shared key, and after the initial authentication is passed, the token mechanism can be used to replace the shared key.
  • the shared key expires immediately.
  • the agent and the server provide an external injection API at startup, and the x.509 certificate imported at the node or server in advance is used for reliable transmission of the initial node authentication process.
  • the authentication process of the node further includes: initiating a node attribute information request to the server based on the node identity file; responding to the node attribute information returned by the server, sending a certificate to the server based on the node attribute information Generate a request CSR (Certificate Signing Request); receive the node attribute authentication returned by the server.
  • CSR Chipificate Signing Request
  • the node attribute authentication includes the node identity file and the identification of the node identity state after signing the node attribute information.
  • the identity file is an identity credential file based on the asset information of the workload and established with a preset identity identification framework.
  • the identity identification framework is the SPIFFE framework.
  • the workload includes at least one of a deployment resource, a pod, a container docker, and an application.
  • workloads obtain identities and associate them with assets, that is, the granularity of identities extends to containers and application processes, so that in addition to identifying workloads, more attribute information is attached to identities.
  • the feature information of the workload can be extracted through the identity, and the workload can be controlled and managed in batches or wildcards in the management background or runtime of the cloud platform; at the same time, the identity can be called from the cloud-native or virtualized virtual machine Or pods extend to containers and application processes.
  • both the node ID and the workload ID follow the idea of identity definition security, using the asset information of the workload, each asset information is equivalent to a tag, using tag-style role management to solve the problem of multiple user identities, Multi-level labels form an identity ID hierarchically.
  • the node identity ID adopts the SPIFFE framework, the node identity ID is a string, which can uniquely identify the workload.
  • the workload can have multiple instances, and the format is open, which can be in the form of path or user.
  • This application breaks the traditional x.509 CA certificate as an identity credential, and introduces a workload security identification framework SPIFFE in the east-west direction, which improves interoperability and provides a perfect identification compatible with the customer system.
  • the SPIFFE framework mainly includes three parts: SPIFFE ID specification, SVID identification document standard, and workload identification API. This implementation The method will not focus on this description.
  • This application adopts the SPIFFE framework to build an identity ID model, which may include device identifiers, network identifiers, service identifiers, workload identifiers, disk identifiers, process identifiers, and resource information.
  • identity ID may include device identifiers, network identifiers, service identifiers, workload identifiers, disk identifiers, process identifiers, and resource information.
  • identity ID may include device identifiers, network identifiers, service identifiers, workload identifiers, disk identifiers, process identifiers, and resource information.
  • identity ID may include device identifiers, network identifiers, service identifiers, workload identifiers, disk identifiers, process identifiers, and resource information.
  • the node identity ID can be designed according to the needs, but it needs to be unique in a cloud platform, and the distribution is calculated after the deployment blueprint is imported or manually configured and imported into the background database.
  • node identity ID is as follows:
  • the identity ID of the workload can be combined by the server, or by the workload resolver in the agent according to the agreed form.
  • Workload ID The form is as follows:
  • the agent identifies the running attributes of the current workload by asking for locally available permissions (for example, when deploying based on kubernetes, through the operating system kernel where the node is located or the kubelet running on the same node), and will These attributes are compared with the information provided to the server when registering workload attributes, and finally determine the object to which the running process belongs.
  • FIG. 5 is a flow chart of workload authentication provided by this application. As shown in Fig. 5, workload authentication may include steps S501 to S505.
  • step S501 the workload initiates a workload file request to the agent.
  • the workload calls the workload API to request the identity file of the workload from the agent.
  • the workload API can be a Unix domain socket.
  • the workload can be pod, container, application process, etc.
  • step S502 the agent queries the node's kernel to identify the caller's process ID and invokes any configured workload prover plugins, providing them with the workload's process ID.
  • step S503 the workload prover uses the process ID to discover additional information about the workload instantiation and, if necessary, query adjacent cloud platform-specific components (eg, Kubernetes kubelet).
  • additional cloud platform-specific components eg, Kubernetes kubelet
  • step S504 the workload prover returns other information found about the instantiation of the workload to the agent in the form of a selector.
  • a selector Such as: selector on the kubernetes system, selector:redis
  • step S505 the agent determines the identity of the workload by comparing the discovered selector with the registration information, and returns the correct cached identity certification file to the workload.
  • the server can obtain the current computing resource allocation and arrangement information of the cloud platform.
  • the server can be deployed in the cloud platform management system, so as to obtain computing resource allocation and arrangement information.
  • the server can be deployed in MANO (Management and Orchestration, management and orchestration), so as to directly obtain the service and microservice blueprint information in the local configuration library.
  • MANO Management and Orchestration, management and orchestration
  • FIG. 6 is a flow chart of server startup provided by this application. As shown in FIG. 6, the starting steps of the server may include steps S601 to S606.
  • step S601 start-up information is read from a configuration library.
  • step S602 the server judges whether there is an upper-level CA management center based on the startup information, and if the judgment result is that there is an upper-level CA management center, then execute step S607; if the judgment result is that there is no upper-level CA management center, then execute step S603.
  • step S603 the server generates a signature certificate, which is the signature certificate of the server itself.
  • step S604 the server generates a trust configuration request based on the signature certificate, and sends the trust configuration request to the configuration repository.
  • step S605 the server judges whether the configuration repository is updated based on the trusted configuration request. If the judgment result is that the configuration repository is successfully updated, step S606 is executed; if the judgment result is that the configuration repository is not successfully updated, step S608 is executed.
  • step S606 the server sends a message to the identity database to power on the identity database and allow registration of identities (workloads and agents). After that, the server starts successfully and enters the working state.
  • the registration identity refers to allowing the agent and the workload to register the identity on the server.
  • step S607 obtain the superior CA through the certificate manager.
  • step S608 wait for the configuration library to be in place, and execute step S606 when the configuration library is in place.
  • FIG. 7 is a flowchart of interaction between a server, an agent, and a workload provided by the present application. As shown in FIG. 7 , the interaction steps between the server, the agent and the workload may include steps S701 to S714.
  • step S701 the agent obtains node identity information through a bootstrap program.
  • step S702 the agent initiates a node identity authentication request to the server, and if the agent does not initiate a node identity authentication request, the activation of the agent ends.
  • step S703 the server verifies whether the node identity credential is valid, and if the node identity is valid, execute step S704, and when the node identity is invalid, end the startup of the agent.
  • step S704 the server parses the node identity credential, and when the node identity credential is successfully parsed, step S705 is executed, and when the node identity credential fails to be parsed successfully, the startup of the agent ends.
  • step S705 the server initiates a matching query on the node identity credentials, and when a matching result is obtained, step S706 is executed, and when no matching result is obtained, the startup of the agent ends.
  • step S706 the server sends the node identity file to the agent, and the node identity file at least includes a node identity ID.
  • step S707 the agent uses the node ID to initiate a TLS to the server to obtain all registered relevant attribute information of the node where the agent is located, and returns the relevant attribute information to the agent.
  • step S708 the agent sends certificate generation requests CSR to the server in batches according to the attribute information of the nodes.
  • step S709 the server signs the attribute information of the node, and returns the node identity file carrying the signature to the agent, and the node identity file also includes the identity status of the node.
  • step S710 the agent enters the working state and starts the workload monitoring mode.
  • step S711 the workload starts to enter the initial state.
  • the first node prover identifies the process ID of the workload through the kernel mode or user mode of the current node according to the process controller PID, determines the startup information based on the process ID, and sends the startup information to the agent.
  • the kernel mode runs operating system programs and operates hardware
  • the user mode runs user programs.
  • step S713 the agent matches the registration information of the workload based on the startup information of the workload. If the matching is successful, execute step S714; if the matching is unsuccessful, return to step S711.
  • step S714 the workload calls the workload API and obtains the workload identity file.
  • step S714 the workload enters the working state and executes the tasks of the cloud platform.
  • the asset meta information of the agent comes from the description of the virtual source virtual machine on the cloud platform or MANO background data, and the agent starts as a pod or container after the virtual machine is started.
  • Table 1 is an example of the asset meta information of the agent instance.
  • the following uses a cloud platform based on kubernetes as an example to introduce an example of trusted node authentication.
  • the workload can be deployment, service, pod, statefulSet; there are deployment files *.yaml at work, these files also exist on the server side, and in the service
  • the specification fields can be extracted according to the design model through scripts, and then registered in the identity database as the asset information of the application workload.
  • multiple field keywords are designed as the primary key of the index, such as: serviceAccountName, image, containerPort.
  • the workload When the workload is loaded in the initial state, it can also obtain its own characteristics and then verify and apply for identity to the agent.
  • the specification information is as follows:
  • the initial state of the application workload can extract the following information through the kubelet workload api, which contains all the characteristics of a trusted environment certificate:
  • the implementation of this application combines the currently implemented TCFS (TECS (Tulip Elastic Cloud System) Cloud Foundation Services) and cloud native architecture to provide a method for realizing east-west workload identity, and this method is based on the current runtime system In general, it can be deployed flexibly by developing certain common components. After implementation, whether it is access control, transmission security, or runtime control of application load, or the formulation of security policies for authorization, it provides more flexible and visible The method; provides a guarantee for zero trust in the field of ICT (information and communication technology) to secure access.
  • ICT information and communication technology
  • the identity management method provided by the embodiment of this application matches the startup information of the workload with the registration information, and sends the identity file to the workload if the matching is successful. Only the workload that receives the identity file can enter the working state. It prevents malicious or untrustworthy workloads from being implanted into the intranet operating environment, and improves the security of the intranet.
  • the present application provides an identity management device, which can be applied to an agent.
  • FIG. 8 is a functional block diagram of an identity management device provided by the present application.
  • the identity management device 800 includes: an acquisition module 801 , a matching module 802 and a sending module 803 .
  • the acquiring module 801 is configured to acquire the startup information of the workload based on the identity file request initiated by the workload; wherein, the identity file request is a request initiated when the workload enters an initial state.
  • the matching module 802 is configured to match the registration information of the workload based on the startup information of the workload; wherein, the registration information is information provided to the server when the workload is registered.
  • the sending module 803 is configured to send the workload identity file to the workload under the condition that the startup information matches the registration information successfully, so that the workload enters the working state based on the workload identity file.
  • the obtaining module 801 identifies the process ID of the workload through the kernel mode or user mode of the current node according to the process control symbol; determines the startup information based on the process ID.
  • the identity management device further includes a node authentication module configured to acquire node identity information; wherein, the node identity information is information capable of proving the identity of the current node; based on the node identity information Initiating a node identity authentication request to the server; receiving the node identity file, wherein the node identity file at least includes a node identity identifier. Initiate a node attribute information request to the server based on the node identity file; respond to the node attribute information returned by the server, initiate a certificate generation request CSR to the server based on the node attribute information; receive the server The returned node attribute authentication.
  • a node authentication module configured to acquire node identity information; wherein, the node identity information is information capable of proving the identity of the current node; based on the node identity information Initiating a node identity authentication request to the server; receiving the node identity file, wherein the node identity file at least includes a node identity identifier. Initiate a node attribute information request
  • the node attribute authentication includes a node identity file after signing the node attribute information and an identification of the node identity state.
  • the identity file is a credential file based on the asset information of the workload and established with a preset identity identification framework.
  • the identity identification framework is a SPIFFE framework.
  • the functions or modules included in the device provided in this embodiment can be used to implement the method described in the identity management method embodiment provided in the first aspect. For its specific implementation and technical effect, refer to the description of the method embodiment above. For brevity, I won't go into details here.
  • the identity management device matches the startup information of the workload with the registration information, and sends the identity file to the workload if the matching is successful. Only the workload that receives the identity file can enter the working state, avoiding Malicious or untrustworthy workloads are implanted into the intranet operating environment, which improves the security of the intranet.
  • the present application provides an electronic device, which includes: one or more processors 901; a memory 902, on which one or more programs are stored.
  • processors 901 When one processor executes, one or more processors implement any one of the above-mentioned identity management methods; one or more I/O interfaces 903 are connected between the processor and the memory, and are configured to realize the connection between the processor and the memory Information exchange.
  • the processor 901 is a device with data processing capability, which includes but not limited to a central processing unit (CPU), etc.
  • the memory 902 is a device with data storage capability, which includes but not limited to a random access memory (RAM, more specifically Such as SDRAM, DDR, etc.), read-only memory (ROM), electrified erasable programmable read-only memory (EEPROM), flash memory (FLASH); I/O interface (read-write interface) 903 is connected between processor 901 and memory 902 , can realize information interaction between the processor 901 and the memory 902, which includes but not limited to a data bus (Bus) and the like.
  • RAM random access memory
  • ROM read-only memory
  • EEPROM electrified erasable programmable read-only memory
  • FLASH flash memory
  • I/O interface (read-write interface) 903 is connected between processor 901 and memory 902 , can realize information interaction between the processor 901 and the memory 902, which includes but not limited to a data bus (Bus) and the
  • the processor 901 , the memory 902 and the I/O interface 903 are connected to each other through a bus, and further connected to other components of the computing device.
  • the embodiment of the present application provides a computer-readable medium, on which a computer program is stored, and when the computer program is executed by a processor, any one of the above-mentioned identity management methods is implemented.
  • Such software may be distributed on computer readable media, which may include computer storage media (or non-transitory media) and communication media (or transitory media).
  • computer storage media includes both volatile and nonvolatile media implemented in any method or technology for storage of information, such as computer readable instructions, data structures, program modules, or other data. permanent, removable and non-removable media.
  • Computer storage media include, but are not limited to, RAM, ROM, EEPROM, flash memory or other memory technology, CD-ROM, digital versatile disk (DVD) or other optical disk storage, magnetic cartridges, magnetic tape, magnetic disk storage or other magnetic storage devices, or can Any other medium used to store desired information and which can be accessed by a computer.
  • communication media typically embodies computer readable instructions, data structures, program modules, or other data in a modulated data signal such as a carrier wave or other transport mechanism, and may include any information delivery media .

Landscapes

  • Engineering & Computer Science (AREA)
  • Computer Security & Cryptography (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Signal Processing (AREA)
  • Stored Programmes (AREA)
  • Storage Device Security (AREA)

Abstract

本申请提供一种身份管理方法及装置、电子设备、计算机可读介质，该方法包括：基于工作负载发起的身份文件请求，获取工作负载的启动信息（S301）；其中，身份文件请求是工作负载进入初始态的情况下发起的请求；基于工作负载的启动信息匹配工作负载的注册信息（S302）；其中，注册信息是工作负载注册时提供给服务端的信息；在启动信息与注册信息匹配成功的情况下，向工作负载发送工作负载身份文件，以供工作负载进入工作态（S303）。

Description

身份管理方法及装置、电子设备、计算机可读介质
相关申请的交叉引用
本申请要求2021年9月30日提交给中国专利局的第202111159996.7号专利申请的优先权，其全部内容通过引用合并于此。
技术领域
本申请涉及但不限于云安全和身份安全技术领域。
背景技术
基于云安全的“零信任”技术框架及方案的快速落地，对身份的可信识别相比于以往的基于网络边界的可信识别有了更高要求。
传统南北向的身份认证主要是基于PKI(Public Key Infrastructure，公钥基础设施)的CA(Certificate Authority，证书授权中心)证书机制，CA证书的签发、生命周期管理主要是依靠可信的根节点或导入可信列表使授信节点来审核并人工签发和维护。东西向内部数据安全在零信任思想下，需要通过身份认证进行更多的传输层TLS(传输层安全协议)安全防护和访问控制策略授权，东西向用户身份更多的体现在非人类用户的工作负载，包括虚机、pod、容器、应用APP等。在云化的环境下，东西向身份认证因为平台、架构、管理控制平面划分等的机制不同，没有统一成熟的实践案例，而且，云原生的集群服务编排布署、服务网格等开源社区方面的实践案例，并不能满足零信任多源持续评估、授权在商用场景下的身份管理。
发明内容
第一方面，本申请提供一种身份管理方法，包括：基于工作负载发起的身份文件请求，获取所述工作负载的启动信息；其中，所述身份文件请求是所述工作负载进入初始态的情况下发起的请求；基于所述工作负载的启动信息匹配所述工作负载的注册信息；其中，所述 注册信息是所述工作负载注册时提供给服务端的信息；在所述启动信息与所述注册信息匹配成功的情况下，向所述工作负载发送所述工作负载身份文件，以供所述工作负载进入工作态。
第二方面，本申请提供一种身份管理装置，包括：获取模块，配置为基于工作负载发起的身份文件请求，获取所述工作负载的启动信息；其中，所述身份文件请求是所述工作负载进入初始态的情况下发起的请求；匹配模块，配置为基于所述工作负载的启动信息匹配所述工作负载的注册信息；其中，所述注册信息是所述工作负载注册时提供给服务端的信息；发送模块，配置为在所述启动信息与所述注册信息匹配成功的情况下，向所述工作负载发送所述工作负载身份文件，以供所述工作负载基于所述工作负载身份文件进入工作态。
第三方面，本申请提供了一种电子设备，包括：一个或多个处理器；存储装置，其上存储有一个或多个程序，当所述一个或多个程序被所述一个或多个处理器执行时，使得所述一个或多个处理器实现本文任意一项所述的方法；一个或多个I/O接口，连接在所述处理器与存储器之间，配置为实现所述处理器与存储器的信息交互。
第四方面，本申请提供了一种存储介质，其上存储有计算机程序，所述计算机程序被处理器执行时实现本文任意一项所述的方法。
附图说明
图1为本申请提供的身份管理方法所采用的硬件设备示意图；
图2为本申请中代理端的结构示意图；
图3为本申请提供的一种身份管理方法的流程图；
图4为本申请提供的一种节点认证的流程图；
图5为本申请提供的一种工作负载认证的流程图；
图6为本申请提供的一种服务端启动的流程图；
图7为本申请提供的一种服务端、代理端与工作负载之间的交互流程图；
图8为本申请提供的一种身份管理装置的原理框图；
图9为本申请提供的一种电子设备的原理框图。
具体实施方式
为使本领域的技术人员更好地理解本申请的技术方案，下面结合附图对本申请提供的服务器进行详细描述。
在下文中将参考附图更充分地描述示例实施方式，但是所述示例实施方式可以以不同形式来体现且不应当被解释为限于本文阐述的实施方式。反之，提供这些实施方式的目的在于使本申请透彻和完整，并将使本领域技术人员充分理解本申请的范围。
如本文所使用的，术语“和/或”包括一个或多个相关列举条目的任何和所有组合。
本文所使用的术语仅用于描述特定实施方式，且不意欲限制本申请。如本文所使用的，单数形式“一个”和“该”也意欲包括复数形式，除非上下文另外清楚指出。还将理解的是，当本说明书中使用术语“包括”和/或“由……制成”时，指定存在所述特征、整体、步骤、操作、元件和/或组件，但不排除存在或添加一个或多个其它特征、整体、步骤、操作、元件、组件和/或其群组。
本文所述实施方式可借助本申请的理想示意图而参考平面图和/或截面图进行描述。因此，可根据制造技术和/或容限来修改示例图示。因此，实施方式不限于附图中所示的实施方式，而是包括基于制造工艺而形成的配置的修改。因此，附图中例示的区具有示意性属性，并且图中所示区的形状例示了元件的区的具体形状，但并不旨在是限制性的。
除非另外限定，否则本文所用的所有术语(包括技术和科学术语)的含义与本领域普通技术人员通常理解的含义相同。还将理解，诸如那些在常用字典中限定的那些术语应当被解释为具有与其在相关技术以及本申请的背景下的含义一致的含义，且将不解释为具有理想化或过度形式上的含义，除非本文明确如此限定。
基于云计算的东西向身份认证在证书管理方面出现了一些开源项目，比如kubernetes cert-manger或是cert-manager-istio-csr，这些开源项目与东西向流量的管理面或控制面节点结合，来关联上级根 CA(Certificate Authority，证书颁发机构)并对身份证书文件进行生命周期管理。然而，这种开源项目默认工作负载的请求身份ID可信，如：默认kubernetes(K8S)集群内微服务身份service account可信，身份ID未经全局统一管理，无法阻止仿冒者冒充身份，同时身份私钥没有安全存储，容易泄露。
除此之外，在获取身份后，一般需要通过静态身份文件挂载到工作负载(比如pod),便于MTLS(Mutual Transport Layer Security,双向传输加密通道)使用，然而，工作负载的身份不能在管理面呈现，也没有与其它属性相关联，扩展不足，未来对零信任的自动多源评估授权具有一定的限制性。
本申请提供的身份管理方法，该方法是基于云原生编排布署或服务网格管理架构的身份管理方案，只有在布署蓝图或编排布署计划内允许的工作负载才能得到统一分配的身份，才可以上电进入工作态，避免了不可信工作负载恶意植入内网运行环境。
本申请提供的身份管理方法是在内网环境中部署或嵌入服务端和代理端，服务端可以是一个，代理端可以是多个，而且服务端和代理端的部署和嵌入不会对现有内网环境造成影响。服务端可以对代理端和应用工作负载的可信环境进行识别，并为工作负载自动化构建与编排布署信息相一致的身份凭据，工作负载在取得身份并通过认证后，可以保证与其他实体相互访问的安全性，例如，使用该身份在实体间建立双向传输加密通道(mTLS)时实现握手认证。
图1为本申请提供的身份管理方法所采用的硬件设备示意图。如图1所示，服务端11作为一个独立的逻辑组件可以部署在云平台管理系统中，代理端12部署在节点，代理端12通过代理接口，即，节点API(Node API)13与服务端信号连接。在服务端11内设置有第一节点证明器111、节点解析器112、数据商店(data store)113、第一密钥管理器(key manager)114、向上授权(upstream Authority)中心115。如本领域技术人员所理解，CLI意指人工操作的命令行界面，比如网管EMS客户端,用于发起请求或注册等。
其中，数据商店(data store)113与后台的配置库16、身份数 据库(identify SQL)17信号连接，以供数据商店113能够获取后台的配置库16和身份数据库17中的数据。云平台管理系统通过注册接口(register API)与后台的配置库16、身份数据库(identify SQL)17信号连接。向上授权(upstream Authority)中心115与数字证书授权机构(CA)18信号连接。
代理端12设置有工作负载接口14，用于与工作负载15进行信息交互，每个代理端12可以与一个或多个工作负载15信号连接。
在一些实施方式中，第一节点证明器111用于与第二节点证明器21配合，来证明节点进行认证。节点解析器112是一个扩展组件，当节点的身份认证后，利用节点解析器112获取基于选择器的属性标签。数据商店113属于数据接口组件，用来存储、查询和更新各种信息。例如，注册条目、哪些节点已证明、已证明的节点的选择器是什么等。数据商店113可以内置内存数据库SQLite，也可以连接云平台的后台数据库，如配置库16和身份数据库17。第一密钥管理器114用于管理或存储基于x.509或JWT(Json web token，杰森网页令牌)用到的私钥，私钥存储在与第一密钥管理器信号连接的本地存储器Mem中。向上授权中心115用于扩展对接外部的其它PKI(Public Key Infrastructure，公钥结构)的组件。
图2为本申请中代理端的结构示意图。如图2所示，代理端包括第二节点证明器21、工作负载解析器22和第二密钥管理器23。
第二节点证明器21用于与第一节点证明器111配合，用以对节点进行认证。工作负载解析器22通过从节点操作系统查询有关进程的信息，并将该进程信息与在使用选择器注册工作负载的属性时提供给服务端的信息进行比较，从而验证节点上工作负载进程的身份是否可用。第二密钥管理器23用于生成和使用发布给工作负载的基于X.509的私钥。
在一些实施方式中，配置库16用于布署蓝图，以及物理工作负载上电后，云平台在后台数据库中可以看到的配置信息、模型视图或脚本等。身份数据库17用于存储spiffe id以及与该spiffe id关联的其它数据库的视图，以及根据身份查询、索引资产信息。
本申请提供的身份管理方法，该方法可应用于代理端。图3为本申请提供的一种身份管理方法的流程图。如图3所示，本申请提供的身份管理方法可以包括步骤S301至S303。
在步骤S301中，基于工作负载发起的身份文件请求，获取工作负载的启动信息；其中，身份文件请求是工作负载进入初始态的情况下发起的请求。
在步骤S302中，基于工作负载的启动信息匹配工作负载的注册信息；其中，注册信息是工作负载注册时提供给服务端的信息。
在步骤S303中，在启动信息与注册信息匹配成功的情况下，向工作负载发送工作负载身份文件，以供工作负载进入工作态。
举例来说，工作负载实例的身份凭据(证书)在该工作负载实例启动时生成(可以通过云平台提供的基于HSM(硬件安全模块)和PKI的安全服务获取)，并通过服务端对外公开，根据控制策略，一个工作负载实例可以有多个身份标识(ID)，身份ID的格式可以采用spiffe定义，但身份凭据只有一份，从身份凭据中可以随时按场景提取身份ID中携带的资产属性，同时，因为在颁发身份凭据证书文件时，至少验证域的所有权；基于此，对于实例的身份证书采用x.509-SVID格式。
在一些实施方式中，在工作负载启动并进入初始态后，向代理端发出身份文件请求。代理端收到身份文件请求后，获取工作负载的启动信息。工作负载的启动信息包括但不限于工作负载的类型、运行区域等信息。
在一些实施方式中，工作负载的注册信息包括资产信息元数据。在布署阶段，工作负载的资产信息元数据可以利用脚本工具从布署蓝图或编排、资源文件中提取，而且可以按用途、所有者或环境等将元数据抽象成一组标签，元数据由一个键和一个可选值组成。考虑到未来运行时控制或授权需要，为每个工作负载实例构建一个或多个遵循SPIFFE规范形式的身份ID，并创建该身份ID与工作负载的资产多对一的索引关系后，存入身份数据库。
在一些实施方式中，通过开局安装布署后，工作负载的元数据 信息在云平台的(后端)配置库和身份数控中已结构化，对外可以唯一标识一个工作负载实体；通过在云平台网管中的物理或虚拟资源来同步工作负载的资产信息。其中，工作负载的资产信息可以是主机、VIM、虚机、POD、容器(docker)、APP。
在一些实施方式中，在启动信息与注册信息无法匹配成功的情况下，工作负载仍然处于初始态，直至匹配成功后，才能获取身份文件，并进入工作态。
在一些实施方式中，在步骤S301中，获取工作负载的启动信息，包括：根据进程控制符通过当前节点的内核态或用户态识别工作负载的进程ID；基于进程ID确定启动信息。
在一些实施方式中，在步骤S301之前，还可以对节点进行认证，即首先对节点进行认证，再对设置在节点的工作负载进行认证。
代理端在首次连接服务端时需要进行身份认证，该认证过程也称为节点认证。在节点认证期间，代理端和服务端一起验证运行该代理端的节点的身份。通过在节点中布署的节点证明器组件进行实施。所有节点证明器都向节点及其环境询问只有该节点拥有的信息片段，以证明该节点的身份。节点认证的结果是代理端收到服务端分配的唯一身份ID。
在本实施方式中，节点身份ID和工作负载ID均是由服务端统一签发管理，减少静态身份凭证散落在云化的各个节点的工作负载中，提高了安全性。
在一些实施方式中，节点的认证过程包括：获取节点身份信息；其中，节点身份信息是能够证明当前节点身份的信息；基于节点身份信息向服务端发起节点身份认证请求；接收节点身份文件，节点身份文件中包括节点身份ID。
节点身份ID充当该代理端负责的工作负载的“父级”，工作负载的身份ID可以有多个，多个工作负载身份ID可以组合为一个结构链表，并可以与节点身份ID共同构建成新的SPIFFE结构的身份ID。
在对节点进行认证的过程中，代理端和服务端通过第一节点证 明器和第二节点证明器向云平台获取节点的元数据，未来节点通过节点解析器，可以验证有关节点的其他属性来识别节点的其它身份(如网络功能虚拟化接口)。
图4为本申请提供的一种节点认证的流程图。其中，VNFI表示虚拟化的网络功能模块实例，VIM表示虚拟化基础设施管理器，NFVO表示网络功能虚拟化编排器，VNFM表示虚拟化的网络功能模块管理器。如图4所示，节点认证步骤可以包括步骤S401至S404。
在步骤S401中，在代理端的第二节点证明器通过云底座(主要是网络功能虚拟化基础设施，NFVI)获取节点身份元信息。
在步骤S402中，第二节点证明器向服务端的第一节点证明器发送节点身份元信息。
在步骤S403中，服务端的第一节点证明器解析节点身份元信息。
在步骤S404中，在认证节点合法有效时，向代理端颁发节点认证，如x.509节点证书。
在一些实施方式中，如果云平台是基于编排布署的平台，代理端作为一个服务，在上电的初始态通过获取主机及虚机实例ID，以及集群成员的节点信息。例如，代理端在上电的初始态使用Kubernetes Service Account令牌获取主机及虚机实例ID，以及集群成员的节点信息。
需要说明的是，在代理端和服务端初次认证时，可使用预置的共享密钥对代理端进行认证，在初次认证通过后，再利用令牌机制替代共享密钥。另外，为了防止共享密钥的滥用，加入令牌机制后，共享密钥立即过期。
在一些实施方式中，代理端和服务端在启动时提供外部注入API，提前在节点或服务端导入的x.509证书，用于初始节点认证过程的可靠传输。
在一些实施方式中，接收节点身份文件之后，节点的认证过程还包括：基于节点身份文件向服务端发起节点属性信息请求；响应服务端返回的节点属性信息，基于节点属性信息向服务端发起证书生成请求CSR(Certificate Signing Request)；接收服务端返回的节点属 性认证。
其中，节点属性认证包括对节点属性信息进行签名后的节点身份文件和节点身份状态的标识。
在一些实施方式中，身份文件是基于工作负载的资产信息，并以预设的身份标识框架建立的身份凭证文件。其中，身份标识框架为SPIFFE框架。
在一些实施方式中，工作负载包括部署资源deployment、pod、容器docker和应用中的至少一种。
在本申请中，工作负载获得了身份标识并与资产相关联，即身份标识的粒度扩展到了容器、应用进程，使得身份标识除了标识工作负载外，附加了更多的属性信息。通过身份标识可以提取工作负载的特征信息，在云平台的管理后台或运行时可通过批量或通配的方式对工作负载进行控制及管理；同时使身份标识从云原生或虚拟化的调用虚机或pod延伸到容器、应用进程。
在本实施方式中，节点身份ID和工作负载身份ID均遵行身份定义安全的思想，利用工作负载的资产信息，每个资产信息相当于一个标签，利用标签式角色管理，解决用户多身份问题，多级标签按层次构成一个身份ID。当节点身份ID采用SPIFFE框架时，节点身份ID是一个字符串，其可以唯一地标识工作负载，工作负载可以有多个实例，且格式开放，可以是路径、用户等形式。
本申请打破了传统的x.509的CA证书作为身份凭据，在东西向中引入了一种工作负载安全标识框架SPIFFE，提高了互操作性，能提供完美的与客户系统兼容的标识。在云化的东西向数据流中，提供一个统一的工作负载标识框架是极具意义的，SPIFFE框架主要包括三部分内容：SPIFFE ID规范、SVID身份标识文档标准、工作负载身份化API，本实施方式对此不作重点描述。
本申请采用SPIFFE框架构建身份ID模型，在该身份ID中可以包括设备标识、网络标识、服务标识、工作负载标识、磁盘标识、进程标识和资源信息。例如：身份ID的形式如下：
Spiffe://设备标识/网络标识/服务标识/工作负载标识/磁盘标识/ 进程标识/资源信息标识。
节点身份ID可以根据需要设计，但需要在一个云平台中唯一，在部署蓝图导入后计算分配或手动配置导入后台数据库。
节点身份ID的形式如下：
spiffe://云底座标识/版本/物理主机标识/虚机标识/命名空间/服务标识。
例如：spiffe://zte.com/v1/host/vm/default/service_redis；
spiffe://zte.com/v1/host/vm/default/service_store。
工作负载的身份ID可以由服务端组合，也可由代理端中的工作负载解析器按约定形式组合。
工作负载的身份ID：形式如下：
spiffe://代理身份ID/进程标识/角色(角色也可以替换为通过唯一编号关联的自定义属性、资产或结构)。
例如：
spiffe://zte.com/v1/NVF-ZTE-JS-0011/default/service_redis/pod_pid_1088/
redis_write；
spiffe://zte.com/v1/NVF-ZTE-JS-001/default/service_redis/pod_pid_1088/
redis_read。
在一些实施方式中，代理端通过询问本地可用的权限(例如：基于kubernetes布署时，通过节点所在的操作系统内核或运行在同一节点上的kubelet)，来识别当前工作负载的运行属性，将这些属性与注册工作负载属性时提供给服务端的信息进行比较，最终确定运行过程所属的对象。
图5为本申请提供的工作负载认证的流程图。如图5所示，工作负载认证可以包括步骤S501至S505。
在步骤S501中，工作负载向代理端发起工作负载文件请求。
在一些实施方式中，工作负载调用工作负载API以向代理端请求工作负载的身份文件。例如：在Unix系统上，工作负载API可以 是Unix域套接字方式。其中，工作负载可以是pod、容器、应用进程等。
在步骤S502中，代理询问节点的内核以识别调用者的进程ID，并调用任何配置的工作负载证明器插件，为这些工作负载证明器插件提供工作负载的进程ID。
在步骤S503中，工作负载证明器使用进程ID来发现有关工作负载实例化的其他信息，并在必要时查询相邻的特定云平台的组件(例如Kubernetes kubelet)。
需要说明的是，这些特定云平台组件在布署时与代理端驻留在同一节点上。
在步骤S504中，工作负载证明器将发现的有关工作负载实例化的其他信息以选择器的形式返回给代理端。如：在kubernetes系统上的selector，selector:redis)
在步骤S505中，代理端通过将发现的选择器与注册信息进行比较，以确定工作负载的身份，并将正确的缓存的身份证明文件返回给工作负载。
在一些实施方式中，服务端可以获取云平台当前的计算资源分配与编排信息。具体实施，服务端可以部署在云平台管理系统中，以便于获取计算资源分配与编排信息。例如，在NFV场景中，服务端可以部署在MANO(Management and Orchestration，管理和编排)中，以便直接获取本地配置库中的服务、微服务蓝图信息。
图6为本申请提供的一种服务端启动的流程图。如图6所示，服务端的启动步骤可以包括步骤S601至S606。
在步骤S601中，从配置库读取启动信息。
在配置服务端时，将服务端的信息存储在配置库中。当服务端启动时，从配置库读取服务端的启动信息。
在步骤S602中，服务端基于启动信息判断是否存在上级CA管理中心，若判断结果为存在上级CA管理中心，则执行步骤S607；若判断结果为不存在上级CA管理中心，则执行步骤S603。
在步骤S603中，服务端生成签名证书，该签名证书是服务端自 己的签名证书。
在步骤S604中，服务端基于签名证书生成信任配置请求，并向配置库发送信任配置请求。
在步骤S605中，服务端判断配置库是否基于信任配置请求更新配置库，若判断结果为成功更新配置库，则执行步骤S606；若判断结果为未成功更新配置库，则执行步骤S608。
在步骤S606中，服务端向身份数据库发送消息，以使身份数据库上电，同时允许注册身份(工作负载和代理端)。之后，服务器成功启动，进入工作态。
其中，注册身份是指允许代理端、工作负载在服务端注册身份。
在步骤S607中，通过证书管理器获取上级CA。
在步骤S608中，等待配置库就位，当配置库就位时，执行步骤S606。
图7为本申请提供的一种服务端、代理端与工作负载之间的交互流程图。如图7所示，服务器、代理端与工作负载之间的交互步骤可以包括步骤S701至S714。
在步骤S701中，代理端通过引导程序获取节点身份信息。
在步骤S702中，代理端向服务端发起节点身份认证请求，若代理端未发起节点身份认证请求，则结束代理端的启动。
在步骤S703中，服务端验证节点身份凭证是否有效，在节点身份有效时，执行步骤S704，在节点身份无效时，结束代理端的启动。
在步骤S704中，服务端解析节点身份凭据，在成功解析节点身份凭据时，执行步骤S705，在未能成功解析节点身份凭证时，结束代理端的启动。
在步骤S705中，服务端对节点身份凭据发起匹配查询，在获得匹配结果时，执行步骤S706，在没有匹配到结果时，结束代理端的启动。
在步骤S706中，服务端向代理端发送节点身份文件，该节点身份文件至少包括节点身份ID。
在步骤S707中，代理端利用节点身份ID向服务端发起TLS， 以获得代理端所在节点所有已登记的相关属性信息，并将相关属性信息返回给代理端。
在步骤S708中，代理端根据节点的属性信息批量向服务端发起证书生成请求CSR。
在步骤S709中，服务端对节点的属性信息进行签名，并向代理端返回携带签名的节点身份文件，而且，该节点身份文件中还包括节点的身份状态。
在步骤S710中，代理端进入工作态，并开启工作负载侦听模式。
在步骤S711中，工作负载启动进入初始态。
在步骤S712中，第一节点证明器根据进程控制符PID通过当前节点的内核态或用户态识别工作负载的进程ID，基于进程ID确定启动信息，并将启动信息发送给代理端。其中，内核态运行操作系统程序，操作硬件，用户态运行用户程序。
在步骤S713中，代理端基于工作负载的启动信息匹配工作负载的注册信息，在匹配成功时，执行步骤S714；在匹配不成功时，返回步骤S711。
在步骤S714中，工作负载调用工作负载API，并获取工作负载身份文件。
在步骤S714后，工作负载进入工作态，执行云平台的任务。
在一些实施方式中，代理端的资产元信息来自与云平台或MANO后台数据上关于虚拟源虚机的描述，代理端在虚机启动后作为pod或容器启动。
表1为代理端实例资产元信息的示例。
表1
Figure PCTCN2022121580-appb-000001
下面以基于kubernetes的云平台为例，介绍可信节点认证的示例。
对于云底座来自于kubernetes或是服务网格istio来说，工作负载可以是deployment、service、pod、statefulSet；在工作时都有布署文件*.yaml，这些文件在服务端也都存在，在服务端上电时可以通过脚本按设计模型提取规约字段，然后作为应用工作负载的资产信息登记在身份数据库中，同时设计多个字段关键字作为索引的主键，比如：serviceAccountName、image、containerPort。
工作负载加载在初始态的时候也可以获取自己的特征后向代理验证并申请身份。
例如，规约信息如下：
Figure PCTCN2022121580-appb-000002
应用工作负载初始态通过kubelet workload api可提取信息如下，含有可信环境证明的所有特征：
Figure PCTCN2022121580-appb-000003
Figure PCTCN2022121580-appb-000004
Figure PCTCN2022121580-appb-000005
本申请实施方式结合当前已实现TCFS(TECS(Tulip Elastic Cloud System)Cloud Foundation Services)和云原生架构，提供了一种实现东西向工作负载身份的方法，并且该方法建立于现在的运行时体系之上，通过开发一定的通用组件即可灵活布署，实现后不管是接入控制、传输安全或在对应用负载的运行时控制上，或是制定安全策略进行授权时，都提供了更灵活可见的方法；为零信任在ICT(信息与通信技术)领域的东西向安全访问提供了保障。
本申请实施方式提供的身份管理方法，通过工作负载的启动信息和注册信息进行匹配，并在匹配成功的情况下，向工作负载发送身份文件，只有收到身份文件的工作负载才能进入工作态，避免了恶意或不可信工作负载植入内网运行环境，提高了内网的安全性。
第二方面，本申请提供一种身份管理装置，该装置可应用于代理端。
图8为本申请提供的一种身份管理装置的原理框图。如图8所示，身份管理装置800包括：获取模块801、匹配模块802和发送模块803。
获取模块801，配置为基于工作负载发起的身份文件请求，获取工作负载的启动信息；其中，身份文件请求是工作负载进入初始态的情况下发起的请求。
匹配模块802，配置为基于工作负载的启动信息匹配工作负载的注册信息；其中，注册信息是工作负载注册时提供给服务端的信息。
发送模块803，配置为在启动信息与注册信息匹配成功的情况下，向工作负载发送工作负载身份文件，以供工作负载基于工作负载身份文件进入工作态。
在一些实施方式中，获取模块801根据进程控制符通过当前节点的内核态或用户态识别所述工作负载的进程ID；基于所述进程ID确定所述启动信息。
在一些实施方式中，身份管理装置还包括节点认证模块，该节点认证模块配置为获取节点身份信息；其中，所述节点身份信息是能够证明所述当前节点身份的信息；基于所述节点身份信息向所述服务端发起节点身份认证请求；接收所述节点身份文件，其中，节点身份文件中至少包括节点身份标识。基于所述节点身份文件向所述服务端发起节点属性信息请求；响应所述服务端返回的节点属性信息，基于所述节点属性信息向所述服务端发起证书生成请求CSR；接收所述服务端返回的节点属性认证。
在一些实施方式中，节点属性认证包括对所述节点属性信息进行签名后的节点身份文件和所述节点身份状态的标识。
在一些实施方式中，所述身份文件是基于所述工作负载的资产信息，并以预设的身份标识框架建立的凭证文件。
在一些实施方式中，所述身份标识框架为SPIFFE框架。
本实施方式提供的装置具有的功能或包含的模块可以用于执行 第一方面提供的身份管理方法实施方式描述的方法，其具体实现和技术效果可参照上文方法实施方式的描述，为了简洁，这里不再赘述。
本申请提供的身份管理装置，通过工作负载的启动信息和注册信息进行匹配，并在匹配成功的情况下，向工作负载发送身份文件，只有收到身份文件的工作负载才能进入工作态，避免了恶意或不可信工作负载植入内网运行环境，提高了内网的安全性。
第三方面，参照图9，本申请提供一种电子设备，其包括：一个或多个处理器901；存储器902，其上存储有一个或多个程序，当一个或多个程序被一个或多个处理器执行时，使得一个或多个处理器实现上述任意一项的身份管理方法；一个或多个I/O接口903，连接在处理器与存储器之间，配置为实现处理器与存储器的信息交互。
其中，处理器901为具有数据处理能力的器件，其包括但不限于中央处理器(CPU)等；存储器902为具有数据存储能力的器件，其包括但不限于随机存取存储器(RAM，更具体如SDRAM、DDR等)、只读存储器(ROM)、带电可擦可编程只读存储器(EEPROM)、闪存(FLASH)；I/O接口(读写接口)903连接在处理器901与存储器902间，能实现处理器901与存储器902的信息交互，其包括但不限于数据总线(Bus)等。
在一些实施方式中，处理器901、存储器902和I/O接口903通过总线相互连接，进而与计算设备的其它组件连接。
第四方面，本申请实施方式提供一种计算机可读介质，其上存储有计算机程序，所述计算机程序被处理器执行时实现上述任意一种身份管理方法。
本领域普通技术人员可以理解，上文中所申请方法中的全部或某些步骤、系统、装置中的功能模块/单元可以被实施为软件、固件、硬件及其适当的组合。在硬件实施方式中，在以上描述中提及的功能模块/单元之间的划分不一定对应于物理组件的划分；例如，一个物理组件可以具有多个功能，或者一个功能或步骤可以由若干物理组件合作执行。某些物理组件或所有物理组件可以被实施为由处理器，如中央处理器、数字信号处理器或微处理器执行的软件，或者被实施为 硬件，或者被实施为集成电路，如专用集成电路。这样的软件可以分布在计算机可读介质上，计算机可读介质可以包括计算机存储介质(或非暂时性介质)和通信介质(或暂时性介质)。如本领域普通技术人员公知的，术语计算机存储介质包括在用于存储信息(诸如计算机可读指令、数据结构、程序模块或其它数据)的任何方法或技术中实施的易失性和非易失性、可移除和不可移除介质。计算机存储介质包括但不限于RAM、ROM、EEPROM、闪存或其它存储器技术、CD-ROM、数字多功能盘(DVD)或其它光盘存储、磁盒、磁带、磁盘存储或其它磁存储装置、或者可以用于存储期望的信息并且可以被计算机访问的任何其它的介质。此外，本领域普通技术人员公知的是，通信介质通常包含计算机可读指令、数据结构、程序模块或者诸如载波或其它传输机制之类的调制数据信号中的其它数据，并且可包括任何信息递送介质。
本文已经示出了示例实施方式，并且虽然采用了具体术语，但它们仅用于并仅应当被解释为一般说明性含义，并且不用于限制的目的。在一些实例中，对本领域技术人员显而易见的是，除非另外明确指出，否则可单独使用与特定实施方式相结合描述的特征、特性和/或元素，或可与其它实施方式相结合描述的特征、特性和/或元件组合使用。因此，本领域技术人员将理解，在不脱离由所附的权利要求阐明的本申请的范围的情况下，可进行各种形式和细节上的改变。

Claims (11)

  1. 一种身份管理方法，包括：
    基于工作负载发起的身份文件请求，获取所述工作负载的启动信息；其中，所述身份文件请求是所述工作负载进入初始态的情况下发起的请求；
    基于所述工作负载的启动信息匹配所述工作负载的注册信息；其中，所述注册信息是所述工作负载注册时提供给服务端的信息；
    在所述启动信息与所述注册信息匹配成功的情况下，向所述工作负载发送所述工作负载身份文件，以供所述工作负载进入工作态。
  2. 根据权利要求1所述的方法，其中，所述获取所述工作负载的启动信息，包括：
    根据进程控制符通过当前节点的内核态或用户态识别所述工作负载的进程标识；
    基于所述进程标识确定所述启动信息。
  3. 根据权利要求1所述的方法，其中，所述基于工作负载发起的身份文件请求，获取所述工作负载的启动信息之前，所述方法还包括：
    获取节点身份信息；其中，所述节点身份信息是能够证明当前节点身份的信息；
    基于所述节点身份信息向所述服务端发起节点身份认证请求；
    接收节点身份文件，其中，节点身份文件中至少包括节点身份标识。
  4. 根据权利要求3所述的方法，其中，所述接收所述节点身份文件之后，所述方法还包括：
    基于所述节点身份文件向所述服务端发起节点属性信息请求；
    响应所述服务端返回的节点属性信息，基于所述节点属性信息向所述服务端发起证书生成请求CSR；
    接收所述服务端返回的节点属性认证。
  5. 根据权利要求4所述的方法，其中，所述节点属性认证包括对所述节点属性信息进行签名后的节点身份文件和所述节点身份状态 的标识。
  6. 根据权利要求1-5任一所述的方法，其中，所述身份文件是基于所述工作负载的资产信息，并以预设的身份标识框架建立的凭证文件。
  7. 根据权利要求6所述的方法，其中，所述身份标识框架为SPIFFE框架。
  8. 根据权利要求1-5任一项所述的方法，其中，所述工作负载包括部署资源deployment、pod、容器和应用中的至少一种。
  9. 一种身份管理装置，包括：
    获取模块，配置为基于工作负载发起的身份文件请求，获取所述工作负载的启动信息；其中，所述身份文件请求是所述工作负载进入初始态的情况下发起的请求；
    匹配模块，配置为基于所述工作负载的启动信息匹配所述工作负载的注册信息；其中，所述注册信息是所述工作负载注册时提供给服务端的信息；
    发送模块，配置为在所述启动信息与所述注册信息匹配成功的情况下，向所述工作负载发送所述工作负载身份文件，以供所述工作负载基于所述工作负载身份文件进入工作态。
  10. 一种电子设备，包括：
    一个或多个处理器；
    存储装置，其上存储有一个或多个程序，当所述一个或多个程序被所述一个或多个处理器执行时，使得所述一个或多个处理器实现根据权利要求1-8任意一项所述的方法；
    一个或多个I/O接口，连接在所述处理器与存储器之间，配置为实现所述处理器与存储器的信息交互。
  11. 一种计算机可读介质，其上存储有计算机程序，所述计算机程序被处理器执行时实现根据权利要求1-8任意一项所述的方法。
PCT/CN2022/121580 2021-09-30 2022-09-27 身份管理方法及装置、电子设备、计算机可读介质 WO2023051498A1 (zh)

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
CN202111159996.7 2021-09-30
CN202111159996.7A CN115913594A (zh) 2021-09-30 2021-09-30 身份管理方法及装置、电子设备、计算机可读介质

Publications (1)

Publication Number Publication Date
WO2023051498A1 true WO2023051498A1 (zh) 2023-04-06

Family

ID=85729505

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/CN2022/121580 WO2023051498A1 (zh) 2021-09-30 2022-09-27 身份管理方法及装置、电子设备、计算机可读介质

Country Status (2)

Country Link
CN (1) CN115913594A (zh)
WO (1) WO2023051498A1 (zh)

Citations (6)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20110087899A1 (en) * 2006-05-17 2011-04-14 Richard Fetik Firewall plus storage apparatus, method and system
US20180191697A1 (en) * 2016-12-31 2018-07-05 Entefy Inc. Multi-party authentication in a zero-trust distributed system
US20190141536A1 (en) * 2018-12-28 2019-05-09 Alexander Bachmutsky Multi-domain trust establishment in edge cloud architectures
CN109788040A (zh) * 2018-12-27 2019-05-21 北京航天智造科技发展有限公司 微服务授权与调度方法和系统
CN112929180A (zh) * 2021-02-05 2021-06-08 中国—东盟信息港股份有限公司 一种Kubernetes零信任网络安全系统及其实现方法
US20210281548A1 (en) * 2020-02-27 2021-09-09 Virtru Corporation Methods and systems for securing containerized applications

Patent Citations (6)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20110087899A1 (en) * 2006-05-17 2011-04-14 Richard Fetik Firewall plus storage apparatus, method and system
US20180191697A1 (en) * 2016-12-31 2018-07-05 Entefy Inc. Multi-party authentication in a zero-trust distributed system
CN109788040A (zh) * 2018-12-27 2019-05-21 北京航天智造科技发展有限公司 微服务授权与调度方法和系统
US20190141536A1 (en) * 2018-12-28 2019-05-09 Alexander Bachmutsky Multi-domain trust establishment in edge cloud architectures
US20210281548A1 (en) * 2020-02-27 2021-09-09 Virtru Corporation Methods and systems for securing containerized applications
CN112929180A (zh) * 2021-02-05 2021-06-08 中国—东盟信息港股份有限公司 一种Kubernetes零信任网络安全系统及其实现方法

Also Published As

Publication number Publication date
CN115913594A (zh) 2023-04-04

Similar Documents

Publication Publication Date Title
US11695757B2 (en) Fast smart card login
US11641361B2 (en) Dynamic access control to network resources using federated full domain logon
US10693916B2 (en) Restrictions on use of a key
US9063971B2 (en) Schema and query abstraction for different LDAP service providers
US8549326B2 (en) Method and system for extending encrypting file system
US9613224B2 (en) Integrating a user's security context in a database for access control
US10049205B2 (en) Asserting identities of application users in a database system based on delegated trust
US8990550B1 (en) Methods and apparatus for securing communications between a node and a server based on hardware metadata gathered by an in-memory process
US9639691B2 (en) Dynamic database and API-accessible credentials data store
US8302165B2 (en) Establishing trust relationships between computer systems
US10621111B2 (en) System and method for unified secure remote configuration and management of multiple applications on embedded device platform
WO2023051498A1 (zh) 身份管理方法及装置、电子设备、计算机可读介质
US11989279B2 (en) Method and system for service image deployment in a cloud computing system based on distributed ledger technology
US20230344648A1 (en) Chained cryptographically signed certificates to convey and delegate trust and authority in a multiple node environment
EP3766221B1 (en) Relying party certificate validation when client uses relying party's ip address
US20240064148A1 (en) System and method for managing privileged account access

Legal Events

Date Code Title Description
121 Ep: the epo has been informed by wipo that ep was designated in this application

Ref document number: 22874883

Country of ref document: EP

Kind code of ref document: A1