IAM Roles Anywhere e PKI: boas práticas para dar identidade a workloads fora da AWS

O ponto central do guia da AWS é simples: cada workload fora da AWS precisa de identidade própria. Isso significa um certificado X.509 exclusivo, assinado pela sua CA, com atributos distintos, e uma IAM role separada para cada um. O IAM Roles Anywhere valida emissor e subject, e extrai Common Name, emissor e Subject Alternative Name para uso em políticas, via sts:sourceIdentity e principal tags. Um detalhe que pega gente desprevenida: Subject CN vazio não é suportado.

A parte de defesa está no detalhe. Certificados de validade curta reduzem a janela de exposição e diminuem a necessidade de revogação ativa. A posição do trust anchor na hierarquia da CA define quais certificados são aceitos. As permissões efetivas das credenciais são a interseção de políticas de recurso, de identidade e de sessão. Para a chave privada, o credential helper integra PKCS #11 (a partir da versão 1.1.0) e TPM 2.0 (desde dezembro de 2024), com chaves não exportáveis. No AWS CLI, a AWS recomenda o comando serve em vez de update, porque update grava credenciais em disco. O serve entrega as credenciais por um endpoint local no padrão IMDSv2.

O post chega após uma sequência de novidades da AWS em identidade e certificados. Em 1 de julho de 2026, o CEVIU noticiou o suporte do ACM ao protocolo ACMEv2 para emissão e renovação automáticas de certificados TLS públicos, em qualquer workload. A nota do post atual liga isso ao Roles Anywhere: o X.509 dá a identidade, o ACM cuida da criptografia em ambientes híbridos.

Credenciais estáticas continuam sendo um vetor clássico de vazamento, como o CEVIU já apontou na matéria de 9 de fevereiro de 2026 sobre abandonar credenciais estáticas. Com Roles Anywhere e uma PKI bem desenhada, servidores on-premises e contêineres passam a usar credenciais temporárias, com escopo mínimo por workload. Se você já emite certificados (por exemplo, via Active Directory Certificate Services), o caminho pode ser curto.