Policy Management in the Target Environment

Abstract

The examples described herein relate to policy management in a target environment. A workload attestation request including a workload specification of a workload is received. A workload profile is determined based on the workload specification. A policy stored in a policy database is identified based on the workload profile. An attestation identifier indicating the workload profile is provided in response to the workload attestation request. When a policy request including the attestation identifier is received from a controller node in the target environment, the policy is compiled from the policy database using the attestation identifier and provided to the controller node, which applies the policy in the target environment.

Description

BACKGROUND OF THE INVENTION

[0001] Cloud native computing is a method of building applications or workloads as a set of microservices that run in containers. Containers include the workload and necessary dependencies into a package, enabling the workload to be executable in different cloud environments. A workload orchestration platform is used to perform the deployment, management, and execution of containerized workloads across various cloud environments. The deployment and execution of the workload depend on the security of the cloud environment. BRIEF DESCRIPTION OF THE DRAWINGS

[0002] These and other features, aspects, and advantages of the present specification will be better understood when the following detailed description is read with reference to the accompanying drawings, in which like characters represent like parts, and in which:

[0003] Figure 1 depicts a networking system including a system for policy management at a target environment according to an example;

[0004] Figure 2 depicts a workload specification and an associated workload profile according to an example;

[0005] Figure 3 is a flowchart depicting a method for policy management in a target environment according to an example;

[0006] Figure 4A and 4B is a signal diagram depicting a method for policy management in a target environment according to another example;

[0007] Figure 5 is a block diagram depicting policy management in a target environment according to an example;

[0008] Figure 6 is a block diagram depicting a policy lifecycle manager for dynamically applying policies in a target environment according to an example; and

[0009] Figure 7 is a block diagram depicting a processing resource and a machine-readable medium encoded with example instructions for managing policies in a target environment according to an example.

[0010] It should be emphasized that in the drawings, the various features are not drawn to scale. In fact, in the drawings, the dimensions of the various features may have been increased or decreased for the sake of clarity of discussion. DETAILED DESCRIPTION

[0011] The following detailed description refers to the accompanying drawings. Wherever possible, the same reference numerals are used in the drawings and the following description to refer to the same or like parts. It should be clearly understood that the drawings are for illustrative and descriptive purposes only. Although several examples are described in this document, modifications, adaptations, and other implementations are possible. Therefore, the following detailed description does not limit the disclosed examples. Instead, the appropriate scope of the disclosed examples may be defined by the appended claims.

[0012] The terms used herein are for the purpose of describing particular examples and are not limiting. As used herein, the singular forms "a", "an", and "the" are also intended to include the plural forms unless the context clearly dictates otherwise. As used herein, the term "another" is defined as at least two or more. Unless otherwise stated, the term "coupled" as used herein is defined as connected, either directly without any intervening element or indirectly with at least one intervening element. For example, two elements can be connected mechanically, electrically, or communicatively through a communication channel, path, network, or system. Additionally, the term "and / or" as used herein refers to and encompasses any and all possible combinations of the associated listed items. It should also be understood that although the terms first, second, third, fourth, etc. may be used herein to describe various elements, these elements should not be limited by these terms since these terms are only used to distinguish one element from another unless otherwise stated or the context indicates otherwise. As used herein, the term "includes" means including but not limited to, and the term "including" means including but not limited to. The term "based on" means at least partially based on.

[0013] Cloud-native computing is a method of building applications or workloads as a set of microservices that run in containers. Containers package the workload and the necessary dependencies such that the workload is executable in different cloud environments. Examples of such workloads can include but are not limited to virtual machines, containers, pods, containerized applications, or any piece of code that can be implemented as a microservice.

[0014] Workloads can be managed by a workload orchestration system such as Kubernetes. The workload orchestration system can operate on a computing node (hereinafter referred to as a controller node). The controller node can receive a workload deployment request to deploy a workload on one or more target cloud environments and schedule the deployment of the workload. Various features of cloud-native computing, such as microservices architecture, modern design, containerization, automation, etc., allow for faster development and delivery of new workloads and quick problem resolution.

[0015] However, the deployment, management, and execution of workloads depend on the security of the target environment and the workload. For example, the workload and the target environment can have specific controls and access rights to ensure that the security of the underlying target environment is not compromised and the risk of exposing workload data is reduced. The controls and access rights can be implemented based on a set of management rules (hereinafter referred to as policies). In some approaches, policies for managing the controls and access rights of workloads can be defined or created during workload development. Policies such as native policies can also be implemented by cloud providers to ensure the security and execution of workloads.

[0016] With the advancement of cloud-native technologies, the number of target environments is increasing continuously, so managing the policies for each target environment and each workload becomes a challenge. For example, each cloud environment can support thousands of workloads developed by different teams and organizations from various geographical locations. In addition, each workload may require different policies to implement a specific set of controls and access rights. Therefore, managing the policies for each workload based on the workload characteristics and the underlying structure of each target environment is tedious and labor-intensive.

[0017] In addition, some target environments may only provide native policies for controlling the infrastructure but may not provide the necessary policies once a workload is deployed. Moreover, applying the correct policies in the target environment may require continuous monitoring. For example, new updates to existing policies or updates to the workload version may require re-implementing or revoking certain policies. Some existing solutions do not provide dynamic collection of the latest policies required for the workload version. Therefore, applying policies in the target environment based on the behavior of the workload is a challenging task.

[0018] To this end, according to aspects of the present disclosure, dynamic policy management based on workload profiles is proposed. In some examples, a workload attestation request can be received from a workload creation node. The workload attestation request can include a workload specification of the workload. The workload profile can be determined based on the workload specification. Based on the workload profile, the policies stored in the policy database can be identified. In response to the workload attestation request, an attestation identifier indicating the workload profile can be provided to the workload creation node. In addition, a request for a policy can be received from a controller node at the target environment. The request can include the attestation identifier. Using the attestation identifier, the policy can be compiled from the policy database. In addition, the policy can be provided to the controller node, and the controller node can apply the policy in the target environment.

[0019] As will be appreciated, the examples presented herein facilitate enhanced dynamic policy management in cloud-native environments based on workload profiles. The examples presented herein reduce or eliminate the need for workload developers to define policies for workloads. A developer can provide only a workload specification, which can be used to attest to the workload using an attestation identifier. The attestation identifier can be used to dynamically compile relevant policies regardless of the number and type of target environments in which the workload is deployed. The dynamic compilation of policies based on the attestation identifier can provide enhanced performance and security for the workload on a target environment (e.g., a Kubernetes cluster), whether in a customer-owned or leased customer-internal private cloud data center or consumed as a public-use cloud provider's as-a-service offering (e.g., via a pay-per-use or consumption-based financial model). Additionally, the enhanced policy dynamic compilation affected by the various example aspects presented herein ensures that the latest policies required by the workload are applied at the target environment. For example, any updates to the policies in the policy database or to the workload can be considered before retrieving the policies from the policy database. Additionally, custom policies that are not available in the target environment can be compiled and applied based on the workload profile.

[0020] Referring now to the drawings, in Figure 1 FIG. 5, a networking system 100 according to an example is depicted. The networking system 100 can include a policy management system 102 (hereinafter referred to as system 102), a workload creation node 104, a policy database 106, and a target environment 108 that are coupled to each other via a network 110. In some examples, the networking system 100 can be a distributed system, where the policy management system 102, the workload creation node 104, the policy database 106, and the target environment 108 can be located in physically different locations (e.g., on different racks, in different chassis, in different buildings, in different cities, in different countries, etc.) while being connected via the network 110.

[0021] Examples of the network 110 can include, but are not limited to, an Internet Protocol (IP) or non-IP-based local area network (LAN), a wireless LAN (WLAN), a metropolitan area network (MAN), a wide area network (WAN), a storage area network (SAN), a personal area network (PAN), a cellular communication network, a public switched telephone network (PSTN), and the Internet. Communications on the network 110 can be performed according to various communication protocols, such as, but not limited to, Transmission Control Protocol and Internet Protocol (TCP / IP), User Datagram Protocol (UDP), IEEE 802.11, and / or cellular communication protocols. Communications on the network 110 can be via wired (e.g., copper wire, optical communication, etc.) or wireless (e.g., be implemented by communication technologies such as cellular communication, satellite communication, Bluetooth, etc. In some examples, network 110 can be enabled via a private communication link, including but not limited to communication links established via Bluetooth, cellular communication, optical communication, radio frequency communication, wired (e.g., copper), etc. In some examples, the private communication link can be a direct communication link between system 102, workload creation node 104, policy database 106, and target environment 108.

[0022] The workload creation node 104 can be a device including a processor or microcontroller and / or any other electronic components, or a device or system that can facilitate various workload development, computing, and / or data storage services. Examples of the workload creation node 104 can include but are not limited to desktop computers, laptop computers, smartphones, servers, computer appliances, workstations, storage systems, or converged or hyperconverged systems, etc. In Figure 1 While the networking system 100 is shown as including one workload creation node 104, the networking system 100 can include any number of workload creation nodes without limiting the scope of the present disclosure. In a given implementation of the networking system 100, the workload creation nodes 104 can have similar or different hardware and / or software configurations.

[0023] The term workload can refer to computing resources, including but not limited to applications (e.g., software programs), virtual machines (VMs), containers, PODs, or containerized applications. In some examples, a workload can include any code segment that can be developed as a microservice. As will be understood, a workload such as a VM can be an instance of an operating system hosted on a given worker node via a VM host program such as a hypervisor. Additionally, a workload such as a container can be a packaged application whose dependencies (e.g., operating system resources, processing allocation, memory allocation, etc.) are hosted on a given worker node via a container host program such as a container runtime (e.g., Docker engine). Further, in some examples, a workload can include a POD formed by grouping one or more containers. For example, a group of containers associated with a general application can be grouped to form a POD.

[0024] The target environment 108 can facilitate resources on which one or more workloads execute, such as computing, storage, and / or networking capabilities. Examples of the target environment 108 can include, but are not limited to, servers, server clusters, container orchestration systems (e.g., Kubernetes), container orchestration system clusters, computer appliances, workstations, desktop computers, laptop computers, smart phones, storage systems, or converged or hyperconverged systems, etc. For example, while some target environments may have high-end computing capabilities, some target environments may facilitate strong data security, and certain target environments may have enhanced heat dissipation capabilities. In Figure 1 the example, although the networking system 100 is shown as including one target environment 108, the networking system 100 can include any number of target environments without limiting the scope of the present disclosure.

[0025] In the description, for illustrative purposes, the workload 112 is described as an application and the target environment 108 is described as one or more Kubernetes clusters. Applications in containers can be managed via a container orchestration system (e.g., Kubernetes). In Figure 1 the example, the workload creation node 104 is shown as facilitating workload creation or development. For example, a developer can work on the workload creation node 104 to write and develop a workload. Although a single workload is shown as being developed at the workload creation node 104, as Figure 1 shown, the workload creation node 104 can facilitate the development of any number of workloads 112 depending on the corresponding hardware and / or software configuration. In some examples, the target environment 108 can also act as the workload creation node 104 and vice versa.

[0026] During or after developing the workload 112 at the workload creation node 104, a workload specification 114 can also be developed, which includes information about the characteristics of the workload 112. The characteristics of the workload can specify various access rights and control rights. For example, the access rights can include access to communication endpoints, such as port 80, port 443, port TCP / 5607. The control rights can include measures for controlling the behavior of the workload. For example, the control rights can include accepting only HTTPS, accepting only a certain number of requests, allowing only secure or encrypted SSH connections, or denying SSH / 22 connections. The system 102 can receive a workload attestation request 116 from the workload creation node 104 that includes the workload specification 114 corresponding to the workload 112 (in Figure 1Marked as WAR in Chinese). The system 102 can attest to the workload 112 based on the workload specification 114 and manage the policies required at the target environment 108 based on the attestation. For example, the system 102 can provide a workload attestation identifier 118 (marked as ATT_ID in Figure 1 Chinese) to the workload creation node 104. The workload attestation identifier 118 can provide a workload deployment request to the target environment 108. Additionally, the system 102 can also receive a policy request 120 from the target environment 108 for deploying the workload 112 in the target environment 108 (described later).

[0027] As Figure 1 shown, in some examples, for instance, the system 102 can be a device including a processor or microcontroller and / or any other electronic components, or a device or system that can facilitate various computing and / or data storage services. Examples of the system 102 can include, but are not limited to, a desktop computer, a laptop computer, a smart phone, a server, a computer appliance, a workstation, a storage system, or a converged or hyperconverged system, etc., configured to manage the policies for the workload 112 in the target environment 108. Additionally, in certain examples, the system 102 can be or can include a virtual machine or a containerized application executed on the hardware in the networked system 100.

[0028] In some examples, the system 102 can include processing resources 122 and a machine-readable medium 124. The machine-readable medium 124 can be any electronic, magnetic, optical, or other physical storage device that can store data and / or executable instructions 126. For example, the machine-readable medium 124 can include one or more of random access memory (RAM), electrically erasable programmable read-only memory (EEPROM), storage drives, flash memory, compact disc read-only memory (CD-ROM), etc. The machine-readable medium 124 can be non-transitory. As described in detail herein, the machine-readable medium 124 can be encoded with executable instructions 126 to perform one or more methods, such as Figure 3 , 4A and the methods described in 4B.

[0029] In addition, the processing resource 122 can be a physical device, e.g., one or more central processing units (CPUs), one or more semiconductor-based microprocessors, one or more graphics processing units (GPUs), an application specific integrated circuit (ASIC), a field programmable gate array (FPGA), other hardware devices capable of retrieving and executing instructions 126 stored in the machine-readable medium 124, or a combination thereof. The processing resource 122 can obtain, decode, and execute the instructions 126 stored in the machine-readable medium 124 to manage the policies of the workload (described further below). As an alternative or in addition to executing the instructions 126, the processing resource 122 can include at least one integrated circuit (IC), control logic, electronic circuitry, or a combination thereof, which includes a plurality of electronic components (described further below) for performing functions intended to be executed by the system 102. Further, in some examples, where the system 102 can be a virtual machine or a containerized application, the processing resource 122 and the machine-readable medium 124 can represent the processing resource and the machine-readable medium of the hardware or computing system that hosts the system 102 as a virtual machine or a containerized application.

[0030] During operation, the processing resource 122 can receive a workload attestation request 116 including a workload specification 114 from the workload creation node 104. In some examples, the processing resource 122 can receive the workload attestation request from a different workload creation node ( Figure 1 not shown in the figure). Each workload attestation request can include a workload specification associated with the workload developed on the corresponding workload creation node. Figure 2 is a block diagram 200 depicting an example list of a workload specification file 202 and a workload profile 204. The workload profile 204 can include various types of workloads. For example, application workloads can include a network application profile 204-1, a database application profile 204-2, a messaging application profile 204-3, a DevOps application profile 204-4, a machine learning application profile 204-5, and so on. In some examples, the workload profile 204 can be stored locally at the system 102, or, can be stored in a remote database accessible via the network 110. In some examples, the system 102 can receive the workload attestation request 116 in the form of a file. Upon receiving the workload attestation request 116, the processing resource 122 can store the file, e.g., the workload specification file 202, in the machine-readable medium 124.

[0031] The workload specification file 202 may include a workload specification 114 that describes the static and runtime behavior of the associated workload. In particular, the workload specification 114 may set certain requirements for the workload. In some examples, the workload specification file 202 may include configurations such as application ports, request privileges, ingress whitelists, authentication modes, exposure modes, etc. For each configuration, the workload specification may include a list of sub-configurations and associated values. For example, the application ports may include a list of sub-configurations such as port 80, port 8080, port 443, port 22, port 20, etc. The authentication mode may include certificate-based authentication. The ingress list may include a list of allowed sources (e.g., IP addresses 35.16.78.100, 35.16.78.101) and domains (e.g., hpe.com). For the request privileges, the sub-configurations may include the required root (true / false) and / or allow host network (yes / no). Each workload profile 204 includes some or all of the possible configurations and / or sub-configurations included in the workload specification. The workload profile 204 may have predefined values for the configurations and / or sub-configurations that are selected as prototypes for the workload represented by the workload profile. The predefined values of the workload profile 204 may also be modified periodically to avoid the latest security failures.

[0032] Referring again to Figure 1 , the system 102 may determine one or more workload profiles 204 based on the workload specification file 202. For example, the values of each sub-configuration in the workload specification file 202 may be used to identify one or more workload profiles 204. In some examples, determining one or more workload profiles 204 may be based on the best match between the configurations and sub-configurations of the workload specification file 202 and the corresponding predefined values of the workload profile 204.

[0033] System 102 can identify one or more policies stored in policy database 106 based on the determined workload profile 204. In some examples, policy database 106 can store multiple policies that can be applicable to target environment 108. In some examples, the multiple policies can include custom policies, global policies, or environment-specific policies. Global policies can be applicable to any environment, such as development, integration, or production environments. For example, global policies for a web application profile can include global access and control permissions, such as allowing only HTTPS or performing certificate authority verification. On the other hand, environment-specific policies can be applicable to a specific environment. For example, environment-specific policies for a web application profile in a development environment can include accepting a maximum of 100 requests per minute or allowing resource downtime during updates. Similarly, environment-specific policies for a web application profile in a production environment can include accepting a maximum of 1000 requests per minute or no resource downtime during updates. In various examples, policy database 106 can be a remote database implemented on a server or any other computing device discussed previously. Alternatively, policy database 106 can be a local database in system 102. Policy database 106 can use tags to link policies and workload profile 204. In some examples, modifications to the link between a policy and one or more workload profiles 204 can be performed in response to a malicious attack on the workload, a failure of the workload, non-execution of the workload, etc. In some examples, the link between a policy and a workload profile can also be modified through a user interface.

[0034] In accordance with aspects of the present disclosure, system 102 can facilitate the compilation of workload attestations and policies that are most suitable for the requirements of workload 112. In some examples, system 102 can provide attestation identifier 118 to workload creation node 104 in response to workload attestation request 116. The attestation identifier can indicate one or more workload profiles 204 associated with workload 112. In some examples, system 102 can automatically create attestation identifier 118 based on workload specification 114. Alternatively, in other examples, attestation identifier 114 can also be created based on external input provided by a separate computing system. For example, an administrator can manually review the workload specification by examining the workload design and architecture. The administrator can then approve the workload profile associated with workload 112. In some examples, both automatic and manual attestations can be performed.

[0035] In some examples, the workload creation node 104 may send a workload deployment request to deploy a workload in the target environment 108 to the controller node 128. The workload deployment request may include an attestation identifier 118. In response to the workload deployment request, the system 102 may receive a request for one or more policies for deploying the workload 112 from the controller node 128. The request 120 may include the attestation identifier. The system 102 may compile relevant policies from the policy database 106 using the attestation identifier 118. Compiling may include retrieving one or more policies associated with the attestation identifier from the policy database 106. In some examples, compiling may include retrieving relevant policy templates or policy statements for creating custom policies from the policy database 106 based on the workload profile 204. In some examples, the system may also check whether the attestation identifier is valid before compilation. For example, some attestation identifiers may be inactive after a certain period of time, or may not indicate an updated workload profile 204 associated with the workload 112.

[0036] Then, the system 102 may provide the policies to the controller node 128 for applying the policies in the target environment 108. It can be understood that the target environment 108 presented herein facilitates the scheduling and deployment of the workload 112. Specifically, in view of the advantages of enhanced policy compilation affected by the various example aspects presented herein, the workload 112 may be executed on a highly configured worker node with sufficient resources to meet the workload requirements. Applying policies based on the workload profile may provide enhanced performance and security for workloads on network systems (e.g., Kubernetes clusters) in customer premises or as-a-service offerings. Moreover, as the policies are updated or the workload versions are updated, the updated policies are automatically and dynamically compiled during runtime, and manual intervention may be reduced or eliminated. Examples of policy updates are described below with respect to Figure 4B proceed to describe.

[0037] Now refer to Figure 3 , according to an example, a flowchart depicting a method 300 for managing policies in the target environment 108 is presented. For illustrative purposes, method 300 will be described in connection with the networking system 100 of Figure 1 and the components of Figure 2 . Method 300 may include method blocks 302, 304, 306, 308, 310, 312, and 314 (collectively referred to hereinafter as blocks 302 - 314), which may be executed by a processor-based system, such as system 102. In particular, the operations at each of method blocks 302 - 314 may be performed by the processing resource 122 by executing instructions stored on a machine-readable medium 124 (see Figure 1) is executed by instruction 126 therein. Additionally, it should be noted that in some examples, the execution order of blocks 302-314 can be different from that Figure 3 shown. For example, blocks 302-314 can be executed in series, in parallel, or in a series-parallel combination.

[0038] At block 302, for example, processing resource 122 can receive a workload attestation request 116 for workload 112 from workload creation node 104. Workload attestation request 116 can include a workload specification 114 indicating the characteristics of workload 112, as described Figure 2 above. At block 304, processing resource 122 can determine one or more workload profiles 204 of workload 112 based on the received workload attestation request. Additionally, at block 306, processing resource 122 can identify one or more policies stored in policy database 106 based on the one or more workload profiles 204 determined at block 304. At block 308, processing resource 122 can provide an attestation identifier 118 to workload creation node 104. Attestation identifier 118 can indicate the one or more workload profiles 204 determined at block 304. Workload creation node 104 can send a workload deployment request for deploying workload 112 at target environment 108 to controller node 128. The workload deployment request can include attestation identifier 118. Additionally, at block 310, processing resource 122 can receive a policy request 120 from controller node 128 at target environment 108. The policy request can include attestation identifier 118. At block 312, processing resource 122 can compile a policy from policy database 106 using the attestation identifier. Additionally, at block 314, processing resource 122 can provide the policy to controller node 128 for applying the policy at target environment 108.

[0039] Now moving on to Figure 4A and 4B , according to another example, a sequence diagram depicting a method for policy management is presented. For illustrative purposes, sequences 400A and 400B will be described in connection with Figure 1 networking system 100. Figure 4ADepicts a sequence diagram for managing workload 112 during or prior to workload deployment in target environment 108. Sequence 400A can include 402, 404, 406, 408, 410, 412, 414, 416, 418, 420, 422, and 424 (collectively hereinafter referred to as 402 - 424), which can be executed by a processor-based system as described above. In particular, the operations of sequence 402 - 424 can be executed by processing resource 122 by executing instructions 126 stored in machine-readable medium 124. Additionally, it should be noted that in some examples, the execution order of 402 - 424 can be different from Figure 4A that shown. For example, the operations of 402 - 424 can be executed in series, in parallel, or in a series-parallel combination.

[0040] At 402, policy management system 426 can perform one or more policy actions on the policies stored in policy database 106 (example policy management system 426 will be described further below with respect to Figure 5 ). For example, at 404, processing resource 122 can receive a workload attestation request 116 for workload 112 from workload creation node 104. Workload attestation request 116 can include workload specification 114. Additionally, at 406, processing resource 122 can determine one or more workload profiles 204 based on workload specification 114. At 408, processing resource 122 can identify one or more policies stored in policy database 106. In some examples, identifying one or more policies can be performed automatically, while in other examples, policy management system 426 can manually identify one or more policies. Additionally, at 410, processing resource 122 can provide a response to workload creation node 104. The response can include an attestation identifier, which can indicate one or more workload profiles 204 associated with workload 112. In some examples, the attestation identifier can be modified based on user input manually provided by an administrator.

[0041] In addition, at 412, the target environment 108 can receive a workload deployment request including a proof identifier 118 of the workload 204 from the workload creation node 104. In some examples, the proof identifier can expire after a predetermined period of time. At 414, an admission network hook can listen for the workload deployment request received at the target environment 108. At 416, the processing resource 122 can receive a request for a policy from the controller node 128 in response to listening for the workload deployment request at the target environment 108. The request for the policy can include the proof identifier associated with the workload 204. In addition, at 418, the processing resource 122 can compile a policy from the policy database 106 based on the proof identifier 118. In some examples, compiling can include verifying the proof identifier 118 received from the controller node 128 and retrieving the policy associated with the proof identifier from the policy database 106. At 420, the processing resource 122 can provide the compiled policy to the controller node 128 as a response. At 422, the controller node 128 can apply the policy in the target environment 108. In some examples, applying the policy in the target environment 108 can include setting native policies and setting policy network hooks. Native policies can include constructs and definitions built into and provided by the target environment 108. Different environments can provide different types of native policies. For example, in a Kubernetes cluster, examples of native policies can include POD security policies, network policies, extended policies (e.g., horizontal POD autoscalers), etc. The native constructs and definitions can be used to implement the compiled policy in the target environment 108. The controller node 12 can use the policy network hook to accept or reject workload deployments or policy updates. At 424, the workload 204 is deployed at the target environment 108 using the compiled policy.

[0042] Figure 4BDepicts a sequence diagram of policies for managing a workload 204 that has been deployed in a target environment 108. Sequence 400B can include 428, 430, 432, 434, 436, 438, and 440 (collectively hereinafter referred to as 428-440), which can be executed by a processor-based system as described above. At 428, a policy management system 426 can perform one or more policy actions on one or more policies stored in a policy database 106. In various examples, policy actions can include policy creation, policy inheritance, policy extension, policy cloning, policy verification, policy update, or policy revocation (policy actions will be further described below). At 430, a processing resource 122 can receive an event notification indicating one or more policy actions performed at the policy database 106. At 432, the processing resource 122 can provide an updated attestation identifier to a controller node 128 at the target environment 108 where the workload is deployed. At 434, the processing resource 122 can receive a request for an updated policy from the controller node 128 based on the updated attestation identifier. At 436, the processing resource 122 can recompile the updated policy from the policy database 106 based on the updated attestation identifier. At 438, the processing resource 122 can provide the updated policy to the controller node 128 as a response. Additionally, at 440, the controller node 128 can apply the updated policy to the target environment 108.

[0043] Move to Figure 5 , according to an example, presents a block diagram 500 that depicts a policy database 110 and a policy management system 426 for facilitating policy management of a workload. In some examples, the functionality of the policy management system 426 can be implemented in the system 102. Alternatively, the policy management system 426 can be a remote computing system communicatively coupled to the system 102 via a network 110. As described above, the policy database 106 can store policies required for workload deployment and execution. In various examples, the policy database 106 can store different types of policies, such as custom policy templates, environment-specific policies, or global policies that can be applied to any target environment 108. In various examples, policies can be attached with tags that can indicate one or more workload profiles 204. In some examples, each workload profile 204 can be marked with one or more policies 504, 506. Tags can allow for easy lookup, grouping, and collection of policies in the policy database 106.

[0044] In some examples, the functions performed by the policy management system 426 can be automated using various machine learning techniques. Alternatively, the policy management system 426 can be manually operated by a policy administrator. In some examples, the policy management system 426 can include a dashboard interface 502 that is used to display a summary of the status and relationships between policies 504, 506, workload profiles 204, target environments 108, and workloads 112. For example, the summary can include a list of policies 504, 506 applied in the target environment 108, a list of policies 504, 506 labeled with one or more workload profiles 204, and a list of policies 504, 506 not labeled with any workload profiles 204. Additionally, the summary can also include the mapping between policies 504, 506 and workload profiles 204. The dashboard interface 502 can also display the number of target environments 108 in which a particular type of policy 504, 506 (e.g., a network application policy) is applied. The dashboard interface 502 can also schematically show a list of available policies and attestation identifiers created using the total number of running or active instances of the workload 112.

[0045] The policy management system 426 can include a policy management interface 508 for performing one or more policy actions 510 on the policies 504, 506 stored in the policy database 106. The policy management interface 508 can include multiple services for performing policy actions to facilitate creating new policies, modifying existing policies, deleting policies, etc. Through various policy actions 510, the policies 504, 506 can be maintained and updated regularly. In various examples, the summary displayed on the dashboard interface 502 can allow the policy administrator to monitor the status of policies 504, 506, workload profiles 204, workloads 112, and target environments 108 and perform one or more policy actions 510.

[0046] The policy action 510 can include policy creation 512 for an existing workload profile 204 or a new workload profile 204. Policies can be created for existing workload profiles to enhance the security and execution of the associated workload 112. In the case of a new workload profile, existing policies as well as new policies can be used for labeling. Policies can be written using predefined templates or a general-purpose language (e.g., Datalog or Rego). In various examples, custom policies can also be created using templates and then applied to the target environment using the policy runtime. The policy runtime can implement network hooks that the controller nodes can use to accept or reject workload deployments or configuration updates.

[0047] In some examples, the policy action 510 may include policy inheritance 514. For example, one or more policies associated with the first workload profile 204 may be made available to the second workload profile 204. If the workload version has been updated and the updated workload version requires the policies associated with the old version of the workload, one or more policies may also be inherited. In some examples, the policies 504, 506 associated with the workload profile 204 may be active for a predetermined period of time. The associated policies 504, 506 may be deactivated after the predetermined period of time. In some examples, the policy action 510 may include a policy extension 516 for extending the policies 504, 506 associated with the workload profile 204 beyond a predetermined period of time.

[0048] In some examples, the policy action 510 may include policy cloning 518 by creating one or more copies of the policies 504, 506. The cloned policies may be used in association with one or more workload profiles 204.

[0049] The policy action 510 may also include a policy validation 520 for checking whether the policies 504, 506 associated with one or more workload profiles 204 are valid. The policy validation 520 may be used to ensure that the security of the workload is not compromised.

[0050] In some examples, the policy action 510 may include a policy application 522 for applying one or more policies 504, 506 in the target environment 108. The policies 504, 506 may be applied regardless of whether they are associated with the workload profile 204.

[0051] In some examples, the policy action may include a policy update 524 for updating one or more policies 504, 506. The policy update 524 may be executed in response to a malicious attack on the workload, a failure of the workload, a non-execution of the workload, etc. In some examples, one or more policies 504, 506 may be updated in response to a change in the workload version.

[0052] In some examples, the policy action 510 may include a policy revocation 526 for revoking one or more policies 504, 506 associated with the workload profile 204. Additionally, the policy action 510 may also include a policy audit 528 for maintaining a history of the policies 504, 506. For example, the history may include a list of the policies 504, 506 that are currently associated with the workload profile 204 and that have been associated with the workload profile 204 in the past.

[0053] In some examples, the policy notification 530 can be used to provide an alert to the system 102 in response to the execution of any policy action 510. In some examples, the policy action 510 can include a policy record 532 for creating logs of policies 504, 506 associated with each workload profile 204 and applied at the target environment 108. In some examples, the policy action 510 can include one or more policies for managing attached or embedded workloads 112, and a management policy plug-in 534 for executing the policies associated with the workload profile 204. The policies 504, 506 can be attached or embedded during the development of the workload.

[0054] Figure 6 Illustrates the implementation of dynamic policy management in the target environment 108. The policy lifecycle manager 602 can be configured to receive requests for policies from the controller nodes 128-1, 128-2. In some examples, the policy lifecycle manager 602 can be implemented as a Kubernetes Operator. The request can include a proof identifier associated with the workload 204. The request including the proof identifier can be provided to the system 102. The system 102 can compile the policy from the policy database 106 based on the proof identifier and provide the compiled policy to the policy lifecycle manager 602.

[0055] The policy lifecycle manager 602 can provide the policy to the controller nodes 128-1, 128-2. In some examples, the controller nodes 128-1, 128-2 can include schedulers 604, 606 configured to schedule the execution of workloads 608, 610 in the target environments 108-1, 108-2. As shown, the workloads 608, 610 can be containerized applications packaged in application PODs 612, 614. In other examples, the workload can be a POD, a container, a virtual machine, etc. In some examples, the target environments 108-1, 108-2 can be Kubernetes clusters including multiple worker nodes 616, 618. The worker nodes 616, 618 can facilitate resources, such as computing, storage, and / or network capabilities, for the execution of the workloads 608, 610.

[0056] In some examples, the policy lifecycle manager 602 can be configured to inject one or more policy agents 620, 622 into worker nodes 616, 618. The worker nodes 616, 618 can include pods 612, 614 that contain the policy agents 620, 622, and can package one or more containerized applications 608, 610. The controller nodes 128-1, 128-2 can communicate with the policy agents 612, 614 to install the policies 620, 622 to be applied in the worker nodes 616, 618. In some examples, the policy agents 612, 614 can be implemented in a side car mode. In some examples, the schedulers 604, 606 can be configured to select one or more worker nodes 616, 618 in each target environment 108-1, 108-2 to deploy and execute the workloads 608, 610. In some examples, the target environment 108 can include a policy runtime engine (not shown in the figure) for applying custom policies.

[0057] Move to Figure 7 , block diagram 700 depicts a processing resource 702 and a machine-readable medium 704 encoded with example instructions for facilitating dynamic policy management of a workload according to an example. The machine-readable medium 704 can be non-transitory and is alternatively referred to as a non-transitory machine-readable medium 704. In some examples, the machine-readable medium 704 can be accessed by the processing resource 702. In some examples, the processing resource 702 can represent an example of the processing resource 122 of the system 102. Additionally, the machine-readable medium 704 can represent an example of the machine-readable medium 124 of the system 102.

[0058] The machine-readable medium 704 can be any electronic, magnetic, optical, or other physical storage device that can store data and / or executable instructions. Thus, the machine-readable medium 704 can be, for example, RAM, EEPROM, a storage drive, flash memory, a CD-ROM, etc. As described in detail herein, the machine-readable medium 704 can be encoded with executable instructions 706, 708, 710, 712, 714, 716, and 718 (collectively referred to hereinafter as instructions 706-718) for performing the method 300 described in Figure 3 . Although not shown, in some examples, the machine-readable medium 704 can be encoded with certain additional executable instructions for performing Figure 3 the method 300 and / or any other operations performed by the system 102, without limiting the scope of the present disclosure.

[0059] The processing resource 702 can be a physical device, such as one or more CPUs, one or more semiconductor-based microprocessors, one or more GPUs, ASICs, FPGAs, other hardware devices capable of retrieving and executing instructions 706 - 718 stored in a machine-readable medium 704, or a combination thereof. In some examples, the processing resource 702 can obtain, decode, and execute the instructions 706 - 718 stored in the machine-readable medium 704 to deploy a workload on one or more target environments 108. In certain examples, as an alternative or supplement to retrieving and executing the instructions 706 - 718, the processing resource 702 can include at least one IC, other control logic, other electronic circuits, or a combination thereof, and the at least one IC, other control logic, other electronic circuits, or a combination thereof includes multiple electronic components for performing functions intended to be performed by Figure 1 the system 102.

[0060] When executed by the processing resource 702, the instruction 706 can cause the processing resource 702 to receive a workload attestation request including a workload specification from a workload creation node. Additionally, when executed by the processing resource 702, the instruction 708 can cause the processing resource 702 to determine a workload profile based on the workload specification. Additionally, when executed by the processing resource 702, the instruction 710 can cause the processing resource 702 to identify a policy stored in the policy database 106 based on the workload profile. Additionally, when executed by the processing resource 702, the instruction 712 can cause the processing resource 702 to provide an attestation identifier indicating the workload profile in response to the workload attestation request. Additionally, when executed by the processing resource 702, the instruction 714 can cause the processing resource 702 to receive a request for the policy from a controller node at the target environment. The request includes the attestation identifier. When executed by the processing resource 702, the instruction 716 can cause the processing resource 702 to compile the policy from the policy database using the attestation identifier. When executed by the processing resource 702, the instruction 712 can cause the processing resource 702 to provide the policy to the controller node, and the controller node applies the policy at the target environment.

[0061] Although certain implementations have been shown and described above, various changes can be made in form and detail. For example, some features and / or functions described with respect to one implementation and / or process can be relevant to other implementations. In other words, a process, feature, component, and / or property described with respect to one implementation may be useful in other implementations. Additionally, it should be understood that the systems and methods described herein can include various combinations and / or sub-combinations of components and / or features of the different implementations described.

[0062] In the foregoing description, numerous specific details are set forth to provide a thorough understanding of the subject matter disclosed herein. It is, however, possible to practice the implementations without some or all of these specific details. Other implementations may include modifications, combinations, and variations of the above details. The following claims are intended to cover such modifications and variations.

Claims

1. A method, comprising: Receiving, by a processor - based system, a workload proof request from a workload creation node, wherein the workload proof request includes a workload specification of the workload; Determining, by the processor - based system, a workload profile based on the workload specification; Identifying, by the processor - based system, a policy based on the workload profile, the policy being stored in a policy database; Providing, by the processor - based system, a proof identifier to the workload creation node in response to the workload proof request, wherein the proof identifier indicates the workload profile; Receiving, by the processor - based system, a request for the policy from a controller node at a target environment, wherein the request includes the proof identifier; Compiling, by the processor - based system, the policy from the policy database using the proof identifier; And Providing, by the processor - based system, the policy to the controller node, wherein the controller node applies the policy in the target environment.

2. The method according to claim 1, wherein compiling the policy comprises: Verifying the proof identifier received from the controller node at the target environment; And Retrieving the policy associated with the proof identifier from the policy database.

3. The method according to claim 1 further comprises: Performing a policy action at the policy database, wherein the policy action includes policy creation, policy inheritance, policy extension, policy cloning, policy verification, policy update, or policy revocation.

4. The method according to claim 1, further comprising: Receiving a notification indicating a policy action performed at the policy database, wherein the policy action includes policy creation, policy inheritance, policy extension, policy cloning, policy verification, policy update, or policy revocation; Providing an updated proof identifier to the controller node at the target environment; Receiving a request for an updated policy for the workload, wherein the request includes the updated proof identifier; Re - compiling the updated policy based on the policy action using the updated proof identifier; Providing the updated policy to the controller node, wherein the controller node applies the policy in the target environment.

5. The method according to claim 1, wherein the policy includes a custom policy, an environment - specific policy, or a global policy applicable at any target environment.

6. The method according to claim 1, wherein the workload includes a container, a POD, a virtual machine, or a containerized application.

7. The method according to claim 1, wherein the workload specification includes application ports, requested privileges, ingress whitelists, authentication modes, and exposure modes.

8. A policy management system, comprising: Processing resources; A machine - readable medium storing one or more instructions that, when executed by the processing resources, cause the processing resources to: Receive a workload proof request from a workload creation node, wherein the workload proof request includes a workload specification of the workload; Determine a workload profile based on the workload specification; Identify a policy based on the workload profile, the policy being stored in a policy database; Provide a proof identifier in response to the workload proof request, wherein the proof identifier indicates the workload profile; Receive a request for the policy from a controller node at the target environment, wherein the request includes the proof identifier; Compile the policy from the policy database using the proof identifier; And Provide the policy to the controller node, wherein the controller node applies the policy in the target environment.

9. The system of claim 8, wherein the instructions, when executed, cause the processing resource to perform a policy action at the policy database, wherein the policy action includes policy creation, policy inheritance, policy extension, policy cloning, policy verification, policy update, or policy revocation.

10. The system of claim 8, wherein the instructions, when executed, cause the processing resource to: Receive a notification indicating a policy action to be performed at the policy database, wherein the policy action includes policy creation, policy inheritance, policy extension, policy cloning, policy verification, policy update, or policy revocation; In response to receiving the notification, provide an updated proof identifier to the controller node at the target environment; Receive a request for an updated policy for the workload, wherein the request includes the updated proof identifier; Recompile the policy based on the policy action using the updated proof identifier; And Provide the updated policy to the controller node, wherein the controller node applies the policy in the target environment.

11. The system of claim 8, wherein the instructions, when executed, cause the processing resource to create a dashboard interface for displaying a summary of the status and relationships between the policy, the workload profile, the target environment, and the workload.

12. The system of claim 8, wherein the workload includes a container, a POD, a virtual machine, or a containerized application.

13. The system of claim 8, wherein the workload specification includes one or more of application ports, requested privileges, ingress whitelists, authentication modes, and exposure modes.

14. A non-transitory machine-readable medium storing instructions executable by a processing resource, the instructions including: Instructions for receiving a workload proof request from a workload creation node, wherein the workload proof request includes a workload specification of the workload; Instructions for determining a workload profile based on the workload specification; Instructions for identifying a policy based on the workload profile, the policy being stored in a policy database; Instructions for providing a proof identifier in response to the workload proof request, wherein the proof identifier indicates the workload profile; Instructions for receiving a request for the policy from a controller node at the target environment, wherein the request includes the proof identifier; Instructions for compiling the policy from the policy database using the proof identifier; And Instructions for providing the policy to the controller node, where the controller node applies the policy in the target environment.

15. The non-transitory machine-readable medium according to claim 14, further comprising instructions for performing policy actions at the policy database, where the policy actions include policy creation, policy inheritance, policy extension, policy cloning, policy verification, policy update, or policy revocation.

16. The non-transitory machine-readable medium according to claim 14, further comprising: Instructions for receiving a notification indicating a policy action performed at the policy database, where the policy actions include policy creation, policy inheritance, policy extension, policy cloning, policy verification, policy update, or policy revocation; Instructions for providing an updated proof identifier to the controller node at the target environment; Instructions for receiving a request for an updated policy for the workload, where the request includes the updated proof identifier; Instructions for recompiling the policy based on the policy action using the updated proof identifier; And Instructions for providing the updated policy to the controller node, where the controller node applies the policy in the target environment.

17. The non-transitory machine-readable medium according to claim 14, where the instructions for compiling the policy from the policy database using the proof identifier include: Instructions for verifying the proof identifier received from the controller node at the target environment; And Instructions for retrieving the policy associated with the proof identifier from the policy database.

18. The non-transitory machine-readable medium according to claim 14, further comprising instructions for creating a dashboard interface for displaying a summary of the status and relationships between the policy, the workload profile, the target environment, and the workload.

19. The non-transitory machine-readable medium according to claim 14, where the workload specification includes application ports, requested privileges, ingress whitelists, authentication modes, and exposure modes.

20. The non-transitory machine-readable medium according to claim 14, where the policy includes a custom policy, an environment-specific policy, or a global policy applicable at any target environment.

Images