luizmachado.dev

AWS IAM Policy Autopilot: criando políticas IAM direto do Kiro

AWS IAM Policy Autopilot: criando políticas IAM direto do Kiro

Criar políticas IAM na mão é uma daquelas tarefas que todo mundo sabe que precisa fazer direito, mas que na prática acaba virando um copia e cola de "Effect": "Allow", "Action": "*" só pra "funcionar por enquanto". O problema é que esse "por enquanto" vira permanente.

O AWS IAM Policy Autopilot veio pra resolver isso. Lançado como ferramenta open source na re:Invent 2025, ele analisa seu código estaticamente e gera políticas IAM baseadas no que sua aplicação realmente precisa. E desde fevereiro de 2026, ele está disponível como Kiro Power, o que significa instalação com um clique e integração direta no seu fluxo de desenvolvimento.

O que é o IAM Policy Autopilot?

É uma ferramenta de análise estática de código que lê seu código fonte, identifica quais serviços e ações da AWS ele utiliza e gera uma política IAM base com as permissões necessárias.

Na prática, ele faz o trabalho chato por você:

  • Escaneia o código procurando chamadas a SDKs da AWS
  • Identifica quais actions (s3:GetObject, dynamodb:PutItem, etc.) são usadas
  • Gera uma política IAM com essas permissões como ponto de partida
  • Você refina conforme o projeto evolui

O ponto importante aqui: ele gera uma política base, não uma política final. A ideia é te dar um starting point muito melhor do que começar do zero ou copiar uma policy genérica.

Por que isso importa?

O problema do "Allow *"

Quantas vezes você já viu (ou escreveu) algo assim?

{

  "Effect": "Allow",


  "Action": "*",


  "Resource": "*"


}

Funciona? Funciona. É seguro? Nem um pouco. Esse tipo de policy viola o princípio de least privilege e é um dos achados mais comuns em auditorias de segurança.

O problema é que criar policies granulares dá trabalho. Você precisa saber exatamente quais actions sua aplicação usa, quais resources ela acessa e em quais condições. O Autopilot automatiza a parte mais tediosa desse processo.

O custo de policies mal configuradas

Policies excessivamente permissivas são porta de entrada pra:

  • Escalação de privilégios: um atacante que compromete uma role com * tem acesso a tudo
  • Movimentação lateral: de um serviço comprometido, o atacante alcança outros
  • Exfiltração de dados: acesso irrestrito a S3, DynamoDB, Secrets Manager

O Autopilot não resolve todos esses problemas sozinho, mas reduz drasticamente a chance de você começar com permissões excessivas.

Como funciona como Kiro Power

Antes do Kiro Power, usar o Autopilot exigia configurar um servidor MCP manualmente, instalar dependências e integrar na sua IDE. Agora o processo é:

  1. Instalação com um clique direto do Kiro IDE ou da interface web
  2. Sem configuração de MCP manual
  3. Integrado ao fluxo de desenvolvimento, você gera policies sem sair do editor

Fluxo de uso

O workflow fica assim:

  1. Você está escrevendo código que usa serviços AWS (Lambda que lê do S3, por exemplo)
  2. Pede pro Kiro gerar a policy IAM
  3. O Autopilot analisa o código e identifica as actions necessárias
  4. Ele gera a policy base
  5. Você revisa, ajusta resources e conditions, e aplica

Tudo isso sem sair do Kiro, sem abrir o console da AWS, sem consultar a documentação de IAM actions.

Casos de uso práticos

Prototipagem rápida

Você está criando um novo projeto e precisa de uma role pra Lambda. Em vez de chutar as permissões, deixa o Autopilot analisar o código e gerar a policy. Mesmo que seja um protótipo, já começa com permissões razoáveis.

Novos projetos AWS

Quando o projeto é novo, você ainda não tem histórico no CloudTrail pra usar ferramentas como o IAM Access Analyzer. O Autopilot preenche essa lacuna porque trabalha com análise estática, não precisa de dados de runtime.

Refatoração de policies existentes

Tem uma role com permissões excessivas e quer apertar? Rode o Autopilot no código que usa essa role e compare a policy gerada com a atual. A diferença mostra o que pode ser removido.

Code review de segurança

Durante um review, em vez de verificar manualmente se a policy está alinhada com o código, use o Autopilot pra gerar a policy esperada e compare com a que está no PR.

Limitações e cuidados

Como toda ferramenta de análise estática, o Autopilot tem limitações que você precisa conhecer:

Análise estática não é completa: se seu código constrói nomes de actions dinamicamente ou usa reflection, o Autopilot pode não capturar tudo. Resources precisam de refinamento: a ferramenta identifica actions, mas os ARNs dos resources geralmente precisam ser ajustados manualmente. Ela pode gerar "Resource": "*" pra uma action onde você deveria restringir a um bucket específico. Conditions não são geradas automaticamente: conditions como aws:SourceAccount, aws:SourceArn ou restrições por IP precisam ser adicionadas por você. Não substitui o IAM Access Analyzer: o Autopilot trabalha com o que o código diz que precisa. O Access Analyzer trabalha com o que realmente foi usado em produção. O ideal é usar os dois: Autopilot no desenvolvimento, Access Analyzer em produção.

Autopilot + Access Analyzer: o combo ideal

Um workflow maduro de IAM combina as duas ferramentas:

  1. Desenvolvimento: Autopilot gera a policy base a partir do código
  2. Deploy: a policy vai pra produção com permissões razoáveis (não excessivas)
  3. Produção: IAM Access Analyzer monitora quais permissões são realmente usadas
  4. Refinamento: com dados do Access Analyzer, você aperta a policy removendo o que não foi usado

Esse ciclo garante que suas policies começam boas e ficam melhores com o tempo.

Como começar

O repositório do projeto está no GitHub: awslabs/iam-policy-autopilot

Pra usar como Kiro Power:

  1. Acesse a página de Kiro Powers
  2. Encontre o IAM Policy Autopilot
  3. Instale com um clique
  4. Abra seu projeto no Kiro e peça pra gerar a policy

Conclusão

O IAM Policy Autopilot como Kiro Power é daquelas integrações que fazem sentido imediato. Criar policies IAM é uma tarefa que todo dev AWS precisa fazer, poucos fazem bem, e a maioria posterga. Ter isso integrado direto no editor, com um clique, remove a fricção e aumenta a chance de você começar com permissões adequadas desde o primeiro deploy.

Não é uma bala de prata. Você ainda precisa revisar, ajustar resources, adicionar conditions e monitorar em produção. Mas o ponto de partida muda completamente: de "Action": "*" pra uma policy que reflete o que seu código realmente faz.

awsiamkirosegurançadevopsia