Verifying revocation timings and recovery procedures before going live ensures that access can be immediately terminated during a security incident or failure. In the modern landscape of 2026, organizations frequently find themselves operating across multiple cloud providers to leverage specialized services or satisfy regional compliance requirements. However, this multi-cloud reality often introduces a significant security burden, particularly when traditional methods of authentication rely on static, long-lived credentials like JSON service-account keys. These keys are notoriously difficult to rotate, easy to misplace, and represent a major vulnerability if leaked into public repositories or compromised environments. To address these challenges, sophisticated infrastructure teams are moving toward keyless architectures that utilize short-lived, identity-based tokens. By establishing a bridge between Amazon Web Services and Google Cloud through open standards, engineers can create a unified deployment pipeline that is both highly secure and operationally efficient. This transition requires a deep understanding of how identity providers interact across different ecosystems and necessitates a disciplined approach to managing infrastructure as code without introducing unnecessary friction into the development lifecycle.
1. Strategic Goals and Architecture Constraints
Establishing a clear set of architectural requirements is the first step toward building a resilient multi-cloud deployment pipeline. For many organizations, the primary objective is to maintain a single source of truth for infrastructure state, regardless of which cloud provider is being targeted. This means keeping all Terraform state files within an existing Amazon S3 bucket, even when deploying resources to Google Cloud. By centralizing state management in a familiar AWS environment, teams avoid the risks associated with migrating sensitive state data and ensure that existing backup and auditing policies remain intact. Furthermore, maintaining a single fleet of GitHub Actions runners hosted on AWS-based Kubernetes clusters allows for better resource utilization and simplified maintenance. Rather than managing two separate sets of CI/CD runners—one for each cloud—engineers can leverage their existing AWS infrastructure to orchestrate deployments across the entire multi-cloud estate, provided that a secure and reliable method of cross-cloud authentication is implemented.
Beyond state management and runner centralization, the most critical constraint in modern cloud engineering is the absolute prohibition of long-lived credentials. In the current operational climate, security teams increasingly view JSON service-account keys as a legacy liability that must be eliminated to achieve a zero-trust posture. Instead of storing these dangerous “keys to the kingdom” in CI/CD secrets or local environments, the architecture must rely on short-lived, dynamically generated access tokens. These tokens should be issued only when needed and should expire automatically shortly after the deployment process completes. This approach significantly reduces the attack surface, as there are no static secrets to be stolen or mismanaged. Transitioning to this model requires a shift in mindset from credential-based security to identity-based security, where the identity of the AWS runner itself serves as the basis for gaining temporary permission to modify resources within the Google Cloud environment.
2. The Mechanics of Keyless Authentication
The technological foundation for this secure cross-cloud bridge is Workload Identity Federation, a mechanism that allows external workloads to access Google Cloud resources without needing a service-account key. This process relies on the exchange of identity assertions between the two cloud providers using standard protocols like OpenID Connect. In this specific scenario, the AWS IAM role assigned to the Kubernetes-based CI runner acts as the identity provider. When the runner needs to interact with Google Cloud, it generates a cryptographically signed request that proves its identity as a trusted AWS principal. Google Cloud’s Security Token Service then evaluates this request against a pre-configured Workload Identity Pool. If the identity matches the defined criteria—such as originating from a specific AWS account and belonging to a specific IAM role—the Security Token Service issues a federated token that represents the AWS workload’s identity within the Google Cloud ecosystem.
To further refine this process and ensure maximum compatibility with the Terraform Google provider, a service-account impersonation model is typically employed. In this model, the federated identity does not directly manage resources; instead, it is granted the specific permission to “impersonate” a Google Cloud service account. This separation of concerns provides an additional layer of security and flexibility. The federated principal is mapped to a service account that possesses the minimum necessary permissions required for the specific Terraform operations being performed. This setup allows for much easier revocation and fine-grained access control, as the permissions are tied to the Google service account rather than the external federation itself. Moreover, using impersonation ensures that all actions taken by the CI runner are logged under the service account’s identity in Google Cloud’s audit logs, providing clear visibility into which automated processes are making changes to the infrastructure.
3. Execution Sequence for Cross-Cloud Deployment
The actual execution of a deployment follows a precise sequence of events that begins within the AWS-hosted CI runner. First, the runner fetches temporary AWS credentials for its assigned IAM role through the standard metadata service or web identity mechanism. Once these credentials are in place, the Google authentication library or a specialized configuration file generates a signed AWS request that serves as a proof of identity. This request is sent to Google Cloud’s Security Token Service, which performs a rigorous validation process. The service checks not only the validity of the signature but also evaluates pre-defined attribute conditions, such as ensuring the request originated from the correct AWS account ID and role name. This ensures that only authorized workloads from the specific AWS environment can attempt to bridge into the Google Cloud project, preventing unauthorized access from other external sources.
Once the federation is validated, the process moves into the identity assumption phase where the federated principal is granted the authority to impersonate the designated Google Cloud service account. The Terraform Google provider, configured with a special credential configuration JSON, handles this exchange transparently. It receives a short-lived OAuth 2.0 access token that is valid for a limited window, typically one hour or less. Armed with this token, Terraform can then execute the planned operations against the Google Cloud APIs to create, modify, or delete resources. Simultaneously, Terraform continues to use its native AWS credentials to communicate with the Amazon S3 backend, ensuring that the state file is updated in real-time as changes are applied to Google Cloud. This dual-authentication flow allows the deployment to proceed smoothly, bridging two distinct cloud providers without the need for a single permanent secret ever being stored or transmitted.
4. Critical Implementation Best Practices
Successfully implementing a keyless CI/CD pipeline requires attention to several technical details that are often overlooked in high-level documentation. One such detail is the pre-initialization of credentials within the Kubernetes environment. It is essential to ensure that the web identity credentials, which are typically materialized as environment variables and files by the Kubernetes IAM roles for service accounts feature, are fully available before Terraform starts its execution. Failure to do so can lead to metadata timeout issues or authentication errors, especially during periods of high cluster load. Furthermore, to keep the CI runner images as lightweight and secure as possible, it is advisable to minimize external dependencies. Rather than installing the full Google Cloud CLI on every runner, teams should utilize the Terraform Google provider’s native ability to perform the Workload Identity Federation exchange using a static configuration file, which significantly reduces the image size and the potential for software vulnerabilities.
Another critical best practice involves layers of network security that complement the identity-based authentication. While Workload Identity Federation is inherently secure, implementing IP allowlisting on the Google Cloud side adds an extra layer of defense-in-depth. By restricting the authentication requests to the specific NAT gateway addresses used by the AWS Kubernetes cluster, organizations can ensure that even if a credential configuration were somehow leaked, it could not be used from an unauthorized network. Additionally, the operational “kill switch” must be verified regularly. Testing how quickly access is terminated after disabling a service account or a workload identity pool is vital for incident response planning. In most cases, existing tokens may remain valid for a few minutes, so understanding this window of exposure allows security teams to create more effective runbooks for mitigating potential breaches in a multi-cloud context.
5. Navigating the Migration and Cleanup Process
The transition to a formal, keyless Terraform pipeline often reveals a significant amount of “technical debt” in the form of manual infrastructure changes that were made over previous years. Cleaning up these legacy modifications is frequently the most time-consuming phase of the project. The first step involves reorganizing the state objects in Amazon S3 to follow a standardized and predictable directory structure. This reorganization is not merely cosmetic; it ensures that the CI/CD pipeline can programmatically locate and manage state files without manual intervention. Following this, every Terragrunt or Terraform configuration unit must be updated to point to the new, corrected S3 keys. This process requires a meticulous verification of state integrity to confirm that no critical data was lost or corrupted during the move, which could otherwise lead to the accidental destruction of production resources during the next deployment cycle.
In addition to state cleanup, the migration process necessitates the calibration of security policy engines that may have been originally designed for a single-cloud environment. Risk-scoring thresholds and automated compliance checks must be adjusted to account for Google-specific resources and the unique behaviors of the Workload Identity Federation. For instance, some security scanners might flag the absence of service-account keys as an error if they are not specifically configured to recognize the keyless model as a superior alternative. Calibrating these engines prevents the CI/CD pipeline from blocking legitimate changes and ensures that the security posture remains consistent across both AWS and Google Cloud. This phase of the project is often an iterative one, where policy rules are refined based on real-world deployment data to strike the right balance between strict security enforcement and developer productivity in a complex multi-cloud ecosystem.
6. Final Takeaways and Operational Realities
The project teams discovered that a comprehensive audit of existing infrastructure was the most reliable way to avoid delays during the implementation of keyless CI/CD. Many legacy environments contained manual “laptop-driven” changes that were not reflected in the state files, creating hidden work that only became apparent once the automation was enforced. By conducting these audits early, the engineers were able to provide more accurate estimates and avoid the common pitfalls of migrating undocumented resources. Furthermore, the use of working audit logs and negative test results proved to be an invaluable tool when seeking approval from security and compliance departments. Demonstrating that an unauthorized AWS role could not gain access to Google Cloud resources provided the concrete evidence needed to build trust in the new federated identity model and accelerated the overall adoption of the technology.
Operationalizing the revocation process was another area where the project delivered lasting value. The teams established that granting access should never occur without a documented and tested runbook for taking that access away. This included not only disabling service accounts but also understanding the nuances of how Workload Identity Federation pools behave when they are deleted. For example, it was noted that these pools often remain in a “soft-deleted” state for 30 days, which can prevent the immediate reuse of certain names and requires specific cleanup procedures. Finally, ensuring that all proof-of-concept environments were fully decommissioned prevented the accumulation of “cloud sprawl” and reduced the long-term maintenance burden. These lessons learned provided a solid foundation for future infrastructure initiatives, ensuring that the move to a keyless, multi-cloud architecture was a permanent improvement rather than a temporary experiment.
