Security configuration of cloud computing nodes

Abstract

Methods and systems are described for configuring nodes in a cloud computing network. One example method includes receiving, over a network, a configuration request from a particular node in the cloud computing network, the configuration request including node information for the particular node; verifying, based at least in part on the node information, that the particular node is authorized to configure; responsive to verifying that the particular node is authorized to configure, identifying, based at least in part on the node information, configuration actions to be performed on the particular node; and sending, over the network, configuration commands corresponding to one or more of the identified configuration actions to the particular node, where the particular node, upon receiving the configuration commands, performs the corresponding configuration actions.

Description

[0001] This application is a divisional application of patent application filed on June 16, 2016, with application number 201680088451.2 (PCT / US2016 / 037786) and entitled "Security Configuration of Cloud Computing Nodes". Background Technology

[0002] This manual generally relates to the secure configuration of nodes in a cloud computing system.

[0003] In cloud computing networks, multiple computing devices can be connected via a network and perform computing tasks collaboratively and / or in parallel. Large-scale distributed systems can include hundreds or even thousands of individual computing devices. Computing devices can be homogeneous (sharing the same configuration) or heterogeneous (having various configurations). Computing devices can further host virtual environments, which allow multiple computing nodes (e.g., virtual machine instances, container instances) to be hosted on a single physical computing device. Summary of the Invention

[0004] Typically, one aspect of the subject matter described in this specification can be implemented in a system and a method performed by a data processing apparatus, the method comprising the actions of receiving a configuration request via a network from a specific node in a cloud computing network, the configuration request including node information of the specific node; verifying that the specific node is authorized for configuration based at least in part on the node information; in response to verifying that the specific node is authorized for configuration, identifying a configuration action to be performed on the specific node based at least in part on the node information; and sending a configuration command via the network to the specific node corresponding to one or more of the identified configuration actions, wherein the specific node executes the configuration command upon receiving it to perform the corresponding configuration action.

[0005] Typically, an innovative aspect of the subject matter described in this specification can be implemented in a method that includes controlling software deployment by a configuration controller, wherein software is deployed to nodes in a cloud computing environment by a configuration manager from a set of configuration managers. One such method includes a node requesting the configuration controller to configure the node; the configuration controller determining the configuration manager to be used to configure the node; the configuration controller establishing a trust relationship between the node and the configuration manager; and deploying the software on the node using the configuration manager based on the established trust relationship.

[0006] On the other hand, the configuration manager can be predetermined by the administrator from a set of configuration managers.

[0007] In some respects, a trust relationship can be established between the configuration manager's client and server, where deployment occurs on the client of software provided by the server, and where the client is executing on a node.

[0008] In some respects, the configuration controller maintains information about the nodes, the status of the software deployment on the nodes, and / or one or more actions to be taken after receiving configuration, after successful node configuration, or after a failure occurs.

[0009] On the other hand, the software to be deployed on the nodes is specified by the configuration determined by the configuration controller.

[0010] On the other hand, the administrator provides the configuration to the configuration controller.

[0011] In some respects, the keys for accessing the cloud computing environment and / or the configuration manager are stored and kept confidential by the configuration controller, and the configuration controller uses the keys to establish trust relationships.

[0012] On the other hand, the keys for accessing the cloud computing environment and / or the configuration manager are created and stored by an entity known to the configuration manager, where the entity can be the cloud computing environment, the configuration manager, or a trusted third party, and the configuration controller uses this knowledge to establish trust relationships. In some cases, the keys are cryptographic keys.

[0013] In some respects, establishing a trust relationship between a first party and a second party means providing the first party with credentials that can be used to authorize access to the second party, or providing each party with credentials that can be used to authorize access to the corresponding other party.

[0014] In some implementations described herein, the processes for verifying the authorized configuration of a specific node / establishing a trust relationship between the node and the configuration manager provide an indirect layer to increase the overall security of the system and facilitate secure configuration. In some cases, the processes remove the ability of individual nodes to control how they are configured, thus preventing unauthorized, unauthenticated, or stolen nodes from requesting configuration resources that may contain sensitive information in a self-organizing manner. This reduces the risk that unauthorized, unauthenticated, or stolen nodes may access sensitive configuration information.

[0015] Processing also offers flexibility through integration with different existing configuration managers, allowing administrators to choose which configuration manager to use for configuring specific nodes. Integration with different configuration managers and tools also allows processing to be implemented in heterogeneous cloud computing networks using multiple configuration managers and tools. Processing can also be implemented using a common client-server protocol for communication, allowing for minimal reconfiguration of existing networks and systems.

[0016] Details of one or more embodiments of the subject matter described herein are set forth in the accompanying drawings and the following description. Other features, aspects, and potential advantages of the subject matter will become apparent from the description, drawings, and claims. Attached Figure Description

[0017] Figure 1 This is a diagram of an example environment for securely configuring resources in a cloud computing system.

[0018] Figure 2 This is a swimlane diagram for example processing of securely configuring resources in a cloud computing system.

[0019] Figure 3 This is a swimlane diagram for example processing of securely configuring resources in a cloud computing system.

[0020] Figure 4 Is Figure 1 A diagram illustrating the example configuration controller used in the environment.

[0021] Figure 5 This is a flowchart of an example process for securely configuring resources in a cloud computing system.

[0022] Figure 6 This is a diagram of a computing device that can be used to implement the systems and methods described in this document.

[0023] The same reference numerals and symbols in each of the figures indicate the same elements. Detailed Implementation

[0024] Configuration manager, such as CHEF TM PUPPET, SALT, and ANSIBLE are software programs used to deploy software to computing devices over a network. These configuration managers are typically used in local environments to distribute software over an internal network. Because these configuration managers offer many useful features, efforts have been made to use them in large-scale cloud computing systems. However, because these configuration managers were primarily designed for internal network use, many features expected in cloud computing systems, such as robust security, interoperability with other frameworks, and resilient deployment capabilities, have hindered these efforts to date.

[0025] This disclosure describes methods and systems for securely configuring nodes in a cloud computing system. The described solution utilizes existing configuration managers as resources to provide configuration items to nodes during configuration processing. The solution can support multiple different types of configuration managers with different application programming interfaces (APIs) and can allow them to be used together in a single cloud computing system. Furthermore, the solution provides support for elastic deployment of resources, such as in response to increased demand for resources or changes in network conditions. Moreover, security measures, such as the allocation, distribution, and management of access credentials for potentially sensitive configuration resources, are managed entirely by the described system, not by the configuration resources or nodes within the cloud computing system.

[0026] The described solution adds an indirection layer between the configuration manager and the nodes under the configuration. For example, when a node is configured by a configuration resource, a trust relationship can be established between the node to be configured and the configuration resource. Typically, the configuration resource or node is part of a trusted computing infrastructure to ensure secure configuration processing (e.g., preventing unauthorized or unauthenticated node access requests that may include sensitive information). In the solution described herein, the configuration controller, included in the trusted computing infrastructure, can proxy the trust relationship between the node and the configuration resource, allowing the node and configuration resource to establish mutual trust, even though they are not themselves part of the trusted computing infrastructure. For example, the configuration controller can establish this trust relationship by configuring the node's access credentials on the configuration resource and providing the node with credentials for accessing the resource. Secure configuration of nodes can be achieved based on this indirection layer provided by the configuration controller, even though the node or configuration resource is not part of the trusted computing infrastructure. For example, the trusted computing infrastructure may include components within the system that manage and protect potentially sensitive access credentials.

[0027] Administrators can configure the system using a set of configuration policies that specify which configuration from which configuration manager should be applied to a particular node. Configuration policies can be specified as a set of rules. Each rule matches a node's characteristics (e.g., name, creation date, owner, etc.) against a set of configuration data. Each rule can also specify the system's configuration action to take, indicating whether the node configuration was successful or unsuccessful. To obtain configuration, a node sends a request to the system (e.g., over a network). When the system receives a request to configure a machine, it finds one or more rules within the configuration policy that match the node's characteristics to determine the configuration action to take.

[0028] This solution integrates with existing configuration managers to provide resilience through automatic node configuration in response to resource demands. Existing configuration managers typically operate in interactive environments, where administrators interactively configure new nodes. This interactive scenario may be unsuitable for resilience scenarios, where customers expect nodes to be configured in response to the current state of the system. This solution enhances the ability of administrators to configure nodes on demand and makes configuration managers suitable for resilience scenarios. This integration capability with existing solutions also makes the system easier to deploy across a variety of different existing cloud configurations, each with one or more configuration managers that can be integrated with this system.

[0029] Regarding security, some cloud configuration managers can provide access credentials (e.g., encryption keys, login credentials, etc.) to nodes under configuration so that they can access network resources to obtain items needed for configuration (e.g., software libraries, source code, etc.). Such configurations can pose security risks because attackers can compromise any number of nodes to obtain these access credentials. This disclosure describes a system in which access credentials can be managed by the configuration system and do not need to be managed or maintained by the node being configured. This aspect increases the overall security of the system and facilitates secure configuration. Furthermore, this system removes the ability of individual nodes to control how they are configured, thus preventing compromised nodes from self-organizing requests for configuration resources that may contain sensitive information. This reduces the risk that unauthorized, unverified, or compromised nodes can access sensitive configuration information.

[0030] This solution also provides enhanced security by verifying that a specific node requesting configuration is indeed authorized to be configured in this way. The system can correlate configuration requests received from a specific node with corresponding actions from an administrator to verify that the node is authorized to be configured. The system can also guide the node to execute various instructions and provide the output of those instructions to verify that the node is genuine and not, for example, a compromised node guided by an attacker. For instance, the system can guide the node to perform a large amount of computation in a short period of time to verify that a compromised node is not manually controlled by a human attacker. The system can also guide the node to provide information such as a unique identifier included in its initial configuration. Such information can be correlated with the node's original creation request to verify that the node is authorized to receive configuration.

[0031] Figure 1This is a diagram of an example environment 100 for securely configuring resources in a cloud computing system. As shown, environment 100 includes a user or automation system 110 that communicates with a deployment manager 120. In response to a request from the user / automation system 110, the deployment manager 120 deploys node 130 (e.g., a virtual machine instance, container instance, or other component of the cloud computing system). A configuration controller 140 interacts with node 130 to provide it with configuration. The configuration controller 140 operates based on configuration policy 160. The configuration controller 140 also interacts with configuration resources 150 and does not authorize node 130 to retrieve configuration items from the resources. In operation, the user / automation system 110 requests the deployment manager 120 to create a node (170). In response, the deployment manager 120 deploys node 130 (172). Upon initialization, node 130 sends a configuration request 174 to the configuration controller 140. The configuration controller 140 identifies the configuration policy 164 of node 130 based on parameters included in the configuration request 174. Configuration controller 140 issues configuration command 176 to node 130. Node 130 executes configuration command 176 and provides the result of the command to configuration controller 140. Configuration controller 140 can also send configuration command 178 to configuration resource 150. For example, configuration by configuration controller 140 can configure configuration resource 150 to authorize node 130 to retrieve configuration items from configuration resource 150 (180). Configuration controller 140 can also (e.g., via configuration command 176) configure access credentials for node 130 that allow it to access configuration resource 150.

[0032] User / automation system 110 is an entity that requests a node instance, such as node 130, to be deployed by deployment manager 120. For example, user / automation system 110 may include a user interacting with a user interface to create a new node instance. User / automation system 110 may also include, for example, an automated system that automatically requests the creation of a node instance from the deployment manager in response to an increase in demand for computing resources for a particular application, a decrease in the performance of a cloud computing system managed by deployment manager 120, or other events. In some implementations, user / automation system 110 may communicate with deployment manager 120 via a network (not shown) to request the creation of a node (170) and receive confirmation (182) that the node has been created. Additional information, such as the identity of user / automation system 110, the attributes of the node to be created, or other information, may be present in the creation request (170) and the confirmation (182), as discussed in more detail below.

[0033] Deployment Manager 120 can be a computing component in a distributed computing environment such as a cloud computing system. In some implementations, Deployment Manager 120 can be one or more computing components operable to deploy new node instances and manage existing node instances within the distributed computing environment. In some cases, Deployment Manager 120 can be implemented as a software component and can provide an API that allows entities such as User / Automation System 110 to request the creation of new nodes within the distributed computing environment. In some implementations, deployment can be a hypervisor component that deploys and manages nodes within one or more virtual execution environments. In such cases, the nodes deployed and managed by the hypervisor can be virtual machine instances, container instances, virtual resources (e.g., disks, processors, etc.), or other virtual components.

[0034] At 172, node 130 is deployed by deployment manager 120. Node 130 can be a node instance deployed and executed by a physical computing device within a virtual environment. In some cases, node 130 can be created based on a virtual machine or container image associated with deployment manager 120 and specified by user / automation system 110 in creation request 170. In some implementations, node 130 can be deployed with a minimal configuration sufficient to allow it to communicate with configuration controller 140. For example, node 130 can be deployed with a minimally configured operating system, limited network configuration allowing it to access configuration controller 140 via a network (not shown), and instructions to send configuration request 174 to configuration controller 140 and await a response from configuration controller 140. Such deployment allows configuration controller 140 to control most aspects of the configuration of node 130. Conversely, a node deployed with a non-minimum configuration may include configuration settings, software packages, and other configuration items within the image used to create the node. Such an approach may make it difficult to make changes to the initial configuration of a new node, as the image from which the node was created must be updated to accommodate such changes. This solution can also be used when nodes are deployed in a non-minimal configuration, for example, to update pre-installed software packages to the latest version, change settings included in the initial configuration of the image to updated values, and perform other configuration actions. This approach alleviates some of the difficulties of changing the initial configuration included in the image because the non-minimal configured node 130 can request and receive configuration from the configuration controller 140 in the same way as the minimally configured node during initialization.

[0035] Configuration controller 140 receives configuration request 174 from node 130 via a network (not shown). In some implementations, node 130 sends configuration request 174 via a Representational State Transition (REST) ​​API provided by configuration controller 140. Node 130 may be instructed to use Hypertext Transfer Protocol (HTTP), HTTP Secure (HTTPS), or other protocols to access the Uniform Resource Locator (URL) corresponding to configuration controller 140. For example, node 130 may send an HTTP request to configuration controller 140 with the URL “http: / / configcontroller.internal.net / start”, where the domain name “configcontroller.internal.net” resolves to a network address associated with configuration controller 140, and the target “start” indicates to configuration controller 140 that node 130 is requesting configuration.

[0036] Configuration request 174 may also include identification information about node 130. For example, user / automation system 110 may specify information about node 130 to be created by deployment manager 120, such as the type of node instance, the identity of the user or system requesting the creation of node 130, a unique identifier for the request to create the node, or other information. In some cases, this information may be encoded in configuration request 174. In some implementations, configuration controller 140 may use this information to verify that node 130 is authorized to be configured. For example, configuration controller 140 may receive a unique identifier for the request to create the node in configuration request 174 and may use this identifier to verify that node 130 has indeed been deployed and is requesting configuration based on a valid creation request. Such verification can provide increased security by preventing unauthorized node instances from gaining access to internal and potentially sensitive configuration data. In one example, such a node instance would be created by a malicious entity attempting to gain access to such internal data. Configuration controller 140 may also verify that the node instance was created by a user or system authorized to create a node instance with the specific attributes of the node to be configured.

[0037] In some implementations, configuration controller 140 may receive configuration request 174 from deployment manager 120. In such a case, when deployment manager 120 deploys a new node, it may send configuration request 174 to configuration controller 140 with information about the newly deployed node. As in the node startup configuration scenario described above, configuration controller 140 may use information about the node in a similar manner to identify and verify the node's identity before configuring it.

[0038] In some implementations, configuration controller 140 can be configured to scan the network for newly deployed nodes awaiting configuration. In such cases, configuration controller 140 will not receive configuration request 174 to initiate configuration for a specific node, but will instead initiate configuration processing when a node awaiting configuration is found. For example, configuration controller 140 may periodically check a database or other resource containing a list of nodes awaiting configuration and may initiate communication with such nodes to begin configuration processing. Configuration controller 140 may also send broadcast messages on the network indicating that it is ready to configure any newly deployed nodes. In such cases, newly deployed nodes will be configured to respond to the broadcast message to begin configuration processing.

[0039] Configuration controller 140 can use information from configuration request 174 to identify a configuration policy in configuration policy 160 for configuring node 130. In some embodiments, configuration policy 160 may include rules and a set of configuration commands to be performed when a node to be configured matches a rule. For example, configuration policy 160 may specify that a node of type "database" should have a database management software program installed during configuration processing. If configuration controller 140 receives a configuration request from node 130 specifying that node 130 is of type "database", the configuration controller will identify that node 130 matches configuration policy 160 for node type "database" and will issue the configuration commands defined in configuration policy 160 to node 130 to install the database management software program. Rules in configuration policy 160 may include criteria specifying matching values ​​for information received in the configuration request received from node 130. In some embodiments, configuration policy 160 may specify a particular configuration resource 152 for performing the configuration.

[0040] Once configuration controller 140 recognizes configuration policy 162 for configuring node 130, configuration controller 140 can send one or more configuration commands 176 to node 130. As previously discussed, node 130 listens for such commands from configuration controller 140 after sending configuration request 174. In some embodiments, when node 130 receives configuration command 176, it deploys instructions to execute the received command and provides the configuration controller 140 with the output or result of the executed command.

[0041] This arrangement provides increased flexibility in configuring node 130 because configuration controller 140 can instruct node 130 to effectively execute any command that can be executed by a user directly inputting commands to node 130. In some implementations, node 130 can execute each received configuration command 176 in an operating system shell or command-line interface, such as Bourne shell (sh), Bourne-Again shell (bash), Korn shell (ksh), C shell (csh), or other shells or command-line interfaces. Such an arrangement allows configuration controller 140 to utilize the rich features of such shells in configuring node 130, such as scripting and flow control operations, such as redirection (">) and pipes ("|").

[0042] For example, in response to a sample configuration request 174 from node 130 of type "database", configuration controller 140 can send configuration command 176 to node 130 to configure a package management client on node 130, such as an Advanced Packaging Tool (APT), RPM package manager, or other client, to access a specific configuration resource 150. For example, configuration command 176 could be "add-apt-repository 'deb http: / / config.blah.com / config / database-manager main'", where "http: / / config.blah.com / config / " is the URL corresponding to resource 150. Node 130 can receive configuration command 176 and execute it in a shell or command-line interface as described above. Execution of configuration command 176 will cause the "add-apt-repository" program on node 130 to be executed with the specified parameters, in which case the configuration of the APT package management client program will be updated. Then, the configuration controller 140 can send a configuration command 176, which invokes the package management client on node 130 and instructs it to retrieve the appropriate package. For example, the configuration command 176 for retrieving the "Database Manager" component from the previous example could be "apt-get install database-manager". Node 130 can receive the configuration command 176 and execute it in the shell or command-line interface described above. Execution of the configuration command 176 will cause the "add-get" program on node 130 to be executed with the specified parameters, in which case this will cause node 130 to retrieve and install the "Database Manager" package from the configuration resource 150 configured with the previous command.

[0043] Configuration controller 140 can also send configuration command 176, which is selected to further verify that node 130 is authorized to be configured. For example, configuration controller 140 can instruct node 130 to perform a series of calculations and provide results within a certain time period. Such a mechanism can be used to verify that node 130 is indeed a computing resource and not a human attacker attempting to gain electronic access to the system. The time period can be selected such that it is infeasible for a human attacker to perform calculations before the time period expires. In another example, configuration controller 140 can instruct node 130 to read immutable characteristics of its environment, such as a Physical Media Access Control (MAC) address, serial number, or other unique identifier of the physical computing device on which node 130 is performing calculations. Node 130 can provide this data to configuration controller 140 for verification. Such a check can ensure that node 130 is a node instance deployed by deployment manager 120 in response to a request from user / automation system 110, and not a node instance deployed by an attacker to mimic a deployed instance for possible malicious purposes.

[0044] Configuration resource 150 can be a computing component or a set of computing components from which node 130 can retrieve configuration items (180). For example, configuration resource 150 can be a configuration management server that executes a configuration management tool, such as CHEF. TM The configuration resource 150 can be a database, repository, or other collection of configuration items, such as PUPPET, SALT, ANSIBLE, or another configuration management tool. In some implementations, the configuration controller can be configured to communicate with multiple different types of configuration resources 150 using APIs, communication protocols, or other mechanisms specific to each particular type of configuration resource 150. To authorize node 130 to access configuration resource 150, configuration controller 140 can send configuration command 178 to configuration resource 150. Similarly, configuration controller 140 can send configuration command 176 to node 130 to provide node 130 with credentials used when accessing configuration resource 150. In some cases, such credentials can be restricted so that node 130 is only granted the access level it needs to be configured. For example, node 130 can be provided with access credentials for configuration resource 150 created by configuration controller 140 at the start of configuration processing and deleted by configuration controller 140 at the end of configuration processing. By reducing the need for node 130 to store and maintain access credentials for its own configuration resource 150, such a technique can result in increased security compared to previous techniques. Instead, configuration controller 140 can manage such credentials and provide them to node 130 only when configuration is required. This limits the resources that an attacker gaining control of node 130 can access and limits the number of components within the system that need to manage and protect potentially sensitive access credentials.

[0045] In some implementations... Figure 1 The interaction between the components shown can be implemented as messages sent between the components via one or more networks to which they are connected. For example, the one or more networks may include Internet Protocol (IP) or other types of networks, and may utilize Transmission Control Protocol (TCP), Universal Datagram Protocol (UDP), or other protocols at the transport layer. The messages sent between the components can be structured according to a communication protocol, such as Hypertext Transfer Protocol (HTTP), Remote Procedure Call (RPC), Simple Object Access Protocol (SOAP), or other communication protocols. One or more physical layer network technologies can be used to implement the one or more networks, including but not limited to Ethernet, Synchronous Optical Network (SONET), Asynchronous Transfer Mode (ATM), and other wired or wireless network technologies.

[0046] In some implementations, configuration controller 140 may update existing nodes on the network in an interleaved manner. In such a rolling update process, configuration controller 140 selects nodes to receive updated configurations based on specified criteria. For example, the criteria may specify that nodes on the network are updated at a rate of 100 per hour. In response, configuration controller 140 may select 100 nodes per hour and instruct these nodes to receive updated configurations in the same manner as described above. In some cases, configuration controller 140 may initiate the update process by sending a message to the nodes to be updated. Configuration controller 140 may also receive the message to initiate the update process from each node to be updated. Configuration controller 140 may also receive the message to initiate the update process from deployment manager 120.

[0047] Figure 2 This is a swimlane diagram of an example process for securely configuring resources in a cloud computing system. At 205, the user / automation system 110 requests the deployment manager 120 to create a node. At 210, the deployment manager 120 creates and deploys node 130. At 215, node 130 initializes par and sends a configuration request message to the configuration controller 140. At 220, node 130 polls for configuration commands from the configuration controller 140. In some implementations, node 130 may enter a "busy wait" loop, where node 130 periodically checks for configuration commands received from the configuration controller 140.

[0048] At 225, in response to a configuration request received from node 130, configuration controller 140 sends a configuration command to node 130. At 230, node 130 executes the received configuration command. At 235, node 130 sends the result of the configuration command to configuration controller 140. For example, node 130 can execute the configuration command within an operating system shell and provide the output of the executed command to configuration controller 140 as a result. At 240, node 130 polls again for configuration commands from configuration controller 140.

[0049] Figure 3 This is a swimlane diagram for example processing of configuring node 130 and configuration resource 150 using configuration controller 140. At 305, configuration controller 140 configures node 130 to access configuration resource 150. For example, configuration controller 140 may provide node 130 with information for accessing configuration resource 150, such as the network address used to contact configuration resource 150, access credentials for accessing configuration resource 150, or other information. In some embodiments, configuration may occur after configuration controller 140 has prepared the configuration resource at 310 and 315 (described below). In some embodiments, configuration controller 140 may install a client application associated with configuration resource 150 on node 130 and may invoke the client application when instructing node 130 to retrieve configuration items from configuration resource 150.

[0050] At 310, configuration controller 140 performs an installation operation to prepare configuration resource 150, thereby providing configuration items to node 130. In some embodiments, such an installation operation may include determining whether configuration resource 150 can provide the specific configuration items required by configuration node 130. At 315, configuration controller 140 instructs configuration resource 150 to authorize node 130 to access configuration resource 150. For example, configuration controller 140 may create a set of access credentials for node 130 on configuration resource 150. In some cases, configuration controller 140 may provide configuration resource 150 with information about node 130, such as its network address or other identifying information, so that configuration resource 150 can verify node 130 when node 130 attempts to access the resource. In some embodiments, configuration controller 140 may perform steps 310 and 315 by utilizing an API specific to configuration resource 150. Configuration controller 140 is operable to communicate with multiple different types of configuration resources 150 using multiple different APIs.

[0051] At 320, configuration controller 140 instructs node 130 to retrieve configuration items from configuration resource 150. For example, configuration controller 140 may instruct node 130 to invoke a client application installed at 305 to access configuration resource 150. Configuration controller 140 may include the configuration item to be retrieved or an identifier of the configuration item. In some embodiments, configuration controller 140 may instruct node 130 to retrieve the configuration item by sending a message constructed according to a protocol specific to configuration resource 150 over the network. At 330, configuration resource 150 returns the configuration item indicated by the request sent at 325.

[0052] At 335, node 130 applies the configuration items received from configuration resource 150. In some embodiments, applying the configuration items may include a client application associated with configuration resource 150 that installs the received configuration items on node 130. When node 130 receives configuration items from configuration resource 150 at 330, node 130 may also return a result to configuration controller 140. In response, configuration controller 140 may send a configuration command to node 130 including instructions to install the configuration items. At 340, node 130 sends the result of applying the configuration items to configuration controller 140. In some embodiments, steps 320 to 340 may be repeated multiple times to apply multiple different configuration items to node 130. Configuration policy 160 of node 130, identified by configuration controller 140, may specify which configuration items should be installed on node 130, and thus may specify the number of times steps 320 to 340 may be repeated and with what parameters.

[0053] At 345, configuration controller 140 determines that configuration of node 130 is complete. In some embodiments, configuration controller 140 may determine configuration completion based on the successful result received from node 130 for each configuration item to be applied to node 130. At 350, configuration controller 140 sends an indication to node 130 that configuration processing is complete. At 355, node 130 sends an indication to deployment manager 120 that it has been successfully deployed. At 360, deployment manager 120 sends an indication to user / automation system 110 that node 130 has been successfully created. In some embodiments, if configuration controller 140 does not receive a successful result from node 130 for one or more configuration items to be applied, configuration controller 140 may send a negative indication such as a "configuration failed" indication to node 130. Node 130 may communicate this indication to deployment manager 120, which may then communicate the indication to user / automation system 110. In some cases, node 130 may delete itself in response to such a failure indication. Node deletion may also be performed by configuration controller 140 or deployment manager 120.

[0054] Figure 4 It includes Figure 1The diagram illustrates an example environment 400 for configuration controller 140. As shown, configuration controller 140 includes a configuration service 410, a configuration worker 420, a set of configuration data 432, and a user interface 450. In operation, configuration initiator 440 can communicate with configuration service 410 using a REST API. Configuration initiator 440 can indicate to configuration service 410 that a new node 130 has been deployed and will request configuration from configuration controller 140. In some cases, configuration initiator 440 may be... Figure 1 The user / automation system 110 shown is shown. Figure 1 The deployment manager 120 shown, or any other computing component or entity that has deployed or created node 130. Configuration initiator 440 may indicate information about node 130, such as unique identifiers for node 130 or unique identifiers for requests that cause node 130 to be deployed or created. This information can be used to verify that a configuration request received by configuration controller 140 originates from node 130 that has already been created or deployed by configuration initiator 440.

[0055] In response to receiving such an instruction from configuration initiator 440, configuration service 410 may assign a task for configuration node 130 to configuration worker 420. In some embodiments, configuration worker 420 may be a software component such as a thread, module, or object, including the functionality required to process configuration requests from node 130 and provide necessary configuration commands to node 130 for necessary configuration. In some cases, configuration service 410 may also route configuration requests identified as originating from node 130 to configuration worker 420, assigned as configuration node 130, such as by configuring a network module (not shown) responsible for internal routing of messages received within configuration controller 140. Once configuration worker 420 receives a configuration request from node 130, as relative to... Figures 1 to 3 As described, it can interact with node 130 in configuration resource 150 to configure node 130.

[0056] Configuration service 410 and configuration worker 420 can create and maintain a set of configuration data 432. In some implementations, configuration data 432 may include information about pending configuration operations, the results of previous configuration operations (e.g., success or failure), or recovery data used to resume or continue pending configuration operations in the event of a failure of configuration controller 140.

[0057] As shown, configuration service 410 creates billing record 470 and log 480. In some implementations, billing record 470 and log 480 include information about completed configuration operations. For example, billing record 470 may include charges to be billed to configuration initiator 440 or another entity that successfully deployed node 130. Log 480 may include detailed information about the configuration processing of node 130, such as which configuration commands were issued by configuration controller 140 and the results of those commands. Log 480 can provide a historical record of the activities of configuration controller 140.

[0058] User interface 450 provides access to information from billing records 470 and logs 480 to administrator 460. For example, administrator 460 can use a web browser to access user interface 450 over a network using HTTP and can retrieve web pages containing information from billing records 470 and logs 480 from the user interface. In some implementations, user interface 450, or a different user interface displayed, may allow administrator 460 to search for information in billing records 470 and logs 480, filter information, view information in different ways, export information to different formats, or perform other operations.

[0059] Figure 5 This is a flowchart of example process 500 for securely configuring resources in a cloud computing system. For clarity, it will be discussed regarding... Figure 1 The components shown are used to describe process 500. At 505, configuration controller 140 receives a configuration request from a specific node 130 in the cloud computing network. In some cases, the configuration request includes node information for the specific node. The node information may include the identifier of the specific node.

[0060] At 510, the configuration controller 140 verifies, at least in part, that a specific node 130 is authorized for configuration based on node information. In some cases, verifying that a specific node 130 is authorized for configuration includes the configuration controller 140 sending an information request to the specific node 130 over the network, receiving a response to the information request from the specific node 130 over the network, and verifying that the response received from the specific node 130 matches an expected response. In some implementations, the information request includes one or more commands executed by the specific node 130 upon receipt, and the response to the information request includes the output produced by the specific node 130 executing one or more commands. Verifying that a specific node 130 is authorized for configuration may also include determining that a management component associated with the cloud computing network has created a node with node information matching the node information received from the specific node 130, and determining that the node has not yet been configured. In some implementations, the node information includes creation information detailing how the specific node 130 was created, and verifying that the specific node 130 is authorized for configuration includes verifying that the creation information matches a security policy associated with the cloud computing network. The creation information may include at least one of the following: the management component that created the specific node 130, the user who created the management component for the specific node 130, the project that created the specific node, or the node type of the specific node 130.

[0061] In 515, as previously relative to Figure 1 As discussed, in response to verifying that a specific node 130 is authorized for configuration, the configuration controller 140 identifies the configuration action to be performed on the specific node 130 based at least in part on node information. At 520, as previously discussed relative to... Figure 1 In the discussion, the configuration controller 140 sends one or more configuration commands corresponding to the identified configuration actions to a specific node 130, and the specific node 130 executes the configuration commands to perform the corresponding configuration actions.

[0062] In some cases, the process 500 also includes the configuration controller 140 receiving a configuration report corresponding to a configuration command from a specific node 130 via a network. The configuration report includes reporting information related to the execution of the configuration command by the specific node 130.

[0063] In some cases, the configuration command is the first configuration command, and the process 500 also includes the configuration controller 140 determining, based on report information, that the first configuration command was successfully executed by a specific node 130, and in response to determining that the first configuration command was successfully executed, sending a second configuration command corresponding to one or more additional configuration actions over the network to the specific node 130, wherein the one or more additional configuration actions are selected from identified configuration actions and are different from the configuration actions corresponding to the first configuration command.

[0064] In some implementations, the process 500 further includes the configuration controller 140 determining, based on the report information, that the configuration command was not successfully executed by the specific node 130, and in response to determining that the configuration command was not successfully executed, notifying the management component associated with the specific node 130 that the specific node 130 was not successfully configured.

[0065] Figure 6 This is a block diagram of computing devices 600, 650, which can be used to implement the systems and methods described in this document as clients, servers, or multiple servers. Computing device 600 is intended to represent various forms of digital computers, such as laptops, desktops, workstations, personal digital assistants, servers, blade servers, mainframes, and other suitable computers. Computing device 650 is intended to represent various forms of mobile devices, such as personal digital assistants, cellular phones, smartphones, and other similar computing devices. Additionally, computing devices 600 or 650 may include a Universal Serial Bus (USB) flash drive. The USB flash drive can store an operating system and other applications. The USB flash drive may include input / output components, such as a wireless transmitter or a USB connector that can be plugged into a USB port of another computing device. The components shown herein, their connections and relationships, and their functions are merely exemplary and are not intended to limit the implementation of the inventions described and / or claimed in this document.

[0066] Computing device 600 includes a processor 602, memory 604, storage device 606, a high-speed interface 608 connected to memory 604 and a high-speed expansion port 610, and a low-speed interface 612 connected to a low-speed bus 614 and storage device 606. Each of components 602, 604, 606, 608, 610, and 612 is interconnected using various buses and can be mounted on a common motherboard or otherwise suitably mounted. Processor 602 can process instructions executed within computing device 600, including instructions stored in memory 604 or storage device 606 to display graphical information of a GUI on an external input / output device such as a display 616 coupled to high-speed interface 608. In other embodiments, multiple processors and / or multiple buses may be suitably used with multiple memories and multiple types of memory. Additionally, multiple computing devices 600 may be connected, each device providing a portion of the necessary operation (e.g., as a server library, a set of blade servers, or a multiprocessor system).

[0067] Memory 604 stores information within computing device 600. In one embodiment, memory 604 is one or more volatile memory cells. In another embodiment, memory 604 is one or more non-volatile memory cells. Memory 604 may also be another form of computer-readable medium, such as a disk or optical disk.

[0068] Storage device 606 provides large-capacity storage for computing device 600. In one embodiment, storage device 606 may be or include computer-readable media, such as floppy disk devices, hard disk devices, optical disk devices, or magnetic tape devices, flash memory or other similar solid-state storage devices, or include devices in a storage area network or other configured array of devices. A computer program product may be tangibly implemented in an information carrier. The computer program product may also contain instructions that, when executed, perform one or more methods such as those described above. The information carrier is a computer or machine-readable medium, such as memory 604, storage device 606, or memory on processor 602.

[0069] High-speed controller 608 manages bandwidth-intensive operations of computing device 600, while low-speed controller 612 manages less bandwidth-intensive operations. This functional allocation is merely exemplary. In one embodiment, high-speed controller 608 is coupled to memory 604, display 616 (e.g., via a graphics processor or accelerator), and is coupled to high-speed expansion port 610, which can accept various expansion cards (not shown). In another embodiment, low-speed controller 612 is coupled to storage device 606 and low-speed expansion port 614. The low-speed expansion port, which may include various communication ports (e.g., USB, Bluetooth, Ethernet, Wireless Ethernet), may be coupled to one or more input / output devices, such as keyboards, pointing devices, scanners, or network devices such as switches or routers, for example, via a network adapter.

[0070] As shown in the figure, computing device 600 can be implemented in several different forms. For example, it can be implemented as a standard server 620, or multiple times in a set of such servers. It can also be implemented as part of a rack server system 624. Alternatively, it can be implemented in a personal computer such as a laptop computer 622. Optionally, components from computing device 600 can be combined with other components in a mobile device (not shown), such as device 650. Each such device can contain one or more of computing devices 600, 650, and the entire system can consist of multiple computing devices 600, 650 communicating with each other.

[0071] Computing device 650 includes processor 652, memory 664, input / output devices such as display 654, communication interface 666 and transceiver 668, and other components. Device 650 may also be provided with storage devices such as microdrives or other devices to provide additional storage. Each of components 650, 652, 664, 654, 666, and 668 is interconnected using various buses, and multiple components may be mounted on a common motherboard or otherwise suitably mounted.

[0072] Processor 652 can execute instructions within computing device 650, including instructions stored in memory 664. The processor can be implemented as a chipset comprising multiple separate analog and digital processors. Alternatively, the processor can be implemented using any of several architectures. For example, processor 610 can be a CISC (Complex Instruction Set Computer) processor, a RISC (Reduced Instruction Set Computer) processor, or a MISC (Minimum Instruction Set Computer) processor. For example, the processor can provide coordination for other components of device 650, such as control of the user interface, applications running by device 650, and wireless communications performed by device 650.

[0073] Processor 652 can communicate with the user via control interface 658 and display interface 656 coupled to display 654. For example, display 654 may be a TFT (Thin Film Transistor Liquid Crystal Display) or OLED (Organic Light Emitting Diode) display, or other suitable display technology. Display interface 656 may include appropriate circuitry for driving display 654 to present graphics and other information to the user. Control interface 658 can receive commands from the user and translate them for submission to processor 652. Additionally, an external interface 662 may be provided to communicate with processor 652, enabling device 650 to perform near-field communication with other devices. For example, external interface 662 may provide wired communication in some embodiments or wireless communication in others, and multiple interfaces may be used.

[0074] Memory 664 stores information within computing device 650. Memory 664 can be implemented as one or more computer-readable media, one or more volatile memory cells, or one or more non-volatile memory cells. Extended memory 674 can also be provided and connected to device 650 via an extended interface 672, which may include, for example, a SIMM (Single In-line Memory Module) card interface. Such extended memory 674 can provide additional storage space for device 650, or it can store applications or other information of device 650. Specifically, extended memory 674 may include instructions to perform or supplement the above-described processes, and may also include security information. Therefore, for example, extended memory 674 can be provided as a security module of device 650 and can be programmed with instructions that allow secure use of device 650. Additionally, security applications and additional information, such as placing identification information on a SIMM card in a manner resistant to hacking, can be provided via the SIMM card.

[0075] As discussed below, memory may include, for example, flash memory and / or NVRAM memory. In one embodiment, a computer program product is tangibly implemented in an information carrier. The computer program product contains instructions that, when executed, perform one or more methods such as those described above. The information carrier is a computer or machine-readable medium, such as memory 664, extended memory 674, or memory on processor 652, which may be received, for example, via transceiver 668 or external interface 662.

[0076] Device 650 can communicate wirelessly via communication interface 666, which may include digital signal processing circuitry if necessary. Communication interface 666 can provide communication under various modes or protocols, such as GSM voice calls, SMS, EMS, or MMS messages, CDMA, TDMA, PDC, WCDMA, CDMA2000, or GPRS, and other communications. Such communication can occur, for example, via radio frequency transceiver 668. Additionally, short-range communication can occur using transceivers such as Bluetooth, WiFi, or others (not shown). Furthermore, GPS (Global Positioning System) receiver module 670 can provide device 650 with additional navigation and location-related wireless data, which can be appropriately used by applications running on device 650.

[0077] Device 650 can also use audio codec 660 for audible communication, which can receive voice information from a user and convert it into usable digital information. Audio codec 660 can also generate audible sounds for a user, such as through a speaker in a mobile phone, for example, device 650. Such sounds can include sounds from voice phone calls, recorded sounds (e.g., voice messages, music files, etc.), and sounds generated by applications operating on device 650.

[0078] As shown in the figure, computing device 650 can be implemented in several different forms. For example, it can be implemented as a cellular phone 680. It can also be implemented as a smartphone 682, a personal digital assistant, or part of another similar mobile device.

[0079] Various implementations of the systems and techniques described herein can be implemented in digital electronic circuits, integrated circuits, specially designed ASICs (Application-Specific Integrated Circuits), computer hardware, firmware, software, and / or combinations thereof. These various implementations can include implementations in one or more computer programs executable and / or interpretable on a programmable system, the programmable system including at least one programmable processor, at least one input device, and at least one output device, the programmable processor being dedicated or general-purpose, coupled to receive data and instructions from and transfer data and instructions to the storage system.

[0080] These computer programs (also known as programs, software, software applications, or code) include machine instructions for a programmable processor and can be implemented in high-level procedural and / or object-oriented programming languages, and / or in assembly / machine language. As used herein, the terms “machine-readable medium” and “computer-readable medium” mean any computer program product, apparatus, and / or device (e.g., disk, optical disk, memory, programmable logic device (PLD)) used to provide machine instructions and / or data to a programmable processor, including machine-readable media that receive machine instructions as machine-readable signals. The term “machine-readable signal” means any signal used to provide machine instructions and / or data to a programmable processor.

[0081] To provide interaction with a user, the systems and techniques described herein can be implemented on a computer having a display device (e.g., a CRT (cathode ray tube) or LCD (liquid crystal display) monitor for displaying information to the user) and a keyboard and indicating devices (e.g., a mouse or trackball) through which the user can provide input to the computer. Other types of devices can also be used to provide interaction with the user; for example, feedback provided to the user can be any form of sensory feedback (e.g., visual feedback, auditory feedback, or tactile feedback); and input from the user, including acoustic, speech, or tactile input, can be received in any form.

[0082] The systems and technologies described herein can be implemented in computing systems that include backend components (e.g., as data servers), middleware components (e.g., application servers), frontend components (e.g., client computers with a graphical user interface or web browser through which users can interact with implementations of the systems and technologies described herein), or any combination of such backend, middleware, or frontend components. Components of the system can be interconnected via digital data communication (e.g., communication networks) of any form or medium. Examples of communication networks include local area networks (“LANs”), wide area networks (“WANs”), peer-to-peer networks (with self-organizing or static members), grid computing infrastructure, and the Internet. Components of the system can also be computing devices (e.g., client or server) that include one or more virtual environments for executing software instances, such as virtual machine instances or container instances. The virtual environment can provide a virtual representation of hardware, software, and other resources to the executing software instance.

[0083] A computing system may include clients and servers. Clients and servers are typically geographically separated and usually interact via communication networks. The client-server relationship is established by computer programs running on individual computers that have a client-server relationship with each other. In some implementations, the server may be a node within a cloud computing system that is accessed by clients via a communication network.

[0084] While some implementations have been described in detail above, other modifications are possible. Furthermore, the logical flow depicted in the figures does not require a specific order or sequence to achieve the desired result. Additional steps may be provided from the described flow, or steps may be eliminated from the described flow, and additional components may be added to or removed from the described system. Therefore, other implementations are within the scope of the following claims.

Claims

1. A computer-implemented method, characterized in that, When the method is executed by data processing hardware, the data processing hardware is caused to operate, the operation including: Receive a request from the user system to create and configure a node in the cloud computing network, the request including attributes associated with the node to be created and configured; A trust relationship is established between the created node and the configuration resource by configuring access credentials on the configuration resource and providing the created node with the credentials to access the configuration resource; Verify that the user system is authorized to create and configure the node; and In response to verifying that the user system is authorized to create and configure the node: Create the node; Receive a configuration request from the created node, the configuration request identifying the configuration action to be performed on the created node based on the attributes associated with the created node; In response to receiving the configuration request from the created node, a configuration command corresponding to one or more of the identified configuration actions is sent to the created node, wherein the created node executes the configuration command upon receiving the configuration command to perform the identified configuration action, wherein the configuration command can be used to instruct the created node to perform a series of calculations and provide results within a selected time period; Receive report information related to the execution of the configuration commands by the created node; and Based on the report information, it is determined that the configuration command was successfully executed by the created node.

2. The method according to claim 1, characterized in that, The operation also includes sending a confirmation to the user system that the created node has been created.

3. The method according to claim 1, characterized in that, The request also includes the identity of the user system.

4. The method according to claim 1, characterized in that, The attribute includes the type of the node instance.

5. The method according to claim 4, characterized in that, The configuration request includes a configuration policy based on the type of the node instance and a configuration command based on the configuration policy.

6. The method according to claim 1, characterized in that, The request also includes a unique identifier used to identify the request.

7. The method according to claim 1, characterized in that, The operation also includes sending a configuration report corresponding to the configuration command from the created node, the configuration report including report information related to the execution of the configuration command by the created node.

8. The method according to claim 7, characterized in that, The configuration command includes a first configuration command, and the operation further includes: Based on the report information, it is determined that the first configuration command was successfully executed by the created node; and In response to determining that the first configuration command was successfully executed, a second configuration command corresponding to one or more additional configuration actions is sent to the created node, wherein the one or more additional configuration actions are selected from the identified configuration actions and are different from the configuration actions corresponding to the first configuration command.

9. The method according to claim 7, characterized in that, The operation also includes: Based on the report information, it is determined that the configuration command was not successfully executed by the created node; and In response to determining that the configuration command was not successfully executed, the management component associated with the created node is notified that the created node was not successfully configured.

10. The method according to claim 1, characterized in that, Verifying that the user system is authorized to create and configure the node includes verifying that the attributes match the security policy associated with the data processing hardware.

11. A system, characterized in that, The system includes: Data processing hardware; and A memory hardware that communicates with the data processing hardware, the memory hardware storing instructions that, when executed on the data processing hardware, cause the data processing hardware to operate, the operation including: Receive a request from the user system to create and configure a node in the cloud computing network, the request including attributes associated with the node to be created and configured; A trust relationship is established between the created node and the configuration resource by configuring access credentials on the configuration resource and providing the created node with the credentials to access the configuration resource; Verify that the user system is authorized to create and configure the node; and In response to verifying that the user system is authorized to create and configure the node: Create the node; Receive a configuration request from the created node, the configuration request identifying the configuration action to be performed on the created node based on the attributes associated with the created node; In response to receiving the configuration request from the created node, a configuration command corresponding to one or more of the identified configuration actions is sent to the created node, wherein the created node executes the configuration command upon receiving the configuration command to perform the identified configuration action, wherein the configuration command can be used to instruct the created node to perform a series of calculations and provide results within a selected time period; Receive report information related to the execution of the configuration commands by the created node; and Based on the report information, it is determined that the configuration command was successfully executed by the created node.

12. The system according to claim 11, characterized in that, The operation also includes sending a confirmation to the user system that the created node has been created.

13. The system according to claim 11, characterized in that, The request also includes the identity of the user system.

14. The system according to claim 11, characterized in that, The attribute includes the type of the node instance.

15. The system according to claim 14, characterized in that, The configuration request includes a configuration policy based on the type of the node instance and a configuration command based on the configuration policy.

16. The system according to claim 11, characterized in that, The request also includes a unique identifier used to identify the request.

17. The system according to claim 11, characterized in that, The operation also includes sending a configuration report corresponding to the configuration command from the created node, the configuration report including report information related to the execution of the configuration command by the created node.

18. The system according to claim 17, characterized in that, The configuration command includes a first configuration command, and the operation further includes: Based on the report information, it is determined that the first configuration command was successfully executed by the created node; and In response to determining that the first configuration command was successfully executed, a second configuration command corresponding to one or more additional configuration actions is sent to the created node, wherein the one or more additional configuration actions are selected from the identified configuration actions and are different from the configuration actions corresponding to the first configuration command.

19. The system according to claim 17, characterized in that, The operation also includes: Based on the report information, it is determined that the configuration command was not successfully executed by the created node; and In response to determining that the configuration command was not successfully executed, the management component associated with the created node is notified that the created node was not successfully configured.

20. The system according to claim 11, characterized in that, Verifying that the user system is authorized to create and configure the node includes verifying that the attributes match the security policy associated with the data processing hardware.

Images