Intent-based governance

Abstract

Techniques for intent-based access control are described. A method of intent-based access control can include receiving, through a user interface of an intent-based governance service, one or more intent statements associated with a user resource in a provider network, the one or more intent statements expressing at least one type of action allowed to be performed on the user resource; compiling the one or more intent statements into at least one access control policy; and associating the at least one access control policy with the user resource.

Description

Background Technology

[0001] Access control within a provider network is often highly complex. This complexity can make users hesitant to use new services or the entire provider network due to concerns about the security of their resources. Customers can specify their data boundaries using access control primitives. For example, they develop policies across various subjects and resources to secure sensitive data and workloads. However, these policies do not change as the underlying systems that apply them evolve. Therefore, customers must constantly update these policies or create new ones based on changes to the provider network or their own organization, lacking the explicit ability to define their intent regarding their data boundaries. To make these updates, customers must understand all relevant changes and the service-specific characteristics within the provider network, resulting in a large amount of undifferentiated, tedious work and an inability to identify gaps in their data boundaries. Attached Figure Description

[0002] Various embodiments according to this disclosure will be described with reference to the accompanying drawings, in which:

[0003] Figure 1 This is a diagram illustrating an environment for intent-based governance according to some implementation schemes.

[0004] Figure 2 This is a diagram illustrating intent-based governance services according to some implementation schemes.

[0005] Figure 3 This is a diagram illustrating an environment for automatically generating updated policies based on intent-based access control, according to some implementation schemes.

[0006] Figure 4 This is a diagram illustrating examples of intent expressions using a domain-specific language according to some implementation schemes.

[0007] Figure 5 This is a flowchart illustrating the operation of a method for intent-based access control according to some implementation schemes.

[0008] Figure 6 An exemplary provider network environment is shown according to some implementation schemes.

[0009] Figure 7 This is a block diagram of an exemplary provider network that provides storage services and hardware virtualization services to customers according to some implementation schemes.

[0010] Figure 8 This is a block diagram illustrating an exemplary computer system that can be used in some implementations. Detailed Implementation

[0011] This disclosure relates to methods, apparatus, systems, and non-transitory computer-readable storage media for intent-based access control. According to some embodiments, the intent-based governance service includes a domain-specific language that includes multiple supported intents. Users can use the domain-specific language to write intent statements (e.g., "My resources should be marked by their cost centers," "My resources cannot be shared across accounts," "Only security administrators can change the configuration of security services," etc.). The intent-based governance service can then compile these statements to automatically generate policies and attach them to the corresponding subjects and resources to enforce data boundaries. This saves customers who would otherwise need to spend time writing low-level policies, debugging, and testing them to ensure they meet their higher-level intents. The embodiments also automatically update policies based on intent statements when the provider network launches new services and features and / or when changes occur within the customer's own organization. This ensures that customers always have secure and up-to-date data boundaries.

[0012] Traditionally, users can define policies that specify permissions for their resources. However, such policies only apply to the provider network and its services at the time the policy is written. For example, a policy can be written to restrict access to data in the storage service to prevent access by anyone outside the user's organization. This can be implemented to restrict access to existing endpoints from which data in the storage service can be accessed, and to restrict the ability of individual users within the organization to share data with other accounts. However, if the storage service is updated to include new sharing features (e.g., enabling individual users to create new endpoints, thereby providing interfaces to other services they previously did not have access to), existing policies may not cover these new features. This increases security risks that may not be immediately apparent unless the customer regularly monitors changes to the provider network and its services.

[0013] In some implementations, users can access an intent-based governance service through a user interface such as a console to provide intent-based statements. The intent-based governance service compiles these statements and provides feedback on what the resulting policies are based on the intent-based statements and any potential conflicts those new policies might cause within the user's organization. If any resulting permissions cannot be mapped according to the intent stated by the user, an error message indicating how the new policy cannot be implemented can be returned. Therefore, users are not required to handle the underlying complexities of permissions management for every service provided by the provider network. Furthermore, users do not need to keep track of the latest changes to the provider network or its services. Instead, the intent-based governance service monitors changes to the provider network and its services and automatically updates policies to align with the intent stated by the user.

[0014] Figure 1This is a diagram illustrating an environment for intent-based access control according to some implementation schemes. Customers (e.g., users) of provider network 100 may host various resources within provider network 100. Intent-based governance service 102 enables users to intuitively define high-level security intents for managing access to those resources. For example, implementations allow users to specify intents using simple, easy-to-understand statements. This intent is then translated into policies that apply to user resources across various services provided by the provider network. Such policies may include, for example, identity and access policies, resource policies and service control policies, as well as network controls, data lake authorization mechanisms, etc. Intent-based governance service 102 can automatically generate permissions based on intents and keep permissions up-to-date as provider network 100 or user resources change. Furthermore, users can update their intents, and existing permissions are updated accordingly.

[0015] Provider Network 100 (or “cloud” provider network) provides users with the ability to utilize one or more of various types of computing-related resources, such as computing resources (e.g., executing virtual machine (VM) instances and / or containers, executing batch jobs, executing code without provisioning servers), data / storage resources (e.g., object storage, block-level storage, data archive storage, databases and database tables, etc.), network-related resources (e.g., configuring virtual networks (including multiple sets of computing resources), content delivery networks (CDN), domain name services (DNS)), application resources (e.g., databases, application build / deployment services), access policies or roles, identity policies or roles, machine images, routers, and other data processing resources, etc. These and other computing resources may be provided as services, such as hardware virtualization services that can execute computing instances, storage services that can store data objects, etc. Users of Provider Network 100 (or “customers”) may utilize one or more user accounts associated with a customer account, but these items may be used somewhat interchangeably depending on the context of use. Users can interact with provider network 100 across one or more intermediate networks 106 (e.g., the Internet) through one or more interfaces, such as by using application programming interface (API) calls, or through a console implemented as a website or application. An API refers to an interface and / or communication protocol between a client and a server, such that if a client issues a request in a predefined format, the client should receive a response in a specific format or initiate a defined action. In the context of a cloud provider network, an API provides a gateway for customers to access cloud infrastructure by allowing customers to obtain data from or initiate actions within the cloud provider network, thereby enabling the development of applications that interact with resources and services hosted within the cloud provider network. APIs can also enable different services within the cloud provider network to exchange data with each other. One or more interfaces may be part of the control plane of provider network 100 or act as the front end of the control plane, which includes “back-end” services that support and implement services that can be provided more directly to customers.

[0016] For example, a cloud provider network (or simply "the cloud") typically refers to a large pool of accessible virtualized computing resources, such as compute, storage, and networking resources, applications, and services. The cloud provides convenient, on-demand network access to a shared pool of configurable computing resources that can be programmatically provisioned and deployed in response to client commands. These resources can be dynamically provisioned and reconfigured to suit variable loads. Therefore, cloud computing can be viewed as applications delivered as a service over a publicly accessible network (e.g., the Internet, cellular networks) and the hardware and software in the cloud provider's data centers that provide those services.

[0017] Cloud provider networks can be structured into multiple zones, where a zone is a geographical area in which the cloud provider clusters its data centers. Each zone comprises multiple (e.g., two or more) Availability Zones (AZs) interconnected by a dedicated high-speed network (e.g., fiber optic communication connection). An AZ (also called an availability area, or simply a "zone") provides an isolated fault area comprising one or more data center facilities that have separate power supplies, separate networking, and separate cooling relative to those data center facilities in another AZ. A data center refers to a physical building or rack that houses and provides power and cooling to the servers of the cloud provider's network. Preferably, AZs within a zone are far enough apart that a natural disaster (or other fault-inducing event) will not simultaneously affect or take down more than one AZ.

[0018] Customers can connect to the cloud provider's Availability Zones (AZs) via publicly accessible networks (e.g., the Internet, cellular networks), such as through a Switching Center (TC). The TC is the primary backbone location connecting customers to the cloud provider's network and can be co-located with other network provider facilities (e.g., Internet Service Providers, telecommunications providers) and securely connected (e.g., via VPN or direct connection) to the AZ. Two or more TCs can operate in each zone for redundancy. Zones are connected to a global network comprising dedicated networking infrastructure (e.g., fiber optic connections controlled by the cloud provider) that connects each zone to at least one other zone. The cloud provider's network delivers content from points of presence (or "POPs") outside but networked with these zones, via edge locations and zone edge caching servers. This partitioning and geographical distribution of computing hardware enables the cloud provider's network to provide customers with low-latency resource access globally with high fault tolerance and stability.

[0019] To provide these and other computing resource services, provider network 100 typically relies on virtualization technology. For example, virtualization technology can be used to provide users with the ability to control or utilize computing resources (e.g., “computing instances,” such as VMs using a guest operating system (O / S) that operate using a hypervisor that may or may not operate on top of the underlying host O / S, containers that may or may not operate within the VM, and computing instances that can execute on “bare metal” hardware without an underlying hypervisor), where one or more computing resources can be implemented using a single electronic device. Thus, users can directly utilize computing resources hosted by the provider network (e.g., provided by hardware virtualization services) to perform various computing tasks. Alternatively, users can indirectly utilize computing resources by submitting code executed by the provider network (e.g., via an on-demand code execution service), which in turn utilizes one or more computing resources to execute the code, typically without the user having any control or knowledge of the one or more underlying computing instances involved.

[0020] In various implementations, "serverless" functionality may include on-demand executable code provided by a user or other entity, such as the provider network itself. Serverless functionality may be maintained within provider network 100 by an on-demand code execution service (referred to in various implementations as a function computing service, function service, cloud function service, function-as-a-service, or serverless computing service) and may be associated with a specific user or account or generally accessible to multiple users / accounts. The on-demand code execution service enables customers of provider network 100 to execute their code on cloud resources without having to select or manage the underlying hardware resources used to execute the code. Serverless functionality may be associated with a Uniform Resource Locator (URL), Uniform Resource Identifier (URI), or other references that can be used to invoke serverless functionality. Serverless functionality may be executed by computing resources (such as virtual machines, containers, etc.) when triggered or invoked. In some implementations, serverless functionality may be invoked via application programming interface (API) calls or specially formatted Hypertext Transfer Protocol (HTTP) request messages. Therefore, users can define on-demand executable serverless functionality without requiring users to maintain dedicated infrastructure to execute serverless functionality. For example, a customer might be able to use the on-demand code execution service 116 by uploading their code and using one or more APIs to request the service to identify, provision, and manage any resources required to run the code. Thus, serverless functionality can be executed on demand using resources maintained by the provider network 100. In some implementations, these resources may be maintained in a “ready” state (e.g., with a pre-initialized runtime environment configured to execute serverless functionality), allowing for near real-time execution of serverless functionality.

[0021] like Figure 1As shown, at number 1, the user can access the intent-based governance service 102 through the electronic device 104. This can include accessing the intent-based governance service 102 through one or more application programming interfaces (APIs), consoles, or other user interfaces. For example, at number 1, the user can provide one or more intent statements 109 to the intent-based governance service 102 in a domain-specific language. Each intent statement expresses a governance policy (also referred to as a "fact") related to at least one intent. The domain-specific language can define multiple intents based on a model of the provider network 100 and its various services. Each intent can correspond to a type or category of action that can be performed on user resources by one or more services of the provider network 100. For example, a "share" intent can cover various actions that can be performed by a service, such as actions that grant access to user data or resources (e.g., allowing customer data to be exported to other accounts, providing access to customer data through a public endpoint, etc.). Thus, an intent statement related to the share intent can define who or under what conditions a resource can be shared. For example, the intent statement can include "<Resource X> cannot be shared" or "<Resource X> can be shared with <Y account>". In various embodiments, intents can be defined in domain-specific languages related to various domains, such as leak protection, zone management, software development kit (SDK) management, tagging standards and practices, access control, etc.

[0022] The intent-based governance service 102 converts the intent statements into policies and provides the user with feedback on how these policies can affect the user resources. For example, existing policies may conflict with one or more of the intent statements. For example, if the intent statement is that no resources should be shared outside the user organization, the intent-based governance service 102 can generate a policy and check the policy against the existing access patterns of the organization's resources. For example, at number 2, the intent-based governance service 102 can send requests to the automated reasoning service 114 and / or the resource access service 116 to determine if there are any conflicts with the new policy and the existing permissions. The automated reasoning service 114 can convert the policy into a mathematical representation and then use automated reasoning tools (such as a satisfiability modulo theory (SMT) solver) to analyze the representation of the policy to determine if a conflict has occurred. Similarly, the resource access service 116 can track how resources were previously accessed. For example, the resource access service 116 can track the last access information of customer resources and / or what resources are accessible, regardless of the time they were last accessed. In this way, the intent-based governance service 102 takes the domain of the intent into account (e.g., for the share intent, the current sharing activities can be checked, and for tagging, the current tagging rules can be checked, etc.).

[0023] Based on responses from the automated reasoning service 114 and / or the resource access service 116, the intent-based governance service 102 may return feedback 111 to the user at point 3. For example, if a new policy restricts access to resource 120 to region A 118, but resource access service 116 indicates regular access to one or more resources from region B 122 to region N 124, an alert indicating that the new policy is inconsistent with existing access patterns may be returned to the user. For example, if the intent relates to shared data, the intent-based governance service 102 may determine who is sharing data within the user's organization, who is currently allowed to share data, and the current state of data sharing (e.g., what is currently being shared). If any of this data conflicts with the intent (e.g., if the intent is to disallow sharing, but some data is currently being shared), this conflict may be identified to the user. The user may then confirm the new policy to be created based on the intent statement previously provided at point 1, or update the intent statement to allow some or all of the conflicts. For example, the intent statement may be updated to restrict access from regions outside of existing access patterns. Alternatively, at number 3, the user can be returned with a diagram illustrating how the new policy is mapped. For example, changes to an existing policy could be highlighted, or a new policy created for an additional service where a previous policy did not exist could be highlighted.

[0024] At number 4, once any discrepancies or conflicts have been resolved, the intent-based governance service 102 can generate a new policy 110 and / or monitor 112. In some implementations, monitor 112 may monitor for events that violate a user's intent statement and then present the event to the user, automatically respond to the event, etc. Additionally, at number 5, the new policy may be automatically attached to user resources 120. This may include resources across multiple regions, resources within a specific region, etc. In various implementations, the regions of provider network 100 may include districts, A / Z zones, or other portions of the provider network, which may correspond to geographic regions or other logical subdivisions of the provider network. In some implementations, the steps of the specific ordering described herein may alternatively be performed in any order.

[0025] Figure 2 This is a diagram illustrating an intent-based governance service according to some implementations. As discussed, the intent-based governance service 102 may include a user interface 108 through which intent statements can be received. Figure 2As shown, in some embodiments, the user interface 108 includes a console 200 that can receive intent statements and return feedback to the user based on a resulting strategy 110 generated from the intent statements. For example, when a user provides an intent statement in a domain-specific language, the intent statement is provided to a compiler 202, which compiles the intent statement into at least one strategy 110. In some embodiments, the compiler 202 compiles the intent statement received via the console 200 into a single strategy. Alternatively, the intent statement can be compiled into multiple strategies. One or more resulting strategies may be in the same format as conventionally generated strategies (e.g., JSON or a similar format).

[0026] These automatically compiled strategies 110 allow clients to have syntactically correct grammatical structures, ensuring that strategy variables conform to grammatical rules (e.g., have end tags), that the * character does not appear in services or union subjects, that the * character should not appear in any string compared to StringEquals or StringNotEquals, that the correct operators are applied to the appropriate operators, etc. The strategies also allow clients to share their data with the intended accounts and services without unintentionally exposing the strategies. In some implementations, compiler 200 generates appropriately formatted strategies and also determines the "attachment points" of said strategies. For example, a strategy concerning subjects in an organization only works when they are attached to the appropriate organization. Compiler 200 is also responsible for identifying the appropriate type of strategy to generate to achieve the intended result.

[0027] As discussed, the intent-based governance service 102 ensures that policies are implemented based on intent statements even when changes are made to provider network 100. Therefore, the intent-based governance service 102 may include one or more provider network event monitors 204. Provider network event monitors 204 may track the status of service updates, code updates, and other changes made to provider network 100 over time. These may result in an updated provider network model 212 that includes a description of the provider network, including the provider network's regions, the services offered by the provider network, and the actions that the services can perform. Model 212 is updated when new intents 210 are supported and / or when changes are made to the provider network or its services. For example, if a new region is added to the provider network, model 212 is updated to reflect this (e.g., updating the model's vocabulary with the name of the new region). Similarly, if a service is updated with a new feature, the model is updated to reflect the actions that the new feature can perform. This may include new APIs or changes to existing APIs. The updated model 212 provides types (e.g., services, regions, etc.) and terms (e.g., service names, region names, intents, etc.) of the domain-specific language 208.

[0028] Additionally, when a new provider network event is detected, update manager 206 can be triggered. Update manager 206 can cause intent statements to be recompiled by compiler 202. Given the updated provider network model 212 compiling intent statements, the updated provider network model provides updated policies that reflect changes in provider network 100. This automatically keeps the user's policies up-to-date with the current state of provider network 100, thereby ensuring that their intents take effect across new services and / or features when they are implemented, rather than requiring the user to keep up-to-date with the current state of provider network 100 or to react to actions that violate their intents after such actions have occurred.

[0029] Figure 3 This is a diagram illustrating an environment for automatically generating updated policies based on intent-based access control, according to some implementation schemes. As discussed, intent-based governance service 102 may include one or more provider network event monitors 204. At number 1, these monitors 204 may receive event data from one or more services 300 of provider network 100. In some implementations, provider network event monitors 204 may receive events from codebase analysis service 302, which performs static code analysis on the services of provider network 100. This allows for the identification of new features of these services before they go live. Once the new features go live, provider network model 212 can then be automatically updated. In some implementations, the provider network event monitor 204 may receive events from provider network status services 304, such as a region status service that tracks the status of provider network regions (e.g., when a new region is added to production and becomes available to customers of the provider network, or when an existing region is removed from production, merged with another existing or new region, etc.), an SDK status service that tracks the status of new SDKs (e.g., when they become available to customers, are removed from production, are updated, etc.), or other provider network status information. Based on the status of each region, the provider network model 212 may be updated.

[0030] For example, if Provider Network Status Service 304 indicates that a new region for Provider Network 100 has been launched in Europe, the governance policy may need to be updated to reflect this change in Provider Network Status. For instance, some customers may not intend to host any of their resources in any region located in Europe, while others may intend to host all or some of their resources in any region located in Europe. Previous solutions required customers to specifically list regions in their policies, requiring customers to know which regions are located in a particular geographic area and to stay updated on any regions added to or removed from that area to ensure their resources are hosted where they intend. For example, a customer's resources might be added to a new region in Europe because they did not specify an exclusion from that region when they wrote their policy (e.g., because the region did not exist when they wrote their policy). However, in various implementations, Provider Network Model 212 is updated based on events such as those generated when a new region is added. Therefore, if a new region is added to Europe, and a customer has an intent-based governance policy that excludes European regions from hosting their resources, the new region will also be automatically excluded when the intent-based governance policy is recompiled, even if the customer is unaware of its existence.

[0031] Once the provider network model 212 has been updated based on events received from services such as service 300, codebase analysis service 302, and region status service 304, the provider network event monitor 204 can invoke update manager 206 at digit 2 to generate updated policies and / or monitors. As discussed, update manager 206 can cause intent statements to be recompiled by compiler 202. Given the updated provider network model 212 compiling intent statements, the updated provider network model provides updated policies that reflect changes in provider network 100. This automatically keeps the user's policies updated to reflect the current state of provider network 100. In some implementations, update manager 206 may also request at digit 3 that the updated policies be analyzed by automated inference service 114 and / or resource access service 116 to identify any conflicts between the new policies and existing policies. At digit 4, feedback can be provided to the user. For example, if resource access service 116 or automated inference service 114 identifies any conflicts, the user can be alerted to the conflicts, and they can update their intent statements to address the conflicts. Alternatively, users may be provided with updates indicating implemented policy changes and alerting them to changes in their provider network. At number 5, the updated policy 306 and / or the updated monitor 308 may be associated with the appropriate subject.

[0032] Figure 4This is a diagram illustrating examples of intent expressions using a domain-specific language according to some implementations. As discussed, implementations use a domain-specific language (e.g., a computer language specifically designed for a particular domain) to define intents. In various implementations, this domain is the governing intent. Figure 4 As shown, exemplary intent statements 400 and 402 in a domain-specific language may include optional label 404, selectors 406 and 408, and intents 410 and 412. For example, intent statement 400 and intent statement 402 each represent an invariant. A single policy may include any number of invariants. Each intent statement may include a selector and one or more intents. In both examples, selectors 406 and 408 are 'services in "my-org"'. Logically, a selector represents the left-hand side of the implication (e.g., for all things, selector(thing) => intent(thing)). Therefore, in intent statement 400, a policy is created such that services in the organization "my-org" are only accessible in the regions indicated in ONLYINREGIONS ([region list]). In this example, the service is only accessible in the region named US-EAST-1. Similarly, intent statements can be structured such that services are only accessible in the European region. Therefore, if a new region is added to Europe, the policy will automatically update to allow access to the service from the new region. In intent statement 402, a tagging policy is created that tags resources based on the associated "cost centers" of all resources created for services in "my-org".

[0033] When an intent statement is received, it can be parsed. In some implementations, the syntax of the intent statement is specified as ANTLR syntax; however, alternative syntaxes may also be implemented. The parsed syntax is reduced to an abstract syntax tree of parsed names. In some implementations, a type checker can then identify the type associated with the intent statement, as follows:

[0034] The service in “my-org” is named {OnlyInRegions([us-east-1])}::invariant.

[0035] The service::selector<service> in "my-org"

[0036] Service::Selector<Service>

[0037] OnlyInRegions([us-east-1]):: Facts<Services>

[0038] OnlyInRegions::(List<Region>)->Facts<Service>

[0039] [us-east-1]::List<region>

[0040] us-east-1:: region

[0041] Once parsed, the intent statement can be compiled into a policy. As discussed, the compiler is responsible for properly formatting the policy and determining its attachment points.

[0042] Figure 5 This is a flowchart illustrating operation 500 of a method for intent-based access control according to some embodiments. Some or all of operation 500 (or other processes described herein, or variations thereof, and / or combinations thereof) is executed under the control of one or more computer systems configured with executable instructions, and is implemented as code (e.g., executable instructions, one or more computer programs, or one or more application programs) that commonly executes on one or more processors, implemented by hardware, or implemented by a combination thereof. The code is stored on a computer-readable storage medium, for example, in the form of a computer program including instructions executable by one or more processors. The computer-readable storage medium is non-transitory. In some embodiments, one or more (or all) of operation 500 is executed by intent-based governance service 102 as shown in other figures.

[0043] Operation 500 includes, at block 502, receiving one or more intent statements associated with a user resource in the provider network through a user interface of an intent-based governance service, the one or more intent statements expressing at least one type of action permitted to be performed on the user resource. In some embodiments, the intent statements are written in a domain-specific language.

[0044] Operation 500 further includes, at block 504, compiling one or more intent statements into at least one access control policy. In some implementations, intent statements are parsed and type-checked before compilation to identify the intent of the statement and the resource to which the intent is to be applied.

[0045] Operation 500 further includes, at block 506, associating at least one access control policy with a user resource. In some implementations, the compiler may identify the resource or subject to which at least one access control policy is to be applied and automatically attach the resulting at least one access control policy to said resource or said subject.

[0046] In some implementations, the operation further includes: sending a request to a resource activity service to compare at least one access control policy with the activity history associated with the user resource, and receiving an instruction from the at least one access control policy to restrict recent activity associated with the user resource. For example, the resource activity service may maintain the access history of the user resource. If the new policy conflicts with an existing access pattern (e.g., restricting recent access), the access pattern may be presented to the user to determine how to resolve the conflict. For example, the existing access pattern may be retained, but further access may be disallowed in the future, or all access may be restricted according to the new policy. For example, in some implementations, the operation further includes: returning a message indicating recent activity to be restricted by at least one access control policy through a user interface of an intent-based governance service; receiving at least one updated intent statement; and compiling the at least one updated intent statement into at least one updated access control policy. The updated access control policy may take into account changes made by the user to the intent in the updated intent statement.

[0047] In some embodiments, the operation further includes receiving an event from the provider network's service indicating at least one change in the provider network. As discussed, an intent-based governance service can keep abreast of policy updates as changes are made to the provider network's service or the provider network itself. Therefore, such changes can be monitored by the intent-based governance service. In some embodiments, the operation further includes updating the provider network's model based on the at least one change. In some embodiments, the operation further includes recompiling the one or more intent statements using the updated model to generate at least one updated access control policy applicable to the at least one change in the provider network. In some embodiments, the provider network's service is a static code analysis service, and the at least one change is a new feature identified by static code analysis of a second service of the provider network. In some embodiments, the provider network's service is a region status service, and the at least one change is a new region coming online for the provider network.

[0048] In some implementations, the operation includes: receiving from a client one or more intent statements written in a domain-specific language, the one or more intent statements expressing a security intent toward a client resource, through a user interface of an intent-based governance service of the provider network; parsing the one or more intent statements based on a provider network model; compiling the parsed one or more intent statements into at least one access control policy; associating the at least one access control policy with the client resource based on the one or more intent statements; detecting changes to the provider network based on static code analysis of one or more services of the provider network; updating the provider network model based on the changes to the provider network; and recompiling the parsed one or more intent statements into an updated at least one access control policy, the updated at least one access control policy being applied to at least one or more changed services of the provider network.

[0049] In some implementations, the security intent includes restricting access to customer resources from one or more zones of the provider network. In some implementations, the security intent includes restricting the sharing of customer resources to the customer's organization.

[0050] Figure 6 An exemplary provider network (or “service provider system”) environment according to some implementations is illustrated. Provider network 600 may provide resource virtualization to customers through one or more virtualization services 610, which allow customers to purchase, lease, or otherwise obtain instances 612 of virtualized resources (including, but not limited to, computing and storage resources) implemented on devices within one or more provider networks in one or more data centers. A local Internet Protocol (IP) address 616 may be associated with resource instance 612; the local IP address is the internal network address of resource instance 612 on provider network 600. In some implementations, provider network 600 may also provide public IP addresses 614 and / or ranges of public IP addresses (e.g., Internet Protocol version 4 (IPv4) or Internet Protocol version 6 (IPv6) addresses) available to customers from provider 600.

[0051] Typically, provider network 600 can use virtualization service 610 to allow service provider customers (e.g., customers of one or more client networks 650A to 650C whose operations include one or more customer devices 652) to dynamically associate at least some public IP addresses 614 assigned to the customer with specific resource instances 612 assigned to the customer. Provider network 600 can also allow customers to remap public IP addresses 614 previously mapped to one virtualized computing resource instance 612 assigned to the customer to another virtualized computing resource instance 612 also assigned to the customer. Using the virtualized computing resource instances 612 and public IP addresses 614 provided by the service provider, service provider customers, such as operators of customer networks 650A to 650C, can, for example, implement customer-specific applications and present the customer's applications on an intermediate network 640, such as the Internet. Then, other network entities 620 on the intermediate network 640 can generate traffic to a destination public IP address 614 published by one or more customer networks 650A to 650C; this traffic is routed to the service provider's data center and, at the data center, routed through the network layer to the local IP address 616 of the virtualized computing resource instance 612, which is currently mapped to the destination public IP address 614. Similarly, response traffic from the virtualized computing resource instance 612 can be routed back to the source entity 620 on the intermediate network 640 through the network layer.

[0052] As used herein, a local IP address refers to an internal or “private” network address of a resource instance within, for example, a provider network. Local IP addresses may be within an address block reserved by the Internet Engineering Task Force (IETF) Request for Comments (RFC) 1918 and / or have an address format specified by IETF RFC 4193 and may be changed within the provider network. Network traffic originating outside the provider network is not directly routed to a local IP address; instead, traffic uses a public IP address mapped to the local IP address of the resource instance. Provider networks may include networking devices or appliances that provide Network Address Translation (NAT) or similar functionality to perform mappings from public IP addresses to local IP addresses, and vice versa.

[0053] A public IP address is a variable network address on the Internet assigned to a resource instance by a service provider or by a customer. Traffic routed to a public IP address is translated, for example, through 1:1 NAT and forwarded to the corresponding local IP address of the resource instance.

[0054] Some public IP addresses may be assigned to specific resource instances by the provider's network infrastructure; these public IP addresses may be referred to as standard public IP addresses, or simply standard IP addresses. In some implementations, the mapping of standard IP addresses to the local IP addresses of resource instances is the default startup configuration for all resource instance types.

[0055] At least some public IP addresses may be assigned to or obtained by customers of Provider Network 600; customers may then assign their assigned public IP addresses to specific resource instances assigned to them. These public IP addresses may be referred to as customer public IP addresses, or simply customer IP addresses. Instead of being assigned to resource instances by Provider Network 600 as in the case of standard IP addresses, customer IP addresses may be assigned to resource instances by the customer, for example, through an API provided by the service provider. Unlike standard IP addresses, customer IP addresses are assigned to customer accounts and may be remapped to other resource instances by the respective customer as needed or desired. Customer IP addresses are associated with customer accounts, not with specific resource instances, and the customer controls the IP address until the customer chooses to release it. Unlike regular static IP addresses, customer IP addresses allow customers to mask resource instance or availability zone failures by remapping their public IP addresses to any resource instance associated with their customer account. For example, customer IP addresses enable customers to resolve customer resource instance or software issues by remapping their customer IP addresses to alternative resource instances.

[0056] Figure 7 This is a block diagram of an exemplary provider network providing storage services and hardware virtualization services to customers according to some implementation schemes. Hardware virtualization service 720 provides customers with multiple computing resources 724 (e.g., computing instances 725 such as VMs). For example, computing resources 724 may be leased or rented to customers of provider network 700 (e.g., customers implementing customer network 750). Each computing resource 724 may have one or more local IP addresses. Provider network 700 may be configured to route packets from the local IP addresses of computing resources 724 to public internet destinations, and from public internet sources to the local IP addresses of computing resources 724.

[0057] Provider network 700 may provide a client network 750, coupled to intermediate network 740 via local network 756, with the ability to implement virtual computing systems 792 through hardware virtualization service 720 coupled to intermediate network 740 and provider network 700. In some embodiments, hardware virtualization service 720 may provide one or more APIs 702 (e.g., web service interfaces) through which client network 750 may access functionality provided by hardware virtualization service 720, for example, through console 794 (e.g., web-based applications, standalone applications, mobile applications, etc.). In some embodiments, each virtual computing system 792 at provider network 700 and client network 750 may correspond to computing resources 724 that are leased, rented, or otherwise provided to client network 750.

[0058] Customers can access the functionality of storage service 710 from an instance of virtual computing system 792 and / or another customer device 790 (e.g., via console 794) through one or more APIs 702, for example, to access data from and store data in storage resources 718A to 718N of virtual data storage areas 716 (e.g., folders or "buckets", virtualized volumes, databases, etc.) provided by provider network 700. In some embodiments, a virtualized data storage gateway (not shown) may be provided at customer network 750, which may locally cache at least some data (e.g., frequently accessed or critical data) and communicate with storage service 710 via one or more communication channels to upload new or modified data from the local cache, thereby maintaining the primary storage area (virtualized data storage area 716) for data maintenance. In some embodiments, users can install and access virtual data storage area 716 volumes via storage service 710, which acts as a storage virtualization service, through virtual computing system 792 and / or on another customer device 790, and these volumes may appear to the user as local (virtualized) storage devices 798.

[0059] Although Figure 7 Not shown, but one or more virtualization services can also be accessed from resource instances within provider network 700 via one or more APIs 702. For example, a customer, device service provider, or other entity can access virtualization services from within a corresponding virtual network on provider network 700 via API 702 to request the allocation of one or more resource instances within the virtual network or another virtual network.

[0060] Explanatory System

[0061] In some implementations, a system that implements some or all of the techniques described herein may include a general-purpose computer system (such as...) Figure 8 The illustrated computer system 800 includes or is configured to access one or more computer-accessible media. In the illustrated embodiment, the computer system 800 includes one or more processors 810 coupled to system memory 820 via an input / output (I / O) interface 830. The computer system 800 also includes a network interface 840 coupled to the I / O interface 830. Although Figure 8 The computer system 800 is shown as a single computing device, but in various embodiments, the computer system 800 may include a single computing device or any number of computing devices configured to work together as a single computer system 800.

[0062] In various embodiments, computer system 800 may be a single-processor system including one processor 810 or a multiprocessor system including several processors 810 (e.g., two, four, eight, or another suitable number). Processor 810 may be any suitable processor capable of executing instructions. For example, in various embodiments, processor 810 may be a general-purpose or embedded processor implementing any of a variety of instruction set architectures (ISAs), such as x86, ARM, PowerPC, SPARC, or MIPS ISA or any other suitable ISA. In a multiprocessor system, each of processors 810 may typically (but not necessarily) implement the same ISA.

[0063] System memory 820 may store instructions and data accessible by one or more processors 810. In various embodiments, system memory 820 may be implemented using any suitable memory technology, such as random access memory (RAM), static RAM (SRAM), synchronous dynamic RAM (SDRAM), non-volatile / flash memory, or any other type of memory. In the illustrated embodiment, program instructions and data (such as the methods, techniques, and data described above) implementing one or more desired functions are shown stored in system memory 820 as intent-based governance service code 825 (e.g., executable to fully or partially implement intent-based governance service 102) and data 826.

[0064] In one embodiment, I / O interface 830 may be configured to coordinate I / O traffic between processor 810, system memory 820, and any peripheral devices (including network interface 840 or other peripheral interfaces) within the device. In some embodiments, I / O interface 830 may perform any necessary protocol, timing, or other data transformations to convert data signals from one component (e.g., system memory 820) into a format suitable for use by another component (e.g., processor 810). In some embodiments, I / O interface 830 may include support for devices attached via various types of peripheral buses (e.g., variations of the Peripheral Component Interconnect (PCI) bus standard or the Universal Serial Bus (USB) standard). In some embodiments, the functionality of I / O interface 830 may be split into two or more separate components, such as a northbridge and a southbridge. Furthermore, in some embodiments, some or all of the functionality of I / O interface 830 (such as an interface to system memory 820) may be directly incorporated into processor 810.

[0065] Network interface 840 can be configured to allow communication between computer system 800 and other devices 860 attached to one or more networks 850 (e.g., such as...). Figure 1The network interface 840 can exchange data with other computer systems or devices shown. In various implementations, for example, the network interface 840 may support communication over any suitable wired or wireless general-purpose data network (e.g., a network type such as Ethernet). Additionally, the network interface 840 may support communication over telecommunications / telephone networks (such as analog voice networks or digital fiber optic communication networks), over storage area networks (SANs) (such as Fibre Channel SANs), or over any other suitable type of network and / or protocol via I / O.

[0066] In some embodiments, the computer system 800 includes one or more offload cards 870A or 870B (including one or more processors 875 and may include one or more network interfaces 840), which are connected using I / O interfaces 830 (e.g., a version of the Peripheral Component Interconnect Fast (PCI-E) standard or another interconnect bus such as Fast Path Interconnect (QPI) or Hyper Path Interconnect (UPI). For example, in some embodiments, the computer system 800 may act as a host electronic device hosting computing resources (such as compute instances) (e.g., operating as part of a hardware virtualization service), and the one or more offload cards 870A or 870B act as a virtualization manager that manages the compute instances running on the host electronic device. As an example, in some embodiments, the one or more offload cards 870A or 870B may perform compute instance management operations, such as pausing and / or unpausing compute instances, starting and / or terminating compute instances, performing memory transfer / copy operations, etc. In some implementations, these management operations may be performed by one or more offload cards 870A or 870B in cooperation with a hypervisor (e.g., upon request from the hypervisor) executed by other processors 810A to 810N of the computer system 800. However, in some implementations, the virtualization manager implemented by one or more offload cards 870A or 870B may accommodate requests from other entities (e.g., from the computing instance itself) and may not cooperate with (or serve) any single hypervisor.

[0067] In some embodiments, system memory 820 may be an embodiment of a computer-accessible medium configured to store program instructions and data as described above. However, in other embodiments, program instructions and / or data may be received, transmitted, or stored on different types of computer-accessible media. Generally, computer-accessible media may include non-transitory storage media or memory media, such as magnetic or optical media, for example, a disk or DVD / CD coupled to computer system 800 via I / O interface 830. Non-transitory computer-accessible storage media may also include any volatile or non-volatile media, such as RAM (e.g., SDRAM, Double Data Rate (DDR) SDRAM, SRAM, etc.), read-only memory (ROM), etc., which may be included as system memory 820 or another type of memory in some embodiments of computer system 800. Furthermore, computer-accessible media may include transmission media or signals, such as electrical signals, electromagnetic signals, or digital signals, conveyed via communication media such as networks and / or wireless links (e.g., achievable via network interface 840).

[0068] The various implementations discussed or proposed herein can be implemented in a wide variety of operating environments, in some cases of which may include one or more user computers, computing devices, or processing devices that can be used to operate any of a number of applications. User or client devices may include any of many general-purpose personal computers, such as desktop or laptop computers running standard operating systems; and cellular, wireless, and handheld devices running mobile software and capable of supporting many networking and messaging protocols. Such systems may also include a number of workstations running a variety of commercially available operating systems and any of other known applications for purposes such as development and database management. These devices may also include other electronic devices, such as virtual terminals, thin clients, gaming systems, and / or other devices capable of communicating over a network.

[0069] Most implementations utilize at least one network familiar to those skilled in the art to support communication using any of a variety of widely available protocols, such as Transmission Control Protocol / Internet Protocol (TCP / IP), File Transfer Protocol (FTP), Universal Plug and Play (UPnP), Network File System (NFS), Public Internet File System (CIFS), Extensible Messaging and Presence Protocol (XMPP), AppleTalk, etc. The one or more networks may include, for example, a Local Area Network (LAN), a Wide Area Network (WAN), a Virtual Private Network (VPN), the Internet, an intranet, an extranet, a Public Switched Telephone Network (PSTN), an infrared network, a wireless network, and any combination thereof.

[0070] In implementations utilizing a web server, the web server can run any of a variety of server or middleware applications, including HTTP servers, File Transfer Protocol (FTP) servers, Common Gateway Interface (CGI) servers, data servers, Java servers, traffic application servers, etc. The one or more servers may also be able to respond to requests from user devices (such as requests implemented in any programming language such as...). One or more web applications may execute programs or scripts written in C, C#, or C++, or any scripting language such as Perl, Python, PHP, or TCL, or combinations thereof. One or more servers may also include database servers, including but not limited to commercially available database servers from Oracle(R), Microsoft(R), Sybase(R), IBM(R), etc. Database servers may be relational or non-relational (e.g., "NoSQL"), distributed or non-distributed, etc.

[0071] The environment disclosed herein may include various data storage areas and other memories and storage media as discussed above. These may reside in various locations, such as on storage media local to (and / or residing in) one or more computers, or on storage media located across a network away from any or all of the computers. In a particular set of embodiments, information may reside in a Storage Area Network (SAN) familiar to those skilled in the art. Similarly, any necessary files for performing functions belonging to a computer, server, or other network device may be stored locally and / or remotely, depending on the circumstances. Where the system includes computerized devices, each such device may include hardware elements electrically coupled via a bus, including, for example, at least one central processing unit (CPU), at least one input device (e.g., mouse, keyboard, controller, touchscreen, or keypad), and / or at least one output device (e.g., display device, printer, or speaker). Such a system may also include one or more storage devices, such as hard disk drives, optical storage devices, and solid-state storage devices such as random access memory (RAM) or read-only memory (ROM), as well as removable media devices, memory cards, flash memory cards, etc.

[0072] Such devices may also include computer-readable storage medium readers, communication devices (e.g., modems, network interface cards (wireless or wired), infrared communication devices, etc.), and working memory, as described above. A computer-readable storage medium reader may be connected to or configured to receive computer-readable storage media, which represents remote, local, fixed, and / or removable storage devices, as well as storage media for temporarily and / or more permanently containing, storing, transmitting, and retrieving computer-readable information. Systems and various devices will also typically include multiple software applications, modules, services, or other elements residing within at least one working memory device, including operating systems and applications such as client applications or web browsers. It should be understood that alternative embodiments may have numerous variations different from those described above. For example, custom hardware may also be used, and / or specific elements may be implemented in hardware, software (including portable software such as applets), or both. Furthermore, connectivity to other computing devices, such as network input / output devices, may be employed.

[0073] Storage media and computer-readable media used to contain code or portions of code may include any suitable media known or used in the art, including storage media and communication media, such as, but not limited to, volatile and non-volatile, removable and non-removable media implemented in any method or technology for storing and / or transmitting information (such as computer-readable instructions, data structures, program modules or other data), including RAM, ROM, electrically erasable programmable read-only memory (EEPROM), flash memory or other memory technologies, read-only optical disc memory (CD-ROM), digital versatile optical disc (DVD) or other optical storage devices, magnetic cartridges, magnetic tapes, disk storage devices or other magnetic storage devices, or any other media that can be used to store desired information and is accessible by system devices. Based on the disclosure and teachings provided herein, those skilled in the art will understand other ways and / or methods for implementing the various embodiments.

[0074] Various implementation schemes have been described above. Specific configurations and details have been set forth for illustrative purposes to provide a thorough understanding of the implementation schemes. However, it will also be apparent to those skilled in the art that the described implementation schemes can be practiced without specific details. Furthermore, well-known features may have been omitted or simplified to avoid obscuring the described implementation schemes.

[0075] In this document, bracketed text and boxes with dashed borders (e.g., large dashes, small dashes, dot dashes, and dots) are used to illustrate optional operations for adding additional features to some embodiments. However, this notation should not be construed as implying that these are the only options or optional operations, and / or that in some embodiments, boxes with solid borders are not optional.

[0076] In various embodiments, reference numerals with suffix letters (e.g., 718A to 718N) can be used to indicate one or more instances of the referenced entity, and when multiple instances exist, each instance need not be identical, but may instead share some general characteristics or act as is customary. Furthermore, unless explicitly stated to the contrary, the use of a particular suffix does not imply the existence of a specific number of entities. Therefore, in various embodiments, two entities using the same or different suffix letters may or may not have the same number of instances.

[0077] References to "an implementation," "implementation," "exemplary implementation," etc., indicate that the described implementation may include a particular feature, structure, or characteristic, but each implementation need not necessarily include that particular feature, structure, or characteristic. Furthermore, such phrases do not necessarily refer to the same implementation. Additionally, when a particular feature, structure, or characteristic is described in connection with an implementation, it should be understood that, whether explicitly described or not, implementing such a feature, structure, or characteristic in conjunction with other implementations is also within the knowledge of those skilled in the art.

[0078] Furthermore, in the various embodiments described above, unless otherwise specifically indicated, disjunctive language such as the phrase “at least one of A, B, or C” is intended to mean A, B, or C or any combination thereof (e.g., A, B, and / or C). Therefore, disjunctive language is generally not intended and should not be construed as implying that a given embodiment requires at least one A, at least one B, or at least one C to each be present.

[0079] Unless otherwise expressly stated, articles such as “a” or “an” should generally be understood to include one or more of the described items. Therefore, phrases such as “device configured to…” are intended to include one or more of the stated devices. Such one or more of the stated devices may also be collectively configured to perform the stated narrative. For example, “processor configured to perform narratives A, B, and C” may include a first processor configured to perform narrative A, which works in conjunction with a second processor configured to perform narratives B and C.

[0080] At least some embodiments of the disclosed technology can be described according to the following terms:

[0081] 1. A computer-implemented method, comprising:

[0082] The user interface of the provider network’s intent-based governance service receives one or more intent statements written in a domain-specific language from the client, the one or more intent statements expressing a security intent toward the client’s resources;

[0083] The one or more intent statements are parsed based on a provider network model;

[0084] Compile the parsed intent statements into at least one access control policy;

[0085] Associating the at least one access control policy with the customer resource based on the one or more intent statements;

[0086] Changes in the provider network are detected based on static code analysis of one or more services of the provider network;

[0087] Update the provider network model based on the changes in the provider network; and

[0088] The parsed intent statements are recompiled into at least one updated access control policy, which is applied to at least one or more modified services of the provider network.

[0089] 2. The computer implementation method as described in Clause 1, wherein the security intent includes restricting access to the customer resources from one or more zones of the provider network.

[0090] 3. A computer-implemented method as described in any one of Clauses 1-2, wherein the security intent includes restricting the sharing of the client resources to the client's organization.

[0091] 4. A computer-implemented method, comprising:

[0092] The user interface of the intent-based governance service receives one or more intent statements associated with a user resource in the provider network, the one or more intent statements expressing at least one type of action that is permitted to be performed on the user resource;

[0093] Compile the one or more intent statements into at least one access control policy; and

[0094] Associate the at least one access control policy with the user resource.

[0095] 5. The computer-implemented method as described in Clause 4, wherein each of the one or more intent statements is expressed in a domain-specific language and describes a governance strategy for at least one intent defined by the domain-specific language.

[0096] 6. The computer-implemented method as described in any one of Clauses 4-5, further comprising:

[0097] Send a request to the resource activity service to compare the at least one access control policy with the activity history associated with the user resource; and

[0098] Receive a response indicating that at least one access control policy will restrict recent activities associated with the user resource.

[0099] 7. The computer-implemented method as described in any one of Clauses 4-6, further comprising:

[0100] The user interface of the intent-based governance service returns a message indicating that the recent activity will be restricted by the at least one access control policy;

[0101] Receive at least one updated intent statement; and

[0102] The at least one updated intent statement is compiled into at least one updated access control policy.

[0103] 8. The computer-implemented method as described in any one of Clauses 4-7, further comprising:

[0104] Receive an event from the service of the provider network that indicates at least one change in the provider network.

[0105] 9. The computer-implemented method as described in Clause 7, further comprising:

[0106] The provider network model is updated based on at least one of the aforementioned changes.

[0107] 10. The computer-implemented method as described in Clause 8, further comprising:

[0108] The one or more intent statements are recompiled using the updated model to generate at least one updated access control policy, which applies to the at least one change in the provider network.

[0109] 11. The computer-implemented method as described in Clause 7, wherein the service of the provider network is a static code analysis service, and wherein the at least one variation is a new feature identified based on static code analysis of a second service of the provider network.

[0110] 12. The computer-implemented method as described in Clause 7, wherein the service of the provider network is a regional status service, and wherein the at least one change is a new regional online of the provider network.

[0111] 13. A system comprising:

[0112] One or more first electronic devices, said one or more first electronic devices being used to implement user resources in a multi-tenant provider network; and

[0113] One or more second electronic devices are configured to implement an intent-based governance service in the multi-tenant provider network, the intent-based governance service including instructions that, upon execution, cause the intent-based governance service to:

[0114] The user interface of the intent-based governance service receives one or more intent statements associated with the user resource, the one or more intent statements expressing at least one type of action that is permitted to be performed on the user resource;

[0115] Compile the one or more intent statements into at least one access control policy; and

[0116] Associate the at least one access control policy with the user resource.

[0117] 14. The system as described in Clause 13, wherein the instructions, upon execution, further enable the intent-based governance service:

[0118] Send a request to the resource activity service to compare the at least one access control policy with the activity history associated with the user resource; and

[0119] Receive a response indicating that at least one access control policy will restrict recent activities associated with the user resource.

[0120] 15. The system as described in any one of Clauses 13-14, wherein the instructions, upon execution, further enable the intent-based governance service:

[0121] The user interface of the intent-based governance service returns a message indicating that the recent activity will be restricted by the at least one access control policy;

[0122] Receive at least one updated intent statement; and

[0123] The at least one updated intent statement is compiled into at least one updated access control policy.

[0124] 16. The system of any one of Clauses 13-15, wherein the instructions, when executed, further enable the intent-based governance service:

[0125] Receive an event from the service of the provider network that indicates at least one change in the provider network.

[0126] 17. The system as described in Clause 16, wherein the instructions, upon execution, further enable the intent-based governance service:

[0127] The provider network model is updated based on at least one of the aforementioned changes.

[0128] 18. The system as described in Clause 17, wherein the instructions, upon execution, further enable the intent-based governance service:

[0129] The one or more intent statements are recompiled using the updated model to generate at least one updated access control policy, which applies to the at least one change in the provider network.

[0130] 19. The system as described in Clause 16, wherein the service of the provider network is a static code analysis service, and wherein the at least one change is a new feature identified by static code analysis based on a second service of the provider network.

[0131] 20. The system as described in Clause 16, wherein the service of the provider network is a regional status service, and wherein the at least one change is a new regional online of the provider network.

[0132] Therefore, the specification and drawings are to be considered illustrative rather than restrictive. However, it will be apparent that various modifications and changes may be made therein without departing from the broader spirit and scope of this disclosure as set forth in the appended claims.

Claims

1. A computer-implemented method, comprising: At the intent-based governance service in the provider network, one or more intent statements written in a domain-specific language from the client, expressing a security intent toward client computing resources hosted by the provider network, are received via the user interface of the intent-based governance service of the provider network. The one or more intent statements are parsed based on the provider network model to generate one or more parsed intent statements; The parsed one or more intent statements are compiled into at least one access control policy; Based on the parsed one or more intent statements, the at least one access control policy is associated with the client computing resource; Changes in the provider network are detected based on static code analysis of one or more services of the provider network; Update the provider network model based on the changes in the provider network; as well as The update manager of the intent-based governance service recompiles the parsed one or more intent statements into an updated access control policy, which is applied to at least one or more modified services of the provider network.

2. The computer-implemented method as described in claim 1, wherein, The security intent regarding the customer's computing resources includes restricting access to the customer's computing resources from one or more areas of the provider's network.

3. The computer-implemented method as described in claim 1, wherein, The security intent regarding the client's computing resources includes restricting the sharing of the client's computing resources to the client's organization.

4. A computer-implemented method, comprising: At the intent-based governance service in the provider network, one or more intent statements written in a domain-specific language, originating from a user and associated with a user computing resource hosted by the provider network, are received via the user interface of the intent-based governance service. The one or more intent statements express at least one type of action that is permitted to be performed on the user computing resource. The one or more intent statements are parsed based on the provider network model to generate one or more parsed intent statements; The parsed one or more intent statements are compiled into at least one access control policy; Based on the parsed one or more intent statements, the at least one access control policy is associated with the user's computing resources; The intent-based governance service receives event data from services of the provider network at its network event monitor. The event data indicates at least one change in the provider network, which is detected based on static code analysis of one or more services of the provider network. The provider network model is updated based on at least one change in the provider network to generate an updated model; as well as The update manager of the intent-based governance service uses the updated model to recompile the parsed one or more intent statements, thereby generating at least one updated access control policy with at least one change applied to the provider network.

5. The computer-implemented method as described in claim 4, further comprising: Send a request to at least one of the automated reasoning service or resource access service to determine whether there is any conflict with the at least one access control policy and one or more existing permissions or access patterns; Based on one or more responses from at least one of the automated reasoning service or the resource access service, feedback on the parsed one or more intent statements is returned via the user interface; as well as The user interface receives confirmation of the parsed one or more intent statements.

6. The computer-implemented method as described in claim 5, wherein, Determining whether there are any conflicts with the at least one access control policy and the one or more existing permissions or access patterns includes: The automated reasoning service transforms the at least one access control policy into at least one mathematical representation; and The automated reasoning service uses automated reasoning tools to analyze the at least one mathematical representation of the at least one access control policy to determine whether any conflict has occurred.

7. The computer-implemented method of claim 4, further comprising: Send a request to the resource activity service to compare the at least one access control policy with the activity history associated with the user's computing resource; as well as Receive a response indicating that at least one access control policy will restrict recent activities associated with the user's computing resources.

8. The computer-implemented method of claim 7, further comprising: A message is returned via the user interface of the intent-based governance service, indicating the recent activity that is restricted by the at least one access control policy; Receive at least one updated intent statement; as well as The at least one updated intent statement is compiled into at least one updated access control policy.

9. The computer-implemented method as described in claim 8, wherein, The at least one type of action permitted to be performed on the user computing resources relates to: restricting access to the user computing resources from one or more areas of the provider network.

10. The computer-implemented method as described in claim 4, wherein, The at least one type of action permitted to be performed on the user computing resources relates to: sharing the user computing resources with the customer's organization.

11. The computer-implemented method as described in claim 4, wherein, The service of the provider network is a static code analysis service, and the at least one change is a new feature of the second service of the provider network identified based on static code analysis.

12. The computer-implemented method as described in claim 4, wherein, The service provided by the provider network is a regional status service, and the at least one change is the launch of a new region of the provider network.

13. A system comprising: First or more electronic devices host user computing resources in a multi-tenant provider network, the user computing resources including one or more first processors and including a first memory; as well as A second or more electronic devices implement an intent-based governance service in the multi-tenant provider network, the intent-based governance service including one or more second processors and including a second memory, the second memory storing instructions that, when executed by the one or more second processors, enable the intent-based governance service to: The user interface of the intent-based governance service receives one or more intent statements written in a domain-specific language, originating from the user and associated with the user's computing resources hosted by the provider network, the one or more intent statements expressing at least one type of action permitted to be performed on the user's computing resources; The one or more intent statements are parsed based on the provider network model to generate one or more parsed intent statements; The parsed one or more intent statements are compiled into at least one access control policy; Based on the parsed one or more intent statements, the at least one access control policy is associated with the user's computing resources; The intent-based governance service receives event data from services of the provider network at its network event monitor. The event data indicates at least one change in the provider network, which is detected based on static code analysis of one or more services of the provider network. The provider network model is updated based on at least one change in the provider network to generate an updated model; as well as The update manager of the intent-based governance service uses the updated model to recompile the parsed one or more intent statements, thereby generating at least one updated access control policy with at least one change applied to the provider network.

14. The system of claim 13, wherein, When the instruction is executed, it further enables the intent-based governance service: Send a request to the resource activity service to compare the at least one access control policy with the activity history associated with the user's computing resource; as well as Receive a response indicating that at least one access control policy will restrict recent activities associated with the user's computing resources.

15. The system of claim 14, wherein, When the instruction is executed, it further enables the intent-based governance service: A message is returned via the user interface of the intent-based governance service, indicating the recent activity that is restricted by the at least one access control policy; Receive at least one updated intent statement; as well as The at least one updated intent statement is compiled into at least one updated access control policy.

16. The system of claim 13, wherein, When the instruction is executed, it further enables the intent-based governance service: Send a request to at least one of the automated reasoning service or resource access service to determine whether there is any conflict with the at least one access control policy and one or more existing permissions or access patterns; Based on one or more responses from at least one of the automated reasoning service or the resource access service, feedback on the parsed one or more intent statements is returned via the user interface; as well as The user interface receives confirmation of the parsed one or more intent statements.

17. The system of claim 13, wherein, The at least one type of action permitted to be performed on the user computing resources relates to: restricting access to the user computing resources from one or more areas of the provider network.

18. The system of claim 17, wherein, The at least one type of action permitted to be performed on the user computing resources relates to: sharing the user computing resources with the customer's organization.

19. The system of claim 13, wherein, When the instruction is executed, the intent-based governance service further causes the service to receive an event from a service of the provider network, the event indicating at least one change in the provider network, wherein the service of the provider network is a static code analysis service, and wherein the at least one change is a new feature of a second service of the provider network identified based on static code analysis.

20. The system of claim 13, wherein, When the instruction is executed, the intent-based governance service further causes the service to receive an event from the provider network's service, the event indicating at least one change in the provider network, wherein the provider network's service is a region status service, and wherein the at least one change is a new region coming online in the provider network.

Images