Learn GitOps with ArgoCD - Cloud Provider Specific Patterns

#Introduction

In episode 30 the ecosystem was connected. But there's one layer we haven't touched specifically: who runs the cluster. EKS, GKE, and AKS each have different authentication mechanisms, ingresses, secret managers, and registries. The same GitOps patterns still apply — Git as the truth, ArgoCD as the reconciler — but how they're realized differs on each cloud.

This episode maps the three major clouds, then closes with multi-cloud patterns. The goal isn't an encyclopedia, but a way of thinking: how cloud-agnostic abstractions keep Git clean even when the cloud behind it differs.

#AWS EKS

Before starting, make sure kubectl points to the right cluster: aws eks update-kubeconfig --name eks-prod --region ap-southeast-1.

#IRSA (IAM Roles for Service Accounts)

IRSA maps a Kubernetes Service Account to an IAM Role — pods using that SA automatically get AWS credentials via OIDC. This is the safe way to give ArgoCD access to AWS resources (e.g. for Image Updater or plugins):

apiVersion: v1
kind: ServiceAccount
metadata:
  name: argocd-repo-server
  namespace: argocd
  annotations:
    eks.amazonaws.com/role-arn: arn:aws:iam::123456789012:role/argocd-repo-role

ArgoCD uses IRSA to: pull images from ECR without static credentials, read Helm values from SSM Parameter Store, or write update results to S3. No secrets are written to Git — credentials follow the SA.

#ALB Ingress Controller

Access to the ArgoCD UI/API on EKS usually goes through the AWS Load Balancer Controller (ALB). The AWS IngressClass resource and Ingress annotations create an Application Load Balancer:

apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  name: argocd-server
  namespace: argocd
  annotations:
    kubernetes.io/ingress.class: alb
    alb.ingress.kubernetes.io/ssl-policy: ELBSecurityPolicy-TLS-1-2
    alb.ingress.kubernetes.io/listen-ports: '[{"HTTPS": 443}]'
spec:
  rules:
    - host: argocd.example.com
      http:
        paths:
          - path: /
            pathType: Prefix
            backend:
              service:
                name: argocd-server
                port:
                  number: 80

#External Secrets: AWS Secrets Manager

A natural integration with the External Secrets Operator (episode 12): a SecretStore points to Secrets Manager using IRSA credentials, and an ExternalSecret mounts secrets into ArgoCD without ever storing them in Git.

#ECR

For images in Amazon Elastic Container Registry, Image Updater (episode 16) or Tekton only needs temporary credentials from IRSA. ECR requires a token that lasts 12 hours — don't store it as a static secret; let IRSA handle it, or use the ecr-login helper in CI.

#GCP GKE

First grab the cluster credentials: gcloud container clusters get-credentials gke-prod --region asia-southeast1.

#Workload Identity

Workload Identity connects a Kubernetes Service Account with a Google Service Account. Pods using that SA are automatically authenticated to GCP:

apiVersion: v1
kind: ServiceAccount
metadata:
  name: argocd
  namespace: argocd
  annotations:
    iam.gke.io/gcp-service-account: argocd-prod@gcp-project.iam.gserviceaccount.com

Its usage pattern is the same as IRSA: the repo server pulls from Artifact Registry, reads values from Secret Manager, with no static secrets.

#GKE Ingress

GKE offers two ingress classes: GKE Ingress (native, global load balancer) and Ingress NGINX (in-cluster controller). For ArgoCD, NGINX is more flexible for features like rate limiting and custom annotations; GKE Ingress excels at large scale and Cloud Armor integration. Choose by need, but make sure the configuration lives in Git.

#GCP Secret Manager

Same as AWS: a SecretStore + ExternalSecret pointing to GCP Secret Manager. Because Workload Identity already provides access, no credentials are stored.

#Artifact Registry

GCR is being retired; Artifact Registry is its successor. ArgoCD integration: Image Updater detects new images in Artifact Registry, commits to Git, ArgoCD syncs.

#Azure AKS

Connect kubectl to the cluster: az aks get-credentials --resource-group rg-prod --name aks-prod.

#Azure AD Integration

AKS integrates Azure AD for authentication. For ArgoCD, use OIDC: point ArgoCD at Azure AD (or Dex forwarding to AD) so ArgoCD login uses the corporate identity. Azure AD RBAC can map groups to ArgoCD projects (episode 10).

#Application Gateway Ingress

AKS commonly uses the Application Gateway Ingress Controller (AGIC) — Azure Application Gateway as the ingress, with the benefit of direct WAF (Web Application Firewall) integration:

metadata:
  annotations:
    kubernetes.io/ingress.class: azure/application-gateway
    appgw.ingress.kubernetes.io/backend-protocol: http
spec:
  tls:
    - hosts:
        - argocd.example.com

#Azure Key Vault

Key Vault is connected to the cluster via the AKS Secret Store CSI add-on or External Secrets Operator with the Azure KeyVault provider. ArgoCD secrets (e.g. repo credentials) are referenced from Key Vault.

#ACR (Azure Container Registry)

The standard AKS registry. Same as other clouds: let pods pull via managed identity (AAD Pod Identity or Workload Identity for AKS), and Image Updater handles updates.

#Multi-Cloud Patterns

#Unified GitOps Across Clouds

A pattern consistent across all clouds: one manifest repo, one ArgoCD hub, many target clusters. EKS, GKE, and AKS clusters are all registered as destinations in ArgoCD (episode 9). The same manifests are deployed to all clusters — cloud differences only exist in the lower layers (storage class, ingress, etc.), handled through a Kustomize overlay or per-cluster Helm values (episode 8).

#Cloud-Agnostic Abstractions

The key to multi-cloud is don't write cloud-specific configuration into application manifests. Use:

• Crossplane (episode 29) with a Composition selected per cloud — the same claim can be realized as RDS on AWS, Cloud SQL on GCP, or Azure SQL.
• CSI drivers as the storage abstraction — select the storage class per cluster via overlay, not hardcoded.
• Ingress abstraction — application manifests just mention Ingress; the per-cloud implementation lives in the platform layer, not in the application.

#Cross-Cloud DR

For cross-cloud disaster recovery (episode 21): an ArgoCD hub in cluster A manages cluster B as an active-passive target. Because manifests are identical and Git is the truth, failover = changing DNS routing + making sure cluster B is fully synced. Practice DR drills periodically — behavior differences between clouds (e.g. CIDR, quotas, latency) only show up when actually tested.

#Closing

This episode mapped per-cloud patterns: AWS EKS with IRSA, ALB Ingress, Secrets Manager, and ECR; GCP GKE with Workload Identity, GKE/NGINX Ingress, Secret Manager, and Artifact Registry; Azure AKS with Azure AD, Application Gateway, Key Vault, and ACR; plus multi-cloud patterns with one Git, an ArgoCD hub, cloud-agnostic abstractions, and cross-cloud DR.

The points you should take with you:

• Cloud credentials should follow the workload identity (IRSA, Workload Identity, managed identity), not static secrets.
• External Secrets + cloud Secret Manager = secrets never enter Git.
• Abstractions (Crossplane, CSI, Ingress) keep manifests cloud-agnostic.
• Multi-cloud requires validating behavior, not just manifests.

These patterns are ready to use in your organization. The last step before full scale is arranging them as policy and culture. In the next episode 32 we discuss enterprise patterns & best practices — platform team structure, repository strategies, environment management, change management, and runbook documentation. See you in episode 32!