Managing policies in target environments

Abstract

A procedure that includes: Receiving, by a processor-based system, a workload certification request (116) from a workload generation node (104), wherein the workload certification request (116) includes a workload specification (114) of a workload (112); Determining a workload profile (204) by the processor-based system based on the workload specification (114); identifying, by the processor-based system, a policy (504) stored in a policy database (106) based on the workload profile (204); providing a certificate identifier (118) by the processor-based system to the workload generation node (104) in response to the workload certificate request (116), the certificate identifier (118) indicating the workload profile (204); receiving, by the processor-based system, a request for the policy (504) from a controller node (128) in a target environment (108), the request including the certificate identifier (118); Compiling the policy (504) from the policy database (106) by the processor-based system using the certificate identifier (118); and Providing the policy (504) by the processor-based system to the controller node (128), wherein the controller node (128) applies the policy (504) in the target environment (108).

Description

BACKGROUND

[0001] Cloud-native computing is an approach to building applications or workloads as a set of microservices running in containers. A container contains workloads and necessary dependencies in a single package, making the workload executable in different cloud environments. The deployment, management, and execution of containerized workloads in different cloud environments is performed using a workload orchestration platform. Such deployment and execution of the workloads depends on the security of the cloud environments. US 2009 / 0 132 647 A1 describes a method, a system, and a storage medium for providing context-based dynamic policy assignment in a distributed processing environment. US 2013 / 0 263 206 A1 describes a method for policy adaptation based on application policy conformance analysis.US 2016 / 0 359 920 A1 describes various methods for enforcing runtime policies in a networked computing environment, e.g., a cloud computing environment.

[0002] It is an object of the invention to propose a method, a system, and a non-transitory, machine-readable storage medium for managing policies in target environments. This object is achieved by a method according to claim 1, a system according to claim 8, and a non-transitory, machine-readable storage medium according to claim 14. BRIEF DESCRIPTION OF THE DRAWINGS

[0003] 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 throughout the drawings, wherein: Fig. 1 shows a networked system having a policy management system in a target environment according to an example; Fig. 2 shows a workload specification and associated workload profiles according to an example; Fig. 3 is a flowchart illustrating a method for policy management in the target environments according to an example; Fig. 4A and Fig. 4B are signal diagrams illustrating a method for policy management in the target environments according to another example; and Fig. Figure 5 is a block diagram illustrating policy management in the target environment according to an example. Fig. 6 is a block diagram illustrating a policy lifecycle manager for dynamically applying policies in the target environment according to an example. Fig. 7 is a block diagram showing a processing resource and a machine-readable medium encoded with example instructions for managing policies in the target environment according to an example.

[0004] It should be emphasized that the various features in the drawings are not drawn to scale. Rather, the dimensions of the various features in the drawings may have been enlarged or reduced for clarity. DETAILED DESCRIPTION

[0005] The following detailed description refers to the accompanying drawings. Wherever possible, like reference numerals are used in the drawings and the following description to refer to the same or similar parts. It is expressly understood that the drawings are for the purpose of illustration and description only. Although several examples are described in this document, modifications, adaptations, and other embodiments are possible. Accordingly, the following detailed description does not limit the disclosed examples. Instead, the proper scope of the disclosed examples may be defined by the appended claims.

[0006] The terminology used herein is for the purpose of describing specific examples and is not intended to be limiting. The singular forms “a,” “an,” and “the” include the plural forms unless the context clearly indicates otherwise. As used herein, “another” is defined as at least a second or more. As used herein, “coupled” is defined as connected, either directly without any intervening elements or indirectly with at least one intervening element, unless otherwise noted. For example, two elements may be mechanically, electrically, or communicatively connected via a communications channel, path, network, or system. Furthermore, as used herein, the term “and / or” refers to and includes all possible combinations of the listed elements. It is also understood that although the terms first, second, third, fourth, etc.used to describe various elements, those elements should not be limited by these terms, as these terms are used only to distinguish one element from another unless otherwise stated or clear from the context. As used herein, the term "includes" means includes, but is not limited to; the term "including" means includes, but is not limited to; and the term "based on" means based at least in part on.

[0007] Cloud-native computing is an approach to building applications or workloads as a set of microservices running in containers. A container contains workloads and their required dependencies in a single package, allowing the workload to run across different cloud environments. Examples of such workloads include a virtual machine, a container, a pod, a containerized application, or any piece of code that can be implemented as a microservice.

[0008] Workloads can be managed through a workload orchestration system such as Kubernetes. The workload orchestration system can run on a compute node, referred to as a controller node. The controller node can receive a request to deploy a workload and schedule the deployment of the workload to one or more target cloud environments. Various features of cloud-native computing, such as microservice architecture, modern design, containerization, automation, and more, enable faster development and deployment of new workloads and faster resolution of issues.

[0009] However, the deployment, management, and execution of workloads depend on the security of the target environments and the workloads themselves. For example, the workloads and target environments may have specific control and access rights to ensure that the security of the underlying target environment is not compromised and to reduce the risk of workload data disclosure. Control and access rights can be implemented based on a set of governance rules, referred to as policies. In some approaches, policies can be defined or created during workload development to govern control and access rights for the workload. Policies, such as native policies, can also be implemented by a cloud provider to ensure the security and execution of workloads.

[0010] With advances in cloud-native technologies, the number of target environments is constantly increasing, making policy management for each target environment and workload challenging. For example, each cloud environment may support several thousand workloads developed by different teams and organizations in different geographic locations. Furthermore, each workload may require different policies to enforce a specific set of controls and access rights. Therefore, managing policies for each workload based on the workload characteristics and underlying constructs of each target environment is tedious and labor-intensive.

[0011] Additionally, some target environments may only provide native policies to control the infrastructure, but not the required policies when a workload is deployed. Furthermore, applying the correct policies in the target environment may require constant monitoring. For example, a new update to an existing policy or a workload version update may require re-enforcing or revoking certain policies. Some existing solutions do not dynamically collect the latest policies required by workload versions. Therefore, applying policies in a target environment based on a workload's behavior is a challenging task.

[0012] To this end, in accordance with aspects of the present disclosure, dynamic policy management based on the workload profile is presented. In some examples, a workload attestation request may be received from a workload generation node. The workload attestation request may include a workload specification of a workload. Based on the workload specification, a workload profile may be determined. Based on the workload profile, a policy stored in a policy database may be identified. In response to the workload attestation request, an attestation identifier indicating the workload profile may be provided to the workload generation node. Further, a request for the policy may be received from a control node in a target environment. The request may include the attestation identifier.Using the attestation identifier, the policy can be compiled from the policy database. The policy can also be made available to the control node, which can then apply the policy in the target environment.

[0013] The examples presented here facilitate improved dynamic policy management in cloud-native environments based on workload profiles. The examples presented here reduce or eliminate the need for workload developers to define policies for the workload. Developers can simply provide a workload specification that can be used to attest the workload using an attestation identifier. The attestation identifier can be used to dynamically compose relevant policies, regardless of the number and type of target environments for workload deployment. Dynamically compose policies based on the attestation identifier can provide improved performance and security for the workloads in the target environments (e.g.,Kubernetes clusters) that are either located on-premises in a private cloud data center owned or leased by the customer, or consumed as an as-a-service offering from a public cloud provider (e.g., via a pay-as-you-go or consumption-based financing model). Furthermore, improved dynamic policy composition, as brought about by various example aspects presented here, ensures that the latest policies required by the workloads are applied in the target environment. For example, any updates to the policies in the policy database or the workload can be considered before policies are retrieved from the policy database. Furthermore, custom policies that are not available in the target environment can also be compiled and applied based on the workload profile.

[0014] In Fig. 1 shows a networked system 100 according to one example. The networked system 100 may 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) connected via a network (110). In some examples, the networked system 100 may be a distributed system in which the policy management system 102, the workload creation node 104, the policy database 106, and the target environment 108 may be physically located (e.g., on different racks, in different chassis, in different buildings, in different cities, in different countries, etc.) while connected via the network 110.

[0015] Examples of network 110 may 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 communications network, a public switched telephone network (PSTN), and the Internet. Communication over network 110 may be in accordance with various communications 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 communications protocols. Communication over network 110 may be via wired (e.g., copper cable, optical communications, etc.) or wireless (e.g., Wi-Fi ®, cellular communication, satellite communication, Bluetooth, etc.) communication technologies. In some examples, network 110 may be enabled over private communication links, including, but not limited to, communication links established via Bluetooth, cellular communication, optical communication, radio frequency communication, wired (e.g., copper), and the like. In some examples, the private communication links may be direct communication links between system 102, workload generation node 104, policy database 106, and target environment 108.

[0016] The workload creation node 104 may be a device that includes a processor or microcontroller and / or other electronic component, or a device or system that enables various workload development, computing, and / or data storage services. Examples of the workload creation node 104 may include, but are not limited to, a desktop computer, a laptop, a smartphone, a server, a computing device, a workstation, a storage system, a converged or hyperconverged system, and the like. Although Fig. 1 shows that the networked system 100 includes a workload creation node 104, the networked system 100 may include any number of workload creation nodes without limiting the scope of the present disclosure. The workload creation node 104 may have similar or different hardware and / or software configurations in a particular implementation of the networked system 100.

[0017] The term workload can refer to a computing resource, including but not limited to an application (e.g., a software program), a virtual machine (VM), a container, a pod, or a containerized application. In some examples, the workload can include any piece of code that can be developed as a microservice. A workload, such as a VM, can be an instance of an operating system hosted on a specific worker node via a VM host program, such as a hypervisor. Additionally, a workload, such as a container, can be a packaged application with its dependencies (e.g., operating system resources, processing allocations, memory allocations, etc.) hosted on a specific worker node via a container host program, such as a container runtime environment (e.g., Docker Engine).Additionally, in some examples, workloads may contain pods formed by grouping one or more containers. For example, a group of containers associated with a common application may be grouped into a pod.

[0018] The target environment 108 may provide resources, e.g., compute, storage, and / or networking capabilities, for one or more workloads that may run thereon. Examples of the target environment 108 may include, but are not limited to, a server, server cluster, container orchestration systems such as Kubernetes, clusters of container orchestration systems, a computer appliance, a workstation, a desktop computer, a laptop, a smartphone, a storage system, or a converged or hyperconverged system, and the like. For example, some target environments may have high-end compute capabilities, some target environments may enable high data security, and certain target environments may have enhanced thermal capabilities. Although in Fig. 1 that the networked system 100 includes a target environment 108, the networked system 100 may include any number of target environments without limiting the scope of the present disclosure.

[0019] In the description, the workload 112 is described as an application and the target environment 108 as one or more Kubernetes clusters to illustrate this. Applications in containers can be managed via a container orchestration system such as Kubernetes. In the example of Fig. 1, the workload creation node 104 is shown to facilitate the creation or development of workloads. For example, developers can work on the workload creation node 104 to write and develop workloads. Although a single workload can be created on the workload creation node 104, as shown in Fig. 1, the workload creation node 104 may facilitate the development of any number of workloads 112 depending on the particular hardware and / or software configurations. In some examples, the target environment 108 may also serve as the workload creation node 104, or vice versa.

[0020] During or after the development of the workload 112 at the workload creation node 104, a workload specification 114 may also be developed, which contains information about the characteristics of the workload 112. The characteristics of the workload may specify various access and control rights. For example, the access rights may include access to communication endpoints such as port 80, port 443, or port TCP / 5607. The control rights may include measures to control the behavior of the workload. For example, the control rights may 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 may issue a workload attestation request 116 (in Fig. 1 marked as WAR) with the workload specification 114 corresponding to the workload 112 from the workload creation node 104. The system 102 may attest the workload 112 based on the workload specification 114 and manage the policies required in the target environment 108 based on the attestation. For example, the system 102 may provide the workload creation node 104 with a workload attestation identifier 118 (in Fig. 1 as ATT_ID) that can send a workload deployment request to the target environment 108. In addition, the system 102 can also receive a policy request 120 from the target environment 108 for deploying the workloads 112 to the target environment 108 (described later).

[0021] As in Fig. 1, in some examples, system 102 may be a device including a processor or microcontroller and / or other electronic component, or a device or system that may enable various computing and / or data storage services, for example. Examples of system 102 may include, but are not limited to, a desktop computer, a laptop, a smartphone, a server, a computing device, a workstation, a storage system, or a converged or hyperconverged system, and the like, configured to manage policies for workload 112 in target environment 108. Furthermore, in certain examples, system 102 may be or include a virtual machine or a containerized application executing on hardware in networked system 100.

[0022] In some examples, system 102 may include a processing resource 122 and a machine-readable medium 124. Machine-readable medium 124 may be any electronic, magnetic, optical, or other physical storage device capable of storing data and / or executable instructions 126. For example, machine-readable medium 124 may include one or more of the following: random access memory (RAM), electrically erasable programmable read-only memory (EEPROM), a storage drive, flash memory, compact disc read-only memory (CD-ROM), and the like. Machine-readable medium 124 may be non-transferable. As described in detail herein, machine-readable medium 124 may be encoded with executable instructions 126 to perform one or more methods, such as those described in Fig. 3, Fig. 4A and Fig. 4B described methods.

[0023] Additionally, processing resource 122 may be a physical device, such as one or more central processing units (CPUs), one or more semiconductor-based microprocessors, one or more graphics processing units (GPUs), application-specific integrated circuits (ASICs), a field-programmable gate array (FPGA), other hardware devices capable of retrieving and executing instructions 126 stored in machine-readable medium 124, or combinations thereof. Processing resource 122 may retrieve, decode, and execute the instructions 126 stored in machine-readable medium 124 to manage policies for a workload (described further below).Alternatively, or in addition to executing instructions 126, processing resource 122 may include at least one integrated circuit (IC), control logic, electronic circuitry, or combinations thereof, including a series of electronic components for performing the functions to be performed by system 102 (as described further below). Moreover, in certain examples where system 102 may be a virtual machine or a containerized application, processing resource 122 and machine-readable medium 124 may represent a processing resource and a machine-readable medium of the hardware or computer system hosting system 102 as a virtual machine or containerized application.

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

[0025] The workload specification file 202 may include the workload specification 114, which describes the static and runtime behavior of an associated workload. In particular, the workload specification 114 may specify 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, and the like. For each configuration, a list of subconfigurations and associated values may be included in the workload specification. For example, the application ports may include the list of subconfigurations, such as port 80, port 8080, port 443, port 22, port 20, and the like. The authentication modes may include certificate-based authentication. The ingress list can contain a list of allowed sources (e.g.: IP addresses 35.16.78.100, 35.16.78.101) and domains (e.g.: hpe.com). For request rights, the subconfigurations may include Roots Required (True / False) and / or Allow Host Network (Yes / No). Each of the workload profiles 204 contains some or all of the possible configurations and / or subconfigurations contained in the workload specifications. The workload profiles 204 may have predefined values for configurations and / or subconfigurations selected as archetypal for a workload represented by that workload profile. The predefined values of the workload profiles 204 may also be changed periodically to avoid state-of-the-art security vulnerabilities.

[0026] Returning to Fig. 1, the system 102 may determine one or more workload profiles 204 based on the workload specification file 202. For example, the values for each subconfiguration in the workload specification file 202 may be used to identify the one or more workload profiles 204. In some examples, the determination of the one or more workload profiles 204 may be based on the best match between the configurations and subconfigurations of the workload specification file 202 and the corresponding predefined values of the workload profiles 204.

[0027] The system 102 may identify one or more policies stored in a policy database 106 based on the determined workload profiles 204. In some examples, the policy database 106 may store a plurality of policies that may be applicable to the target environment 108. In some examples, the plurality of policies may include custom policies, global policies, or environment-specific policies. The global policies may be applicable in any environment, such as development, integration, or production environments. For example, a global policy for a web application profile may include global access and control rights, such as allowing only HTTPS or performing certificate authority verification. On the other hand, the environment-specific policies may be applicable to specific environments.For example, environment-specific policies for a web application profile in a development environment may include accepting a maximum of 100 requests per minute or allowing the resource to be shut down during an update. Similarly, environment-specific policies for a web application profile in a production environment may allow a maximum of 1,000 requests per minute or not allow any resource downtime during an update. In various examples, policy database 106 may be a remote database implemented on a server or other computing device previously mentioned. Alternatively, policy database 106 may be a local database within system 102. Policy database 106 may use tags to link policies and workload profiles 204.In some examples, changing the association between the policies and the one or more workload profiles 204 may occur in response to a malicious attack on the workload, a malfunction of the workload, a failure of the workload, and the like. In some examples, the association between the policies and the workload profiles may also be changed via a user interface.

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

[0029] In some examples, the workload creation node 104 may send a workload deployment request to the controller node 128 to deploy the workload in the target environment 108. The request to deploy the workload may include the attestation identifier 118. In response to the request to deploy the workload, the system 102 may receive a request for one or more policies from the controller node 128 to deploy the workload 112. The request 120 may include the identifier of the attestation. The system 102 may compile the 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 based on the workload profiles 204 from the policy database 106 to create custom policies. In some examples, the system may also check whether the attestation identifier is valid before compiling. For example, some attestation identifiers may be inactive after a certain period of time or may not indicate updated workload profiles 204 associated with the workload 112.

[0030] The system 102 can then forward the policies to the control node 128 so that the policies are applied in the target environment 108. As can be seen, the target environment 108 presented here facilitates the scheduling and deployment of the workload 112. In particular, due to the improved policy composition brought about by various example aspects presented here, the workload 112 can be executed on a well-equipped worker node that has sufficient resources to meet the workload requirements. Applying the policies based on the workload profile can enable improved performance and security for workloads on networked systems (e.g., Kubernetes clusters) on the customer's premises or in an as-a-service offering.Furthermore, when policies or workload versions are updated, the updated policies are compiled automatically and dynamically during operation, and manual intervention can be reduced or eliminated. An example of a policy update is described below with reference to . Fig. 4B.

[0031] Fig. 3 shows a flowchart illustrating a method 300 for managing policies in the target environment 108 according to an example. For illustration, the method 300 is used in connection with the networked system 100 of Fig. 1 and the elements of Fig. 2. The method 300 may include method blocks 302, 304, 306, 308, 310, 312, and 314 (hereinafter collectively referred to as blocks 302-314) that may be executed by a processor-based system, such as the system 102. In particular, operations in each of the method blocks 302-314 may be performed by the processing resource 122 by executing the instructions 126 stored on the machine-readable medium 124 (see Fig. 1). Furthermore, it should be noted that in some examples, the order of execution of blocks 302-314 may be different than in Fig. 3. For example, blocks 302-314 can be implemented in series, parallel, or in a series-parallel combination.

[0032] In block 302, the processing resource 122 may receive a workload certification request 116 for the workload 112, for example, from the workload generation node 104. The workload certification request 116 may include the workload specification 114 that specifies the characteristics of the workload 112, as shown in Fig. 2. In block 304, the processing resource 122 may determine one or more workload profiles 204 for the workload 112 based on the received workload attestation requests. Further, in block 306, the processing resource 122 may identify one or more policies stored in the policy database 106 based on the one or more workload profiles 204 determined in block 304. In block 308, the processing resource 122 may transmit the attestation identifier 118 to the workload creation node 104. The attestation identifier 118 may indicate the one or more workload profiles 204 determined in block 304. The workload creation node 104 may send a workload deployment request to the control node 128 to deploy the workload 112 to the target environment 108. The request to provide the workload may contain the certificate identifier 118.Further, in block 310, the processing resource 122 may receive a policy request 120 from the controller node 128 in the target environment 108. The policy request may include the attestation identifier 118. In block 312, the processing resource 122 may compile the policy from the policy database 106 using the attestation identifier. Further, in block 314, the processing resource 122 may forward the policy to the controller node 128 to apply the policy in the target environment 108.

[0033] In the Fig. 4A and Fig. 4B, sequence diagrams are shown showing methods for policy management according to another example. For illustration, sequences 400A and 400B are shown in connection with the networked system 100 of Fig. 1 described. Fig. 4A shows a sequence diagram for managing policies for the workload 112 during or before deployment of the workload to the target environment 108. The sequence 400A may include 402, 404, 406, 408, 410, 412, 414, 416, 418, 420, 422, and 424 (hereinafter collectively referred to as 402-424), which may be executed by processor-based systems as previously described. In particular, the operations of the sequence 402-424 may be performed by the processing resource 122 by executing the instructions 126 stored on the machine-readable medium 124. Furthermore, it should be noted that in some examples, the order of execution of 402-424 may differ from that in Fig. 4A may vary. For example, operations 402-424 may be performed in series, parallel, or in a series-parallel combination.

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

[0035] Further, at 412, the target environment 108 may receive a workload deployment request with the attestation identifier 118 of the workload 204 from the workload creation node 104. In some examples, the attestation identifier may expire after a certain period of time. At 414, an admission webhook may listen for workload deployment requests received in the target environment 108. At 416, in response to listening to the workload deployment request in the target environment 108, the processing resource 122 may receive a request for policies from the controller node 128. The policy request may include the attestation identifier associated with the workload 204. Further, at 418, the processing resource 122 may compile the policies from the policy database 106 based on the attestation identifier 118.In some examples, compiling may include validating the attestation identifier 118 received from the controller node 128 and retrieving the policy associated with the attestation identifier from the policy database 106. At 420, the processing resource 122 may provide the compiled policies in response to the controller node 128. At 422, the controller node 128 may apply the policies in the target environment 108. In some examples, applying the policies in the target environment 108 may include setting up native policies and setting up policy webhooks. The native policy may include constructs and definitions built into and provided by the target environment 108. Different environments may provide different types of native policies.In a Kubernetes cluster, examples of native policies may include pod security policies, network policies, scaling policies (e.g., horizontal pod autoscaler), and the like. The native constructs and definitions may be used to implement the compiled policies in the target environment 108. The policy webhooks may be used by the controller node 12 to accept or reject workload deployments or policy updates. At 424, the workload 204 is deployed to the target environment 108 using the compiled policies.

[0036] Fig. 4B shows a sequence diagram for managing policies for workloads 204 that have already been deployed to the target environment 108. The sequence 400B may include steps 428, 430, 432, 434, 436, 438, and 440 (collectively referred to as 428-440 hereinafter), which may be performed by processor-based systems as previously described. At 428, the policy management system 426 may perform one or more policy actions on the one or more policies stored in the policy database 106. In various examples, the policy actions may include creating, inheriting, extending, cloning, validating, updating, or revoking policies (the policy actions are described further below). At 430, the processing resource 122 may receive an event notification indicative of the one or more policy actions performed on the policy database 106.At 432, the processing resource 122 may transmit an updated attestation identifier to the controller node 128 in the target environment 108 where the workload is deployed. At 434, the processing resource 122 may receive a request for updated policies from the controller node 128 based on the updated attestation identifier. At 436, the processing resource 122 may recompile the updated policies from the policy database 106 based on the updated attestation identifier. At 438, the processing resource 122 may provide the updated policies in response to the controller node 128. Further, at 440, the control node 128 may apply the updated policies to the target environment 108.

[0037] In Fig. 5 illustrates a block diagram 500 illustrating a policy database 110 and a policy management system 426 for facilitating policy management for workloads, according to one example. In some examples, the functions of the policy management system 426 may be implemented in the system 102. Alternatively, the policy management system 426 may be a remote computer system connected to the system 102 via the network 110. The policy database 106 may store policies required for deploying and executing workloads, as previously described. In various examples, the policy database 106 may store different types of policies, such as custom policy templates, environment-specific policies, or global policies that may be applied in each target environment 108.In various examples, the policies may be tagged with tags that may indicate one or more workload profiles 204. In some examples, each workload profile 204 may be tagged with one or more policies 504, 506. The tags may enable easy lookup, grouping, and collection of the policies in the policy database 106.

[0038] In some examples, the functions performed by policy management system 426 may be automated using various machine learning techniques. Alternatively, policy management system 426 may be manually operated by a policy administrator. In some examples, policy management system 426 may include a dashboard interface 502 to display a summary of the status and relationships between policies 504, 506, workload profiles 204, target environment 108, and workload 112. The summary may include, for example, a list of policies 504, 506 applied in target environment 108, a list of policies 504, 506 tagged with one or more workload profiles 204, and a list of policies 504, 506 not tagged with any workload profile 204.Additionally, the summary may also include a mapping between the policies 504, 506 and the workload profiles 204. The dashboard interface 502 may also display the number of target environments 108 in which the policies 504, 506 of a particular type, such as a web application policy, are applied. The dashboard interface 502 may also summarize a list of available policies and attestation identifiers created with the total number of running or active instances of the workloads 112.

[0039] The policy management system 426 may 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 may include a variety of services for performing the policy actions to facilitate creating new policies, making changes to existing policies, removing policies, and the like. Through the various policy actions 510, the policies 504, 506 may be maintained and regularly updated. In various examples, the summary displayed on the dashboard interface 502 may enable a policy administrator to monitor the status of the policies 504, 506, the workload profiles 204, the workloads 112, and the target environment 108 and to perform one or more policy actions 510.

[0040] The policy actions 510 may include the creation of policies 512 for an existing workload profile 204 or a new workload profile 204. Policies for an existing workload profile may be created to improve the security and execution of the associated workloads 112. For new workload profiles, both existing and new policies can be used for tagging. The policy can be created using predefined templates or general-purpose languages such as Datalog or Rego. In various examples, custom policies can also be created using the templates and then applied in the target environment using a policy runtime. The policy runtime can implement a webhook that can be used by the control node to accept or reject workload deployments or configuration updates.

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

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

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

[0044] In some examples, policy action 510 may include policy application 522 for applying one or more policies 504, 506 to the target environment 108. Policies 504, 506 may be applied regardless of whether they are associated with workload profiles 204 or not.

[0045] In some examples, the policy action may include policy update 524 for updating one or more policies 504, 506. Policy update 524 may be performed in response to a malicious attack on the workload, a malfunction of the workload, a failure of the workload to run, and the like. In some examples, the one or more policies 504, 506 may be updated in response to a change in workload versions.

[0046] In some examples, policy action 510 may include policy revocation 526 to revoke one or more policies 504, 506 associated with workload profiles 204. Furthermore, policy action 510 may also include policy review 528 to maintain a historical record of policies 504, 506. For example, the historical record may include the list of policies 504, 506 that are currently and previously associated with a workload profile 204.

[0047] In some examples, a policy notification 530 may be used to communicate an alert to the system 102 in response to the performance of one of the policy actions 510. In some examples, the policy action 510 may include policy logging 532 to create a log of the policies 504, 506 associated with each workload profile 204 and applied in the target environment 108. In some examples, the policy action 510 may include managing policy plugins 534 to manage one or more policies associated or embedded with the workload 112 to enforce the policy associated with the workload profile 204. The policies 504, 506 may be added or embedded during the development of the workload.

[0048] Fig. 6 shows the implementation of dynamic policy management in the target environment 108. A policy lifecycle manager 602 may be configured to receive a request for policies from the controller node 128-1, 128-2. In some examples, the policy lifecycle manager 602 may be implemented as a Kubernetes operator. The request may include the attestation identifier associated with a workload 204. The request, including the attestation identifier, may be provided to the system 102. The system 102 may compile the policies from the policy database 106 based on the attestation identifier and provide the compiled policies to the policy lifecycle manager 602.

[0049] The policy lifecycle manager 602 may propagate the policies to the controller node 128-1, 128-2. In some examples, the controller node 128-1, 128-2 may include a scheduler 604, 606 configured to schedule the execution of workloads 608, 610 in the target environment 108-1, 108-2. As shown, the workloads 608, 610 may be containerized applications packaged in an application pod 612, 614. In other examples, the workloads may be pods, containers, virtual machines, and the like. In some examples, the target environment 108-1, 108-2 may be a Kubernetes cluster with multiple worker nodes 616, 618. The worker nodes 616, 618 may provide resources, such as storage, to the target environment 108-1, 108-2. B. provide computing, storage and / or network capacity for the execution of the workloads 608, 610.

[0050] In some examples, the policy lifecycle manager 602 may be configured to inject one or more policy proxies 620, 622 into the worker nodes 616, 618. The worker nodes 616, 618 may include pods 612, 614, which may contain the policy proxy 620, 622 and package one or more containerized applications 608, 610. The controller node 128-1, 128-2 may communicate with the policy proxy 612, 614 to assemble policies 620, 622 to be applied in the worker node 616, 618. In some examples, the policy proxy 612, 614 may be implemented as a page auto pattern. In some examples, the scheduler 604, 606 may be configured to select the one or more worker nodes 616, 618 in each target environment 108-1, 108-2 for deploying and executing the workloads 608, 610.In some examples, the target environment 108 may include a policy runtime engine (not shown in the figure) for applying user-defined policies.

[0051] Fig. 7 shows a block diagram 700 illustrating a processing resource 702 and a machine-readable medium 704 encoded with example instructions to facilitate dynamic management of workloads, according to an example. The machine-readable medium 704 may be non-transitory and is alternatively referred to as a non-transitory machine-readable medium 704. In some examples, the machine-readable medium 704 may be accessed by the processing resource 702. In some examples, the processing resource 702 may represent an example of the processing resource 122 of the system 102. Further, the machine-readable medium 704 may represent an example of the machine-readable medium 124 of the system 102.

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

[0053] The processing resource 702 may be a physical device, e.g., one or more CPUs, one or more semiconductor-based microprocessors, one or more GPUs, ASICs, FPGAs, other hardware devices capable of retrieving and executing the instructions 706-718 stored in the machine-readable medium 704, or combinations thereof. In some examples, the processing resource 702 may retrieve, decode, and execute the instructions 706-718 stored in the machine-readable medium 704 to deploy workloads on one or more of the target environments 108. In certain examples, alternatively or in addition to retrieving and executing the instructions 706-718, the processing resource 702 may include at least one IC, other control logic, other electronic circuitry, or combinations thereof, including a series of electronic components for performing the functions performed by the system 102 of Fig.1 should be executed.

[0054] Instructions 706, when executed by processing resource 702, may cause processing resource 702 to receive a workload attestation request including the workload specification from the workload generation node. Further, instructions 708, when executed by processing resource 702, may cause processing resource 702 to determine a workload profile based on the workload specification. Furthermore, instructions 710, when executed by processing resource 702, may cause processing resource 702 to identify policies stored in policy database 106 based on the workload profile.Additionally, instructions 712, when executed by processing resource 702, may cause processing resource 702 to provide an attestation identifier indicating the workload profile in response to the workload attestation request. Further, instructions 714, when executed by processing resource 702, may cause processing resource 702 to receive a request for the policy from the controller node in the target environment. The request includes the identifier for the attestation. Instructions 716, when executed by processing resource 702, may cause processing resource 702 to compile the policy from the policy database using the attestation identifier.The instructions 712, when executed by the processing resource 702, may cause the processing resource 702 to communicate the policy to the control node, which applies the policy in the target environment.

[0055] Although specific implementations have been shown and described above, various changes in form and details may be made. For example, some features and / or functions described with respect to one implementation and / or process may be transferred to other implementations. In other words, processes, features, components, and / or characteristics described with respect to one implementation may also be useful in other implementations. Furthermore, it should be understood that the systems and methods described herein may include various combinations and / or subcombinations of the components and / or features of the various implementations described.

[0056] In the foregoing description, numerous details are set forth to facilitate understanding of the subject matter disclosed herein. However, the invention may be practiced without some or all of these details. Other implementations may include modifications, combinations, and variations of the details described above. The following claims are intended to cover such modifications and variations.

Claims

[1] A process comprising: Receiving, by a processor-based system, a workload certification request (116) from a workload generation node (104), wherein the workload certification request (116) includes a workload specification (114) of a workload (112); Determining a workload profile (204) by the processor-based system based on the workload specification (114); identifying, by the processor-based system, a policy (504) stored in a policy database (106) based on the workload profile (204); providing a certificate identifier (118) by the processor-based system to the workload generation node (104) in response to the workload certificate request (116), the certificate identifier (118) indicating the workload profile (204); receiving, by the processor-based system, a request for the policy (504) from a controller node (128) in a target environment (108), the request including the certificate identifier (118); Compiling the policy (504) from the policy database (106) by the processor-based system using the certificate identifier (118); and Providing the policy (504) by the processor-based system to the controller node (128), wherein the controller node (128) applies the policy (504) in the target environment (108). [2] The method of claim 1, wherein compiling the policy (504) comprises: Validating the certificate identifier (118) received from the controller node (128) in the target environment (108); and Retrieving the policy (504) associated with the certificate identifier (118) from the policy database (106). [3] The method of claim 1, further comprising: Performing a policy action (510) in the policy database (106), wherein the policy action (510) comprises creation, policy inheritance, policy extension, policy cloning, policy validation, policy update, or policy revocation. [4] The method of claim 1, further comprising: Receiving a notification (530) indicating a policy action (510) performed in the policy database (106), wherein the policy action (510) includes policy creation, policy inheritance, policy extension, policy cloning, policy validation, policy update, or policy revocation; Providing an updated certificate identifier (118) to the controller node (128) in the target environment (108); Receiving a request for updated policies (504) for the workload (112), the request including the updated certificate identifier (118); Recompiling the updated policy (504) based on the policy action (510) using the updated certificate identifier (118); Providing the updated policy (504) to the controller node (128), wherein the controller node (128) applies the policy (504) in the target environment (108). [5] The method of claim 1, wherein the policy (504) comprises a user-defined policy, an environment-specific policy, or a global policy applicable in each target environment (108). [6] The method of claim 1, wherein the workload (112) comprises a container, a pod, a virtual machine, or a containerized application. [7] The method of claim 1, wherein the workload specification (114) includes application ports, request privileges, an ingress whitelist, authentication modes, and exposure modes. [8] A policy management system (504) comprising: a processing resource (122); a machine-readable medium storing one or more instructions that, when executed by the processing resource (122), cause the processing resource (122): receive a workload certification request (116) from a workload generation node (104), the workload certification request (116) including a workload specification (114) of a workload (112); determine a workload profile (204) based on the workload specification (114); identify a policy (504) stored in a policy database (106) based on the workload profile (204); provide a certificate identifier (118) in response to the workload certificate request (116), the certificate identifier (118) indicating the workload profile (204); receive a request for the policy (504) from a controller node (128) in a target environment (108), the request including the certificate identifier (118); compile the policy (504) from the policy database (106) using the certificate identifier (118); and provide the policy (504) to the controller node (128), wherein the controller node (128) applies the policy (504) in the target environment (108). [9] The system of claim 8, wherein the instructions, when extended, cause the processing resource (122) to perform a policy action (510) in the policy database (106), the policy action (510) comprising policy creation, policy inheritance, policy extension, policy cloning, policy validation, policy update, or policy revocation. [10] The system of claim 8, wherein the instructions, when extended, cause the processing resource (122): receive a notification (530) indicating a policy action (510) performed in the policy database (106), wherein the policy action (510) includes policy creation, policy inheritance, policy extension, policy cloning, policy validation, policy update, or policy revocation; provide an updated certificate identifier (118) for the controller node (128) in the target environment (108) in response to receiving the notification (530); receive a request for updated policies (504) for the workload (112), the request including the updated certificate identifier (118); recompile the policy (504) based on the policy action (510) using the updated certificate identifier (118); and provide the updated policy (504) to the controller node (128), wherein the controller node (128) applies the policy (504) in the target environment (108). [11] The system of claim 8, wherein the instructions, when extended, cause the processing resource (122) to create a dashboard interface (502) for displaying a summary of the status and relationships between the policies (504), the workload profiles (204), the target environments (108), and the workloads (112). [12] The system of claim 8, wherein the workload (112) comprises a container, a pod, a virtual machine, or a containerized application. [13] The system of claim 8, wherein the workload specification (114) includes one or more application ports, request privileges, an ingress whitelist, authentication modes, and exposure modes. [14] non-transitory, machine-readable medium storing instructions executable by a processing resource (122), the instructions comprising: Instructions for receiving a workload certification request (116) from a workload generation node (104), the workload certification request (116) including a workload specification (114) of a workload (112); Instructions for determining a workload profile (204) based on the workload specification (114); Instructions for identifying a policy (504) stored in a policy database (106) based on the workload profile (204); Instructions for providing a certificate identifier (118) in response to the workload certificate request (116), the certificate identifier (118) indicating the workload profile (204); Instructions for receiving a request for the policy (504) from a controller node (128) in a target environment (108), the request including the certificate identifier (118); Instructions for compiling the policy (504) from the policy database (106) using the certificate identifier (118); and Instructions for providing the policy (504) to the controller node (128), wherein the controller node (128) applies the policy (504) in the target environment (108). [15] The non-transitory machine-readable medium of claim 14, further comprising instructions for performing a policy action (510) in the policy database (106), wherein the policy action (510) comprises policy creation, policy inheritance, policy extension, policy cloning, policy validation, policy update, or policy revocation. [16] The non-transitory machine-readable medium of claim 14, further comprising: Instructions for receiving a notification (530) indicating a policy action (510) performed in the policy database (106), wherein the policy action (510) includes policy creation, policy inheritance, policy extension, policy cloning, policy validation, policy update, or policy revocation; Instructions for providing an updated certificate identifier (118) to the controller node (128) in the target environment (108); Instructions to receive a request for updated policies (504) for the workload (112), the request including the updated certificate identifier (118); Instructions for recompiling the policy (504) based on the policy action (510) using the updated certificate identifier (118); and Instructions for providing the updated policy (504) to the controller node (128), wherein the controller node (128) applies the policy (504) in the target environment (108). [17] The non-transitory machine-readable medium of claim 14, wherein the instructions for compiling the policy (504) from the policy database (106) using the certificate identifier (118) comprise: Instructions for validating the certificate identifier (118) received from the controller node (128) in the target environment (108); and Instructions for retrieving the policy (504) associated with the certificate identifier (118) from the policy database (106). [18] The non-transitory machine-readable medium of claim 14, further comprising instructions for creating a dashboard interface (502) for displaying a summary of the status and relationships between the policies (504), the workload profiles (204), the target environments (108), and the workloads (112). [19] The non-transitory machine-readable medium of claim 14, wherein the workload specification (114) includes application ports, request privileges, an ingress whitelist, authentication modes, and exposure modes. [20] The non-transitory machine-readable medium of claim 14, wherein the policy (504) includes a user-defined policy, an environment-specific policy, or a global policy applicable in each target environment (108).

Images