Remote IaC Runtime Execution for Heterogeneous Cloud Automation
Find Innovative SolutionsGenerate Solutions
Solution Overview
Problem
Cloud automation tools face challenges in managing diverse Infrastructure as Code (IaC) runtimes and version control systems across multiple customer environments, requiring customer credentials, which poses security risks and management complexities.
Innovation Solution
A cloud automation service executes externally, utilizing remote workers within the customer environment configured with IaC runtimes and credentials, allowing customers to select runtime types and versions, while keeping credentials isolated from the service.
Engineering Contradictions & Design Principles
Engineering Contradiction Analysis
1Adaptability or versatility
If the cloud automation tool installs and configures multiple IaC runtimes and versions internally, then it can support diverse customer environments, but the device complexity and maintenance burden increase significantly
Solution Approach 1:
The patent extracts the IaC runtime execution capability from the cloud automation tool and places it in the customer's environment. The cloud automation tool only manages the remote worker process, while the actual IaC runtime (Terraform, Pulumi, etc.) executes locally in the customer's environment. This eliminates the need for the cloud tool to install and maintain multiple runtime versions.
Solution Approach 2:
The patent introduces a remote worker as an intermediary component that bridges the cloud automation tool and the customer's IaC runtime. The remote worker process communicates between the cloud tool and the local runtime, enabling support for multiple runtimes without requiring the cloud tool to directly manage them.
2Ease of operation
If the cloud automation tool requires customer credentials to access version control systems and infrastructure, then it can perform read-write operations for compliance, but security risks and trust issues increase
Solution Approach 1:
The patent segments the credential management function by having the remote worker process manage credentials locally in the customer's environment rather than the cloud tool storing or accessing them. Credentials are segmented at the local level, allowing read-write access for compliance while preventing credential exposure to the cloud service.
Solution Approach 2:
The remote worker process performs self-service credential management, using locally stored credentials to authenticate to version control systems and infrastructure APIs. This eliminates the need for the cloud automation tool to handle credentials, as the remote worker independently manages its own authentication.
3Extent of automation
If the cloud automation tool executes as a cloud service with centralized control, then it can provide unified management, but it cannot accommodate local version control systems deployed on corporate networks
Solution Approach 1:
The patent makes the system dynamic by allowing the remote worker to be configured with different version control system endpoints based on the customer's deployment architecture. The remote worker can dynamically connect to various VCS deployments (private gitlab, public GitHub, Azure DevOps) without requiring changes to the cloud automation tool's centralized architecture.
Data Source
AI summary
An example method of managing infrastructure in a cloud includes: receiving, at a remote worker from a cloud automation service, a task to be executed for managing the infrastructure, the remote worker executing in a customer environment that includes the infrastructure, the remote worker having a runtime, the cloud automation service executing external to the customer environment; retrieving, using first credentials obtained by the runtime from the customer environment, source code from a version control system executing in the customer environment; and executing, by the runtime, the source code to manage the infrastructure in the customer environment according to the task.