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 /home/node/.aws read-only justamente por isso — /home/node é o $HOME do usuário da imagem (node, uid 1000), e é de lá que a cadeia default do SDK resolve o cache do SSO. 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”.

Montar no $HOME errado dá o mesmo sintoma: Could not load credentials from any providers, que se lê como credencial expirada e é caminho de arquivo.

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.

Magalu Cloud

Aqui o desenho não é irmão dos outros dois, e a diferença é de postura, não de conveniência.

A MGC autentica por chave de API (header X-API-Key). Não há análogo de cadeia de credencial — nada equivalente a IRSA na AWS ou Workload Identity no GCP —, então não existe RUNNER_MGC_CRED_MODE: só a chave estática, lida do secret manager do cliente. Inventar um modo que não existe seria pior que a ausência.

MGC_API_KEY=…
MGC_REGION=br-se1        # opcional; a região vive na URL, um runner atende uma região
MGC_TENANT_ID=…          # opcional; evita uma chamada no boot
MGC_S3_ACCESS_KEY=…      # object storage; é o `key_pair_id` da MESMA chave
MGC_S3_SECRET_KEY=…      # object storage; é o `key_pair_secret` da MESMA chave

Os escopos são o controle, e são imutáveis

Uma API key do ID Magalu carrega três componentes: api_key (o que o RootPilot usa no header X-API-Key), key_pair_id e key_pair_secret — que juntos são a credencial S3 do Object Storage e viram o MGC_S3_ACCESS_KEY/MGC_S3_SECRET_KEY acima.

Criar a key pelo console marcando “tudo” gera cerca de 160 escopos da conta inteira, incluindo billing e IAM. Crie pela CLI com --scopes explícitos e conceda apenas leitura — um escopo de leitura por produto que o RootPilot vai ler:

Produto	O que o RootPilot lê
Virtual machine (virtual-machine.read)	instâncias e seus IPs
Network (network.read)	VPCs, subnets, security groups, IPs públicos, NAT, load balancers
Object storage (object-storage.read)	buckets e postura de exposição
Block storage	volumes, anexação e criptografia
DBaaS	instâncias, clusters e réplicas de banco
Kubernetes (MKE)	clusters, node pools e quem alcança o API server
Container registry	registries, repositórios e imagens
Auditoria	quem fez o quê, quando e sobre qual recurso

Os identificadores dos quatro últimos saem da própria listagem de escopos do console/CLI — não os adivinhe a partir dos três primeiros. Uma chave sem o escopo de um produto não quebra o RootPilot: só as leituras daquele produto voltam auth_error, e o resto do connector segue servindo. O efeito prático é que o produto fica invisível sem barulho nenhum, então vale conferir a lista acima contra o que você espera ver.

Isso é melhor do que parece: a postura read-only do RootPilot passa a estar enforçada na credencial, não só no código. O connector recusa escrita, e a chave nem a permite. Escopo não é editável depois — mudou a necessidade, recria a key.

O par S3 sem o escopo assina perfeitamente — e leva AccessDenied em tudo

key_pair_id/key_pair_secret existem em toda API key, tenha ela object-storage.read ou não. Sem o escopo, o par continua assinando SigV4 válido e cada operação de bucket volta AccessDenied — o que se lê como credencial errada quando é autorização faltando.

E como escopo é imutável, o conserto não é editar a chave: é criar chave nova e rotacionar. Foi exatamente o que aconteceu na nossa própria frota quando o object storage entrou (a chave só de compute+network virou uma v2, e a antiga foi revogada no mesmo dia). Decidir isto na criação custa um minuto; decidir depois custa uma rotação.

Sem as duas variáveis, os buckets somem em silêncio

MGC_S3_ACCESS_KEY e MGC_S3_SECRET_KEY são opcionais no manifesto, de propósito: sem elas as seis operações de storage falham com auth_error e o resto do connector segue servindo — o boot não reclama e o Fleet mostra mgc verde. Ou seja, esquecê-las não derruba nada: só deixa os seus buckets invisíveis, sem barulho nenhum. Se o RootPilot disser que não enxerga object storage, comece por aqui.

Contexto derivado no boot

O análogo de “conta” na MGC é o tenant_id, que aparece em VPC, security group e IP público. Não existe “project”.

Diferente do GCP, ele não sai de graça: a API key é opaca, e não há metadata server de workload identity. Então o runner usa MGC_TENANT_ID quando ele está definido e, na ausência, deriva de uma listagem de VPC — uma chamada, best-effort. Sem chave, sem VPC ou com a chamada falhando, nenhuma conta é anunciada, e o control-plane cai no fallback de configuração. Ele nunca inventa um id: anunciar uma conta inexistente faria o roteamento mandar leitura para um lugar que não responde.

IP público sobrevive ao destroy da VM

Na MGC o IP público fica alocado (e cobrando) depois que a VM some, e continua respondendo a ping — então o teste barato não denuncia. A operação network.listMgcPublicIps marca esses casos com orphaned: true.

Variáveis relacionadas

Variável	Notas
AWS_REGION	Usada pelos connectors AWS e obrigatória na atestação aws-sts.
MGC_API_KEY	Chave de API da Magalu Cloud. Crie com escopos de leitura — um por produto que o RootPilot vai ler (ver a tabela acima).
MGC_REGION	br-se1 (default) ou br-ne1. Vive na URL: um runner atende uma região.
MGC_TENANT_ID	Evita a chamada de descoberta no boot. Recomendado em produção.
MGC_S3_ACCESS_KEY	O key_pair_id da mesma API key. Object storage fala S3 (SigV4) contra outro host — outra credencial, mesmo dono. Opcional: sem ela os buckets ficam invisíveis, sem erro no boot.
MGC_S3_SECRET_KEY	O key_pair_secret da mesma API key. Quem autoriza as leituras de bucket é o escopo object-storage.read da MGC_API_KEY, não este par.
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.