Continuous Delivery to AWS, Azure, Google Cloud, and Kubernetes: Configuration, Design Patterns, and Trade-Offs

1. Design from the deployment boundary inward

The deployment contract should be provider-neutral at its boundary even when the implementation is provider-specific. Inputs usually include artifact name/digest, environment, target identity, rollout policy and health criteria. Outputs include provider deployment/revision ID, deployed digest, health result and rollback handle. The adapter owns authentication and provider syntax; the caller owns the decision that this subject may be promoted to this target.

2. Official action versus provider CLI

Prefer an official authentication action when it narrows and standardizes the token exchange, but do not treat “official” as exemption from SHA pinning, source review or least privilege. The current examples use AWS v6.2.4, Azure Login v3.1.0 and Google Auth v3.0.0 pinned to exact commits.

3. Static credential versus OIDC federation

A static secret may still be necessary for a legacy endpoint that cannot federate. If so, scope it to one disposable or bounded target, store it in the appropriate environment, rotate it, and document an exit plan. Do not keep a permanent admin key as a “fallback” after OIDC migration.

4. Repository/ref trust versus environment trust

A branch-bound OIDC subject answers “which ref requested this credential?” An environment-bound subject answers “which repository job entered this environment boundary?” When production approval and branch/tag restrictions are part of governance, binding provider trust to the production environment often aligns identity with the actual deployment gate. It does not eliminate the need for artifact verification or environment protection.

For repositories using GitHub’s immutable subject format, owner and repository IDs are embedded in the repo segment. Older name-based subjects remain possible. Inspect actual claims in a safe/synthetic manner before writing provider trust.

5. Push deployment versus GitOps handoff

GitOps can shrink cluster credentials in CI because the workflow changes desired state rather than the cluster directly. But a merged manifest or successful API call is only a handoff. Record the commit/reconciliation revision and later target health if you claim deployment completion.

6. Direct kubeconfig versus cloud-federated cluster identity

A raw kubeconfig containing a long-lived token or client certificate is a secret with its own rotation and exfiltration risk. For managed EKS/AKS/GKE, prefer the cloud federation path that authenticates the workflow to the provider and then obtains a short-lived cluster credential using provider-supported tooling. For a local kind lab, the kubeconfig is ephemeral target state created and deleted inside the job.

7. One generic workflow or provider-specific reusable adapters?

A giant workflow full of if: provider == ... branches tends to accumulate broad permissions, provider tools and hidden assumptions. A better architecture is a stable caller contract plus separate reusable adapter workflows such as deploy-aws.yml, deploy-azure.yml, deploy-gcp.yml and deploy-k8s.yml. Each adapter can request only the permissions, runner/toolchain and environment data it needs.

Pin cross-repository reusable workflows to an immutable commit SHA in production. The caller should pass the exact artifact digest explicitly and require the adapter to return target-side identity/health outputs.

8. Rollback policy: target reversal, not artifact rebuild

A rollback selects a previously verified deployment identity. In Kubernetes that may be a prior Deployment revision whose Pod template points to a known-good digest. In a cloud service it may be a previous task definition, revision, slot or version. Rebuilding old source creates new bytes and should be treated as a new release candidate, not a rollback.

9. Worked decisions

10. Cost, latency and plan boundaries

OIDC itself does not make cloud resources free. Managed clusters, egress, build minutes and provider services may incur cost even when authentication is secretless. The mandatory course path remains on a standard GitHub-hosted runner with a local kind cluster. Larger runners, private networking, managed Kubernetes and enterprise environment policies are optional architecture considerations, not prerequisites.

11. Design summary

A durable deployment architecture keeps one narrow provider-neutral contract while allowing each adapter to own its authentication, tooling and target-specific rollout semantics. Federation, environment governance, digest promotion and health evidence stay invariant even when the cloud API changes.

Knowledge check

Official references and version notes

• GitHub OIDC overview — Why short-lived federation is preferred to long-lived cloud secrets.
• OIDC reference — Current claims, immutable subject format, audiences, reusable-workflow behavior and token-request permissions.
• OIDC in AWS — Current AWS trust conditions and official authentication action pattern.
• OIDC in Azure — Current Microsoft Entra workload identity federation pattern.
• OIDC in Google Cloud — Current Workload Identity Federation integration.
• Managing environments — Environment protection, deployment branches/tags, secrets and target governance.
• Deployments and environments — Conceptual distinction between deployment records, environment gates and external target health.
• kind quick start — Pinned local Kubernetes cluster tool used by the free lab.
• kind local registry — Current localhost registry/network model when digest-addressable local images are needed.
• Kubernetes Deployments — Rollout, revision and rollback model.
• kubectl rollout — Status, history, undo and restart operations.