Desafio 7: Cross-account Deployments via Access Entries

Objetivo

Configurar o ArgoCD EKS Capability em uma conta AWS (hub) para fazer deploy de aplicações em um cluster EKS em outra conta AWS (spoke), sem usar IRSA nem role chaining.

Em arquiteturas multi-conta, o padrão tradicional para o ArgoCD self-managed acessar clusters em outras contas envolve IRSA, trust policies entre contas, e role assumption chains - configuração complexa e propensa a erros.

O EKS Capabilities simplifica radicalmente isso. Como o ArgoCD roda no control plane da AWS, o acesso cross-account é feito diretamente via EKS Access Entries: você adiciona o ARN da IAM Capability Role da conta hub como principal no cluster da conta spoke. Sem VPC peering, sem Transit Gateway, sem role chaining.

O ArgoCD gerencia a conectividade automaticamente - inclusive para clusters com API endpoint privado.

Requisitos

Conta A (hub): cluster EKS com ArgoCD Capability habilitado
Conta B (spoke): cluster EKS alvo do deploy
Access Entry no cluster spoke autorizando a Capability Role da conta hub
Cluster spoke registrado no ArgoCD via Secret com o ARN do cluster
Deploy de uma aplicação no cluster spoke validado via UI

Desafio

Configure o Access Entry na conta spoke e registre o cluster no ArgoCD da conta hub. Faça o deploy de uma aplicação e valide que ela está rodando no cluster da conta B.

Dica: O Access Entry usa o ARN da Capability Role da conta hub como principal. Para produção, evite AmazonEKSClusterAdminPolicy - crie uma policy customizada com apenas as permissões necessárias para o ArgoCD deployar nos namespaces alvo.

Ver solução

Solução

1. Obter o ARN da Capability Role (conta hub)

# Na conta hub
aws iam get-role --role-name ArgoCD-Capability-Role \
  --query 'Role.Arn' --output text
# Resultado: arn:aws:iam::HUB_ACCOUNT_ID:role/ArgoCD-Capability-Role

2. Criar Access Entry no cluster spoke (conta B)

# Na conta spoke (B)
aws eks create-access-entry \
  --cluster-name meu-cluster-spoke \
  --principal-arn arn:aws:iam::HUB_ACCOUNT_ID:role/ArgoCD-Capability-Role \
  --type STANDARD

# Associar policy de admin (simplificado para lab)
aws eks associate-access-policy \
  --cluster-name meu-cluster-spoke \
  --principal-arn arn:aws:iam::HUB_ACCOUNT_ID:role/ArgoCD-Capability-Role \
  --policy-arn arn:aws:eks::aws:cluster-access-policy/AmazonEKSClusterAdminPolicy \
  --access-scope type=cluster

3. Registrar cluster spoke no ArgoCD (conta hub)

# Obter ARN do cluster spoke
SPOKE_ARN=$(aws eks describe-cluster \
  --name meu-cluster-spoke \
  --profile conta-spoke \
  --query 'cluster.arn' --output text)

apiVersion: v1
kind: Secret
metadata:
  name: cluster-spoke-contab
  namespace: argocd
  labels:
    argocd.argoproj.io/secret-type: cluster
    env: prod
    account: spoke
type: Opaque
stringData:
  name: spoke-prod
  server: arn:aws:eks:us-east-1:SPOKE_ACCOUNT_ID:cluster/meu-cluster-spoke

kubectl apply -f cluster-spoke.yaml

4. Validar registro

# Na UI: Settings > Clusters - o cluster spoke deve aparecer como Connected
# Via CLI:
argocd cluster list

5. Deploy de aplicação no cluster spoke

apiVersion: argoproj.io/v1alpha1
kind: Application
metadata:
  name: app-cross-account
  namespace: argocd
spec:
  project: default
  source:
    repoURL: https://github.com/argoproj/argocd-example-apps.git
    path: guestbook
    targetRevision: HEAD
  destination:
    name: spoke-prod
    namespace: guestbook
  syncPolicy:
    automated: {}
    syncOptions:
    - CreateNamespace=true

Por que não precisa de VPC peering

O ArgoCD EKS Capability roda no control plane da AWS, não nos seus worker nodes. A AWS gerencia a conectividade entre o serviço e os clusters alvo - incluindo clusters com API endpoint 100% privado. Isso elimina toda a complexidade de networking que seria necessária com ArgoCD self-managed.

Produção: least-privilege no Access Entry

Em vez de AmazonEKSClusterAdminPolicy, crie um ClusterRole restrito:

apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRole
metadata:
  name: argocd-deploy
rules:
- apiGroups: ["apps", ""]
  resources: ["deployments", "services", "configmaps", "namespaces"]
  verbs: ["get", "list", "watch", "create", "update", "patch", "delete"]

Próximos Passos

Configurar Access Entries com ClusterRole customizado por namespace para least-privilege real em produção
Usar AWS Organizations para automatizar a criação de Access Entries em novos clusters spoke
Combinar com o desafio de Fleet Management para ver como cross-account funciona em escala