Credenciais de nuvem

Os connectors de AWS e GCP precisam de credencial de nuvem para ler. Há dois modos, e eles são ortogonais ao secret store: aquele decide onde os segredos vivem, este decide como a credencial de nuvem é resolvida.

RUNNER_AWS_CRED_MODE=static   # default
RUNNER_AWS_CRED_MODE=chain

RUNNER_GCP_CRED_MODE=static   # default
RUNNER_GCP_CRED_MODE=chain

AWS

static: o default

Lê AWS_ACCESS_KEY_ID, AWS_SECRET_ACCESS_KEY e, opcionalmente, AWS_SESSION_TOKEN do secret store e injeta explicitamente no client.

Serve quem recebe chaves prontas ou as guarda no Vault ou no Secrets Manager. É o default por retrocompatibilidade.

chain: workload identity

Não injeta chave nenhuma. A cadeia de credenciais default do SDK resolve: IRSA no EKS, task role no ECS, instance profile na EC2, variáveis de ambiente, ou o cache de SSO.

É o modo correto quando o runner roda dentro da AWS, e o que evita chave estática circulando.

RUNNER_AWS_CRED_MODE=chain
AWS_PROFILE=meu-profile     # em desenvolvimento, com aws sso login

Em desenvolvimento, chain precisa do volume ~/.aws

O aws sso login escreve o cache em ~/.aws/sso/cache no host, e o profile diz qual usar. O Compose monta ~/.aws em /root/.aws read-only justamente por isso. Sem o volume, o container não vê o cache e a cadeia falha sem dizer que é isso, o clássico “funciona no meu terminal e não no container”.

Quando o token de SSO expirar, rode aws sso login no host. O container passa a ler o cache renovado sem precisar reiniciar.

Uma sutileza que causa connector invisível

O served-set é secret-aware: um connector cujas chaves obrigatórias faltam sai do conjunto anunciado. Mas em chain a credencial não vem do secret store, então, sem tratamento, o runner não anunciaria as operações aws.* mesmo funcionando perfeitamente.

Por isso o runtime marca o connector aws como sempre servido no modo chain. Vale saber que esse caso especial existe, para não estranhar a diferença de comportamento entre os dois modos.

Multi-conta

O modo chain é single-account por construção. Para várias contas AWS, suba um runner por conta, cada um com a sua identidade IRSA. O grafo é fundido do lado do control-plane.

Contexto derivado no boot

Com RUNNER_CONNECTORS=real, o runner faz um probe best-effort de STS no boot para descobrir conta e região, e reporta isso no handshake. É o que permite ao control-plane resolver o contexto AWS do tenant a partir do runner vivo, em vez de configuração manual.

O probe nunca lança. Se falhar, a informação simplesmente não vai, e o control-plane usa o fallback.

GCP

O desenho é o irmão exato do lado AWS.

static: o default

Lê a chave JSON da service account (GCP_SA_KEY, o JSON em uma linha) do secret store e constrói os clients com ela.

chain: Application Default Credentials

Não injeta chave. A ADC resolve: Workload Identity no GKE, metadata na GCE, o arquivo apontado por GOOGLE_APPLICATION_CREDENTIALS, ou o gcloud.

Com chain, o GCP_SA_KEY não é necessário.

RUNNER_GCP_CRED_MODE=chain
GCP_PROJECT_ID=meu-projeto

Também single-projeto: para vários projetos, um runner por projeto, cada um com a sua GSA de Workload Identity.

Variáveis relacionadas

Variável	Notas
AWS_REGION	Usada pelos connectors AWS e obrigatória na atestação aws-sts.
EKS_CLUSTER	Sem ela o health check do EKS responde skipped: no cluster configured. O connector aparece como não-configurado no Fleet, que é diferente de quebrado e igualmente cego.
GCP_PROJECT_ID	Projeto alvo.
GCP_REGION	Região alvo.
GCP_BILLING_EXPORT_TABLE	Tabela de billing-export do BigQuery. Sem ela, a operação de custo do GCP falha de forma explícita.

O connector kubernetes reusa as credenciais da AWS

Ele é acoplado à AWS e declara as mesmas chaves AWS_*. Não há um conjunto separado de credenciais para Kubernetes.