ADJUSTMENT OF ACCESS PERMISSIONS OF USER DEVICES BASED ON CREATED ACCESS POLICIES

A computer-implemented method, according to one embodiment, includes analyzing a deployment plan for an instance of Infrastructure as Code (IaC) code to identify a plurality of milestones of the deployment plan, and creating access policies for the identified milestones. The method further includes monitoring milestone state logs during an execution of the instance of IaC code for occurrence of predetermined milestone events. In response to a determination that a first of the predetermined milestone events has occurred, first user device access permissions are adjusted based on the created access policies. A computer program product, according to one embodiment, includes a computer readable storage medium having program instructions embodied therewith. The program instructions are readable and/or executable by a processing circuit to cause the processing circuit to perform the foregoing method.

BACKGROUND

The present invention relates to Infrastructure as Code (IaC), and more specifically, this invention relates to adjusting access permissions of user devices based on created access policies.

IaC automation templates are used to declaratively provision cloud resources. An IaC automation template acts as a single source of truth for cloud configuration data. In addition, the IaC code or IaC template acts as a dynamic workflow definition, that may be used by an underlying workflow engine to program and configure the cloud in a systematic manner. IaC code may be changed at any time, and the new IaC Code may be deployed to a cloud infrastructure. Tools may be configured to assess and/or detect the changes in configuration state, build a workflow (to achieve a goal state), and incrementally update a configuration state of a cloud environment.

A user device, e.g., the subject, that is performing a configuration change, using the IaC code, must have permissions associated with the updates to the cloud's configuration state. For context, each cloud resource in the IaC code may have a unique associated permission or access-control definition that the user device must request and obtain in order to perform cloud operations. In conventional deployments, it may be assumed that the user device has already obtained the necessary permissions from an administrator device, to perform the cloud operations (to update the configuration state) on all the relevant cloud resources. One of these conventional approaches for obtaining these permissions includes inspecting the IaC code to determine a list of resources that must be touched for the update, and sharing the list of resources (and operations) with the administrator device in order to obtain the associated permissions.

SUMMARY

A computer-implemented method, according to one embodiment, includes analyzing a deployment plan for an instance of Infrastructure as Code (IaC) code to identify a plurality of milestones of the deployment plan, and creating access policies for the identified milestones. The method further includes monitoring milestone state logs during an execution of the instance of IaC code for occurrence of predetermined milestone events. In response to a determination that a first of the predetermined milestone events has occurred, first user device access permissions are adjusted based on the created access policies.

A computer program product, according to one embodiment, includes a computer readable storage medium having program instructions embodied therewith. The program instructions are readable and/or executable by a processing circuit to cause the processing circuit to perform the foregoing method.

A system, according to one embodiment, includes a processor, and logic integrated with the processor, executable by the processor, or integrated with and executable by the processor. The logic is configured to perform the foregoing method.

DETAILED DESCRIPTION

The following description discloses several preferred embodiments of systems, methods and computer program products for adjusting access permissions of user devices based on created access policies.

In one general embodiment, a computer-implemented method includes analyzing a deployment plan for an instance of Infrastructure as Code (IaC) code to identify a plurality of milestones of the deployment plan, and creating access policies for the identified milestones. The method further includes monitoring milestone state logs during an execution of the instance of IaC code for occurrence of predetermined milestone events. In response to a determination that a first of the predetermined milestone events has occurred, first user device access permissions are adjusted based on the created access policies.

In another general embodiment, a computer program product includes a computer readable storage medium having program instructions embodied therewith. The program instructions are readable and/or executable by a processing circuit to cause the processing circuit to perform the foregoing method.

In another general embodiment, a system includes a processor, and logic integrated with the processor, executable by the processor, or integrated with and executable by the processor. The logic is configured to perform the foregoing method.

As mentioned elsewhere herein, IaC automation templates are used to declaratively provision cloud resources. An IaC automation template acts as a single source of truth for cloud configuration data. In addition, the IaC code or IaC template acts as a dynamic workflow definition, that may be used by an underlying workflow engine to program and configure the cloud in a systematic manner. IaC code may be changed at any time, and the new IaC Code may be deployed to a cloud infrastructure. The configuration of the cloud resources may also be changed at any time, using the graphical user interface (GUI) or command line interface (CLI). Tools may be configured to assess and/or detect the changes in configuration state, dynamically build a workflow (to achieve a goal state), and incrementally update a configuration state of a cloud environment.

A user device, e.g., the subject, that is performing a configuration change, using the IaC code, must have permissions associated with the updates to the cloud's configuration state. For context, each cloud resource in the IaC code may have a unique associated permission or access-control definition that the user device must request and obtain in order to perform cloud operations. In conventional deployments, it may be assumed that the user device has already obtained the necessary permissions from an administrator device, to perform the cloud operations (to update the configuration state) on all the relevant cloud resources. One of these conventional approaches for obtaining these permissions includes inspecting the IaC code to determine a list of resources that must be touched for the update, and sharing the list of resources (and operations) with the administrator device in order to obtain the associated permissions.

The conventional techniques for obtaining permissions described above involve IaC code that is used to assemble multiple cloud-resources. Within some of these techniques and IaC code use cases, each cloud-resource has a predefined set of permissions (or access controls) to perform create, read, update, and delete (CRUD) operations on its configuration state. However, these techniques become problematic when a user device performs CRUD operation on the composite IaC Code in that there is no guarantee that the user device will obtain and have the permissions to all the cloud-resources used in the IaC Code. This leads to some instances of user devices not gaining permission to access at least some resources associated with updates to a cloud's configuration state. These instances ultimately compromise performance of a cloud environment that includes the cloud-resources, because, e.g., the user devices are unable to access the available cloud resources, troubleshooting must be performed to manually obtain permissions for the user devices, the cloud resources are sometimes no longer available by the time that the user devices finally obtain permissions to the cloud resources, etc. For at least these reasons, there is a longstanding need for techniques that define an access-policy for composite resources described using an “IaC code” that dynamically morphs based on both a current state of the cloud environment, and a desired state expressed in an IaC code. In sharp contrast to the deficiencies described above, techniques described herein dynamically modify the permission levels for user devices to access cloud resources (in IaC code) during execution of the IaC code such that, a user device is provided with the permissions associated with operating on the cloud-resources, in a just-in-time manner.

Now referring toFIG.2, a flowchart of a method200is shown according to one embodiment. The method200may be performed in accordance with the present invention in any of the environments depicted inFIGS.1-5, among others, in various embodiments. Of course, more or fewer operations than those specifically described inFIG.2may be included in method200, as would be understood by one of skill in the art upon reading the present descriptions.

It may be prefaced that method200may be performed in a type of cloud environment that would become apparent to one of ordinary skill in the art after reading the descriptions herein. In some preferred approaches, the cloud environment includes at least one user device (see first user device202), an IaC deployment manager component204, an IaC access manager component206, and an administrator device208. In some preferred approaches, the IaC deployment manager component is an infrastructure tool responsible for IaC deployment, and the IaC access manager component is a component that is configured to identity and access management (IAM) or IAM enabled services. Various approaches described below detail interactions between these components. It may also be noted that operations of method200may be performed in a cloud environment that includes a plurality of cloud resources. For example, depending on the approach, these cloud resources may include, e.g., object storage, access to a predetermined database, use of a virtual private cloud (VPC), use of a data engine, access to cloud computing processing and/or computing resources, etc. Furthermore, in some approaches, the operations of method200may be performed with respect to IaC code. In one of such approaches, the IaC code may be TERRAFORM.

In some approaches, method200includes a just-in-time access policy for a group of user devices and/or users associated with the user device being defined, e.g., see operation210. In some approaches, the just-in-time access policy is defined by the administrator device208. For context, the user devices of the just-in-time access policy are user device that are authorized and/or registered to acquire relatively higher privileges and/or permissions (on-demand) to work with a predetermined IaC Code (and resources associated therewith) in an on-demand manner. In some approaches, these user devices may be authorized and/or registered to acquire the relatively higher privileges and/or permissions by a predetermined process, e.g., a registration process in which user devices requesting access to the resources are at least initially subjected to training and/or verification techniques of a type that would become apparent to one of ordinary skill in the art after reading the descriptions herein. For example, operation212includes registering at least a first user device, e.g., User-1, with the IaC access manager. As a result of at least the first user device being registered with the IaC access manager, the IaC access manager is preferably configured to cause, e.g., instruct the IaC deployment manager component, the user device to be added to and/or removed from milestone access groups, as will be described in greater detail elsewhere below.

A deployment plan for IaC code may be generated, e.g., by the IaC deployment manager component, based on a current configuration state of the cloud environment, e.g., see operation216. In some approaches, the deployment plan for IaC code may be generated in response to receiving, e.g., by the IaC deployment manager component from the first user device, a request to initiate an IaC template deployment, e.g., see operation214. The deployment plan may include information of a type that would become apparent to one of ordinary skill in the art after reading the descriptions herein. For example, in some approaches, such as for a typical first-time deployment, the generated deployment may include a plurality of provisions of resources with respect to one another. For example, the generated deployment may provision, e.g., and/or include an indication, a first predetermined first resource with a predetermined second resource in parallel. The generated deployment may additionally and/or alternatively provision a fourth predetermined resource after the first predetermined resources completes a predetermined operation, provision a third predetermined resource after the second predetermined resource completes a predetermined operation, provision a fifth predetermined resource after the third and fourth predetermined resources complete predetermined task(s), etc.

When shared, the deployment plan for an instance of IaC code that is based on a current configuration state of the cloud environment may be received by the IaC access manager component from the IaC deployment manager component, e.g., see operation218.

The IaC deployment manager component may use the IaC deployment plan to deploy the IaC code. A typical IaC deployment plan may, in some approaches, include a plurality of milestones. For context, a “milestone” may be anything that refers to or defines a particular stage of deployment, and, in some approaches, defines different periods of time that one or more resources of the cloud environment will be provisioned. The milestones may differ depending on how the cloud resources are tied to one another in the IaC code and/or depending on how a cloud service treats these cloud resources. For example, a first milestone may provision a plurality of predetermined resources. However, in some other approaches, only a single resources may be provisioned for a second milestone. In some approaches, an initial deployment plan may provision a plurality of resources to at least one milestone. In some other approaches, only a subset of the resources provisioned in the initial deployment plan may be provisioned to at least one of the milestones, e.g., based on an updating.

For context, once received, the deployment plan may be analyzed by the IaC access manager component. For example, operation220includes analyzing the deployment plan for an instance of IaC code to identify a plurality of milestones of the deployment plan. In some preferred approaches, this analysis identifies and/or inspects the milestones in order to create access policies for the milestones that will occur during execution of the IaC code. In some approaches, an access group may be created for each milestone group, e.g., see operation222. For context, an “access group” is a group of identities that can be used as the subject of an access policy. For further context, each “access policy” specifies an allowed set of actions. Access policies, in some preferred approaches, have the form of <subject> <role> <resource(s)>, where the “subject” is the user device that may be added to or removed from the access group, the “role” describes the permission used to perform an operation (CRUD) on the cloud resources, and the “resource(s)” are the resources that the subject at least temporarily has access to as a result of being added to the access policy. This way, a plurality of access requests are not otherwise performed by a registered user device, e.g., User-1, in order to access resources of the cloud environment during the different milestones. Instead, the created access policies may be used to provide the user device with just-in-time access to such resources during a predetermined milestone event, with subsequent detachment of the user devices in response to a determination that the predetermined milestone event has concluded. Note that, in some approaches, such detachment is preferably performed regardless of success or failure at the completion of the predetermined milestone event. Access policies are preferably created by the IaC deployment manager component for the milestones identified during the performed analysis. More specifically, in some preferred approaches, method200includes analyzing the IaC deployment plan to dynamically create multiple IaC access policies, e.g., one for each milestone in the IaC deployment plan.

In some approaches, method200includes determining types of permissions to deploy in the access policies. The types of permissions may, in one or more of such approaches, be determined by searching for and potentially extracting one or more predetermined text elements from the received deployment plan. For example, the deployment plan may indicate one or more operations, e.g., delete, modify, access, etc., that are to be performed in each milestone. Predetermined text elements that are associated with these operations may be identified, e.g., using natural language processing (NLP) techniques that would become apparent to one of ordinary skill in the art after reading the descriptions herein. In some approaches, creating the access policies includes assigning the permissions to resources that are accessible within milestone access groups associated with the access policies. For example, a first permission to delete data may be assigned to a first resource that is to be performed in a first of the milestones of the deployment plan, a second permission to modify data may be assigned to a second resource that is to be performed in the first milestone of the deployment plan, and a third permission to access data may be assigned to a third resource that is to be performed in a second of the milestones of the deployment plan that occurs after the first milestone concludes.

Method200may additionally and/or alternatively include estimating amounts of time that using resources in identified milestones will take during the execution of the instance of the IaC code. In some approaches, such estimations may be based on a temporal analysis of previously executed instances of IaC code, e.g., where the previously executed instances of IaC code are determined to have at least a predetermined degree of similarity with the instance of IaC code associated with the received deployment plan. Accordingly, in some approaches, the access policies may be created based on the estimated amounts of time.

Box224of method200includes operations of a predetermined milestone deployment process. For context, the predetermined milestone deployment process includes ensuring that user devices do not have to initiate resource permissions during an execution of the instance of IaC code. In some approaches, the predetermined milestone deployment process may include execution of the instance of IaC code being initiated. Upon the instance of the IaC code being initiated, the predetermined milestone deployment process may include adding a user device, e.g., the first user device, to one of the new milestone access groups. In some preferred approaches, during the predetermined milestone deployment process, user devices are added to at least an initial one of the milestone access groups in response to a determination that one of the milestone events has begun during the execution of the instance of IaC code. For example, in some approaches, a first of the predetermined milestone events may include a first milestone event being initiated. In one or more of such approaches, the adjustment performed in response to the determination that the first of the predetermined milestone events has occurred may include causing a first user device to be added to a first milestone access group that is associated with a first of the access policies, e.g., see operation226. The first user device may, in some approaches, be caused to be added to a first milestone access group by the IaC access manager issuing an assignment instruction to the IaC deployment manager. For context, “adding” a given user device to a milestone access group may provide the user device with access to one or more predetermined cloud resources according to an access policy, e.g., see milestone resource deployment in operation228. For example, the first user device preferably has access to at least a first cloud resource as a result of being added to the first milestone access group, and the first user device does not have access to the first cloud resource when not otherwise added/included in the first milestone access group. In other words, access to resources is selectively granted to a determined user device for at least a temporary period of time as a result of a milestone event occurring during execution of the instance of the IaC code. This selective granting enables a dynamically morphing access-policy based on the current state of the cloud environment and the desired state expressed in the IaC code. Furthermore, the techniques described herein enable dynamic modification of the permission levels for user device(s) to access cloud resources in IaC code while performing a long-running IaC automation for a collection of cloud-resources. This ensures security and oversight in the cloud environment by ensuring that the user device is allowed only a minimal or a relatively least extent of permissions that are required to operate on the cloud-resources just-in-time.

The cloud resources that user devices have access to as a result of being added to a milestone access group may depend on the approach and/or deployment parameters. However, it should be noted that this access to the cloud resources is preferably only provided to the user device upon being added to the milestone access group. Accordingly, in some approaches, upon the IaC deployment manager component beginning to run the instance of the IaC code, the IaC Access Manager component preferably uses a just-in-time access policy to activate an associated access policy for the user device, e.g., by an instruction being issued for attaching the user device to the milestone access group. In some illustrative approaches, a first of the cloud resources includes object storage. In another approach, the cloud resources may additionally and/or alternatively include access to a predetermined database. In yet another approach, the cloud resources may additionally and/or alternatively include use of a virtual private cloud (VPC). In yet another approach, the cloud resources may additionally and/or alternatively include use of a data engine. It should be noted that the created access policies preferably define what resources are available to user devices that are added to an associated milestone access group. For example, a first of the created access policies may specify that a first resource is made available to a first user device during a first milestone that occurs during execution of the instance of the IaC code.

Subsequent to being added to a milestone access group, the first user device is preferably not indefinitely provided access to the cloud resources within the first milestone access group. Instead, metrics may be monitored for determining when to remove the first user device from the milestone access group. In some preferred approaches, milestone state logs are examined and monitored to determine and monitor such metrics. This monitoring may include reviewing logs and/or event information received from the IaC deployment manager component to understand a state of the running instance of IaC code execution. In some approaches, this monitoring may additionally and/or alternatively include monitoring cloud-resources deployed by the instance of IaC code to determine whether any configuration change events have occurred. For context, in some approaches, the milestone state logs preferably detail the progression of the milestones during execution of the instance of the IaC code, and therefore may be accessed to determine whether a given identified milestone has concluded and/or another identified milestone has begun. Accordingly, milestone state logs may be received and/or requested, and the milestone state logs may be monitored during an execution of the instance of IaC code for occurrence of predetermined milestone events, e.g., see operation230. The monitoring may, in some approaches, include determining whether performance metrics pre-associated with a first of the milestone events has ended and/or whether performance metrics pre-associated with a second of the milestone events have been detected. For example, in a first of such approaches, in response to a determination that predetermined performance metrics, e.g., use of cloud resources associated with the first milestone event, processing operations that began upon the first user device being added to the first milestone access group, processing operations decreasing a predetermined amount, etc., pre-associated with a first of the milestone events are no longer present in the milestone state logs, a determination may be made that a predetermined milestone event has occurred. In such an approach, the predetermined milestone event includes the first milestone event ending.

In response to a determination that a first of the predetermined milestone events has occurred, method200includes adjusting user device access permissions based on the created access policies. More specifically, in some approaches, the IaC access manager component may be caused to auto-adjust the access permissions of the user device depending on a milestone state of the IaC deployment plan execution. This may be achieved by moving the user device and/or a subject to a next milestone-specific access group, thereby switching to a new access policy. For example, in some preferred approaches, the access permissions of a user device that are currently included in a milestone access group are adjusted to detach the user device from the milestone access group, e.g., user devices are detached from milestone access groups in response to a determination that the milestone has completed. In one of such approaches, this adjustment includes adjusting access permissions of the first user device based on a first of the created access policies that specifies that the first user device is to be removed from the first milestone access group in response to a determination that the first milestone has completed, e.g., see operation232.

Method200may additionally and/or alternatively include initiating further milestone deployments in response to a determination that the first milestone event has occurred, e.g., see operation234. In some approaches, these further milestone deployments may include continuing to monitor for predetermined milestone events, e.g., such as the beginning of and/or the ending of milestone events, and in response to a determination that one or more of such milestone events have occurred, adjusting user device access permissions based on the created access policies. For example, in response to a determination that a second of the predetermined milestone events has occurred, method200includes adjusting the first user device access permissions and second user device access permissions based on the created access policies. In some approaches, the adjustments performed in response to the determination that the second of the predetermined milestone events has occurred includes causing a second user device to be added to a second milestone access group associated with a second of the access policies. The second user device may have access to at least a second cloud resource as a result of being added to the second milestone access group, and the second user device may not have access to the second cloud resource when not otherwise added/included in the second milestone access group. Furthermore, in some approaches, the first user device is caused to be removed from the first milestone access group and the first user device loses access to at least the first cloud resource as a result of being removed from the first milestone access group. This loss of access to at least the first cloud resource may, in some approaches, occur at the same time that the second user device gains access to at least the second cloud resource.

It should be noted that although various approaches above describe a first user device and a second user device having user device access permissions adjusted throughout the different milestone events, in some approaches, a single user device, e.g., the first user device, may have user device access permissions across two or more of the milestone events, e.g., the first user device may be moved from a first milestone access group to a second milestone access group in response to a determination that the first milestone has been successfully completed.

The adjustment of user device access permissions in response to determination(s) that predetermined milestone events have occurred may continue until all of the milestones are completed during the execution of the instance of IaC code. Accordingly, method200may, in some approaches, include adding and detaching, e.g., a third user device, a fourth user devices, a fifth user device, etc., from milestone access groups until a determination is made that a user device is detached from a last of the milestone access groups, e.g., see operation236. It should be noted that, during such additions and/or detachments, one or more of the cloud resources may be dependent on at least one other cloud resource. For example, in some approaches, the second cloud resource is dependent on the first cloud resource. This dependency may mean that the second resource cannot be used until use of the first resource is complete. Accordingly, in some approaches, the provisioning of the second resource may be delayed until a determination is made that processing using the first resource has completed, e.g., processing performed by the first user device using the first resource.

Operation238includes finishing the IaC template deployment. In some approaches, finishing the IaC template deployment includes relaying the IaC template to the user device. The IaC template preferably includes the created access policies and/or other instructions generated during the initial execution of the instance of IaC code, e.g., additions and/or detachments performed during the predetermined milestone deployment process.

Although various approaches above detail a use case in which an IaC template for provisioning cloud resources is created, in some other approaches, method200may additionally and/or alternatively include the IaC template being updated. For example, in some approaches, the execution of the instance of IaC code may cause updates of a subset of cloud resources that are associated with the access policies. In one or more of such approaches, the predetermined milestone events may only be based on the created access policies associated with the subset of the cloud resources. In other words, in some approaches, only detection of milestone events associated with the cloud resources that are being updated result in adjustments to user device access permissions, while no changes are performed to the other resource provisioning specified in the IaC template, e.g., the resource provisioning of the IaC template that the updates do not affect.

Various performance benefits are enabled as a result of deploying the techniques described herein in a cloud environment in which cloud resources are provisioned to user devices. These techniques may be used to define and enforce a just-in-time authorization policy for composite resources described using an IaC code. For example, the techniques described herein provide permission guarantees for accessing cloud resources that are not otherwise available using conventional techniques for performing CRUD operations. Accordingly, instances of user devices not gaining permission to access at least some resources associated with updates to a cloud's configuration state are avoided, thereby increasing performance of a cloud environment that includes the cloud-resources. Furthermore, performance of the cloud environment is also improved as a result of avoiding such permission failure events, because troubleshooting operations to manually obtain permissions for the user devices are also mitigated.

FIGS.3A-3Ddepicts tables300,320,340and360that include information used for adjusting access permissions of user devices based on created access policies, in accordance with several embodiments. As an option, the present tables300,320,340and360may be implemented in conjunction with features from any other embodiment listed herein, such as those described with reference to the other FIGS. Of course, however, such tables300,320,340and360and others presented herein may be used in various applications and/or in permutations which may or may not be specifically described in the illustrative embodiments listed herein. Further, the tables300,320,340and360presented herein may be used in any desired environment.

It may be prefaced that the tables300,320,340and360include information that is based on an IaC template (as an instance of IaC code) that is used to provision the cloud resources: R1, R2, R3, R4and R5. It may be assumed that resource dependencies exist that include: R3being dependent on R2, R5being dependent on R3and R4, and R4being dependent on R1. Respective amounts of time that using the cloud resources in a plurality of milestones identified within a deployment plan for the instance of IaC code will take during the execution of the instance of the IaC code may be estimated. In some approaches, the time estimates for the cloud resources include: R1: 3 minutes, R2: 8 minutes, R3: 20 minutes, R4: 10 minutes and R5: 7 minutes.

In some approaches, in a typical first-time deployment, an open-source IaC software tool, e.g., such as TERRAFORM, may be used to generate a deployment plan. In some approaches, the deployment plan may provision R1and R2in parallel, provision R4after R1completes, provision R3after R2completes, and provision R5after R3and R4complete. Referring now toFIG.3A, the deployment plan is shown arranged in the table300. The table300details the deployment plan as a temporal breakdown of usage of the cloud resources. It may be noted that this temporal breakdown considers the resource dependencies, e.g., R1and R2are used in parallel, R3is not used until usage of R2is complete, R5is not used until usage of R3and R4is complete, etc. In some approaches, a user device that is used to deploy this IaC template for the first time may need the permissions detailed in the table320ofFIG.3B. For example, a first user device may need a create type access permission to use R1, an update type access permission to use R2, a create type access permission to use R3, a create type access permission to use R4, and an update type access permission to use R5.

Based on the above information, an IaC IAM access manager component may be caused to generate cloud resource provisioning milestones in table340ofFIG.3C. For example, a first milestone, e.g., see Milestone1, may include R1and R2, a second milestone, e.g., see Milestone2, may include R3and R4, and a third milestone, e.g., see Milestone3, may include R5. With reference now toFIG.3D, access policies may be created for the identified milestones. For example, the table360includes a first milestone access policy, e.g., see Milestone1access policy, that includes R1(create) and R2(update). Furthermore, the table360includes a second milestone, e.g., see Milestone2access policy, that includes R3(create) and R4(create). Finally, the table360further includes a third milestone access policy, e.g., see Milestone3access policy, that includes R5(update). It may be noted that, in some approaches, a granularity of the number of resources managed per milestone may be configurable. In addition, the resource groups of the cloud resources are preferably considered while drawing boundaries for the milestones.

In some illustrative use cases, a predetermined process may be performed that includes using the information of the tables300,320,340and360to adjust access permissions of user devices based on created access policies. In one or more of such use cases, a cloud account administrator device may be used to create a just-in-time access policy for user devices that will be given permissions (on-demand) to provision or configure the cloud resources using the selected IaC code. These user devices are prevented from using this permission outside the scope of the IaC code execution based on being added and detached from milestone access groups.

Upon initiation of the deployment of the IaC template, the predetermined process may include causing an IaC IAM access manager component to create multiple milestone access policies (for all identified IaC milestones, and corresponding milestone access groups). In response to a determination that a user device belongs to the just-in-time access policy of the IaC template, the user device is added to the milestone1access group. An IaC code engine, e.g., an IaC deployment manager component, may be caused, e.g., instructed by the IaC IAM access manager component to provision cloud resources R1and R2(milestone1). Furthermore, the IaC IAM access manager component may be caused to monitor progress of provisioning of the resources R1and R2and the IaC automation logs and/or events. In response to a determination that milestone1has successfully completed, the user device is moved from milestone1access group to milestone2access group.

In some approaches, the IaC deployment manager component is made aware of the changes being made by the IaC IAM access manager component, e.g., by outputs of the IaC IAM access manager component to the IaC deployment manager component, and may be caused to wait before starting the next milestone tasks. The IaC code engine, e.g., an IaC deployment manager component, may be caused to provision resources R3and R4(milestone2) based on an instruction issued by the IaC IAM access manager component. The IaC IAM access manager component then monitors the progress of provisioning the resource R3& R4. In response to a determination that the second milestone has been successfully completed, the first user device is caused to be moved from milestone2access group to milestone3access group.

The predetermined process may additionally and/or alternatively include the IaC code engine, e.g., an IaC deployment manager component, provisioning cloud resource R5. In response to a determination that the third milestone event, e.g., milestone3, has been successfully completed, the user device is removed from the milestone3access group.

During this deployment (execution of the instance of IaC code), the user device is provided with the permissions to provision the cloud resources in the IaC template, and therefore the user device does not have to otherwise request each of such permissions. Subsequently, these permissions are withdrawn. In some approaches, the user device is granted permissions only during the provisioning action, thereby ensuring that the user device is scoped to relevant resource instances and/or resource groups.

FIGS.4A-4Cdepicts tables400,420and440that include information used for updating access permissions of user devices in a cloud environment that is already provisioned, in accordance with several embodiments. As an option, the present tables400,420and440may be implemented in conjunction with features from any other embodiment listed herein, such as those described with reference to the other FIGS. Of course, however, such tables400,420and440and others presented herein may be used in various applications and/or in permutations which may or may not be specifically described in the illustrative embodiments listed herein. Further, the tables400,420and440presented herein may be used in any desired environment.

It may be prefaced thatFIGS.4A-4Cdetail an extension to the scenario described above, e.g., seeFIGS.3A-3D. More specifically,FIGS.4A-4Cdetail information associated with a cloud environment that is already provisioned using an IaC template to configure cloud resources R1, R2, R3, R4, and R5. In the current approach, it may be assumed that a user device initiates a change of the configuration of a few cloud resources in the IaC template. Referring now toFIG.4A, the table400includes information that may be used to determine the list of resources that will be modified as a result of the configuration change. For example, the deployment plan to deploy the configuration change includes: a first update to the cloud resource R2, a second update to the cloud resource R3(after R2completes), and destroying the cloud resource R5(after R3completes).

Based on the information in the table300, an IaC IAM access manager component may generate resource provisioning milestones. With reference now to table420ofFIG.4B, these resource provisioning milestones may include: milestone1: R2, milestone2: R3, and milestone3: R5. Furthermore, an access policy may be generated for each of the milestones. As illustrated in table440ofFIG.4C, these policies may include a first milestone access policy, e.g., see Milestone1access policy, a second milestone access policy, e.g., see Milestone2access policy, and a third milestone access policy, e.g., see Milestone3access policy. It should be noted that, in some approaches, a granularity of the number of resources managed per milestone is configurable.

Upon initiation of configuration change based on the deployment plan, a predetermined update process may be performed that includes creating milestone access policies and milestone access groups for the three milestones. In response to a determination that a user device belongs to the just-in-time access policy of the IaC template, the user device is added to the milestone1access group. The IaC code engine, e.g., an IaC deployment manager component, may be caused to update the cloud resource R2.

The IaC IAM access manager component may monitor the progress of provisioning the cloud resource R2and the IaC automation logs and/or events. In response to a determination that the milestone1has successfully completed, the user device is moved from the milestone1access group to the milestone2access group. In some approaches, the IaC code engine, e.g., the IaC deployment manager component, may be caused, e.g., based on an instruction from the IaC IAM access manager component to update the cloud resource R3.

The predetermined process may additionally and/or alternatively include the IaC IAM access manager component monitoring the progress of updates to the cloud resource R3. In response to a determination that the milestone2has successfully completed, the user device is caused to move from the milestone2access group to the milestone3access group. In some approaches, the IaC deployment manager component may be caused, e.g., instructed, to destroy cloud resource R5in accordance with the update. Thereafter, in response to a determination that milestone3has been successfully completed, the user device is removed from the milestone3access group.

While various approaches above describe techniques in the context of cloud-resource provisioning using an IaC template, these techniques may, in some approaches, additionally and/or alternatively be applied in one or more other use cases. For example, in a further use case, these techniques may be applied to enable contextual access control in a workflow engine. In such a use case, the user devices may be dynamically granted and revoked permissions to perform the automated tasks and/or operations in the workflow definition. In another use case, these techniques may be applied to enable just-in-time milestone-based access control in which a user device's access permission is based on reaching a milestone (or the path taken towards the milestone), which thereby applies the use case to numerous application areas.

Now referring toFIG.5, a flowchart of a method509is shown according to one embodiment. The method509may be performed in accordance with the present invention in any of the environments depicted inFIGS.1-5, among others, in various embodiments. Of course, more or fewer operations than those specifically described inFIG.5may be included in method509, as would be understood by one of skill in the art upon reading the present descriptions.

With continued reference to method509, step500begins the deployment of the process software. An initial step is to determine if there are any programs that will reside on a server or servers when the process software is executed (501). If this is the case, then the servers that will contain the executables are identified (609). The process software for the server or servers is transferred directly to the servers' storage via FTP or some other protocol or by copying though the use of a shared file system (610). The process software is then installed on the servers (611).

Next, a determination is made on whether the process software is to be deployed by having users access the process software on a server or servers (502). If the users are to access the process software on servers, then the server addresses that will store the process software are identified (503).

A determination is made if a proxy server is to be built (600) to store the process software. A proxy server is a server that sits between a client application, such as a Web browser, and a real server. It intercepts all requests to the real server to see if it can fulfill the requests itself. If not, it forwards the request to the real server. The two primary benefits of a proxy server are to improve performance and to filter requests. If a proxy server is required, then the proxy server is installed (601). The process software is sent to the (one or more) servers either via a protocol such as FTP, or it is copied directly from the source files to the server files via file sharing (602). Another embodiment involves sending a transaction to the (one or more) servers that contained the process software, and have the server process the transaction and then receive and copy the process software to the server's file system. Once the process software is stored at the servers, the users via their client computers then access the process software on the servers and copy to their client computers file systems (603). Another embodiment is to have the servers automatically copy the process software to each client and then run the installation program for the process software at each client computer. The user executes the program that installs the process software on his client computer (612) and then exits the process (508).

In step504a determination is made whether the process software is to be deployed by sending the process software to users via e-mail. The set of users where the process software will be deployed are identified together with the addresses of the user client computers (505). The process software is sent via e-mail (604) to each of the users' client computers. The users then receive the e-mail (605) and then detach the process software from the e-mail to a directory on their client computers (606). The user executes the program that installs the process software on his client computer (612) and then exits the process (508).

Lastly, a determination is made on whether the process software will be sent directly to user directories on their client computers (506). If so, the user directories are identified (507). The process software is transferred directly to the user's client computer directory (607). This can be done in several ways such as, but not limited to, sharing the file system directories and then copying from the sender's file system to the recipient user's file system or, alternatively, using a transfer protocol such as File Transfer Protocol (FTP). The users access the directories on their client file systems in preparation for installing the process software (608). The user executes the program that installs the process software on his client computer (612) and then exits the process (508).