O que é o IAM?
É um dos principais serviços da AWS, responsável por prover uma autenticação base para diversos componentes dos nossos ambientes na nuvem. A sigla significa “Gerenciamento de Acesso de Identidade”.
De forma geral, ele será o serviço fundamental para definirmos os controles de autenticação e autorização dentro da nossa infraestrutura para acessar os serviços da AWS. Podemos dizer que o serviço IAM é a primeira parada para iniciar a nossa jornada na nuvem.
Componentes do IAM
Temos alguns componentes chaves que nos fornecem os insumos necessários para gerenciar os acesso para os serviços na AWS. Entender a relação entre eles é o primeiro passo para dominar a gestão de identidade, concedendo e gerenciando permissões para manter o ambiente seguro dentro da nuvem da Amazon.
- Policies: É uma espécie de documento escrito no formato JSON onde colocamos as definições que nos permitirão acessar os serviços da AWS.
- Usuários: Os usuários servem para que possamos realizar login no console para utilizar os serviços da AWS. Através deles podemos obter outras credencias de acesso para interagir com a API da AWS através da linha de comando ou um SDK. Por padrão um usuário do IAM não possui nenhuma permissão para executar operações na nuvem.
- Grupos: Os grupos atuam como uma maneira de organizar melhor o nosso ambientes, agrupando todas as policies em comum a serem distribuídas para um grupo de usuários. Ao invés de colocarmos cada policie individualmente nos usuários, a boa prática é criar um grupo com as permissões adequadas e colocar todos os usuários necessários lá dentro. Desta forma, mantermos o controle e a organização do nosso ambiente.
- Roles: As roles são recursos especiais que nos permitem utilizar credenciais de acesso temporário para interagir com os serviços da AWS. A role pode ser assumida por um usuário do IAM, um código de aplicação e até mesmo por outros serviços da AWS como EC2, Lambda, etc.
Interação com a API dos serviços
É através de Usuários e Roles que interagimos diretamente com as APIs dos serviços da AWS. Podemos até dizer que estes recurso são como uma espécie de operadores(como operadores de equipamentos), no sentido que são eles os acionadores que disparam chamadas para interagirmos com as APIs da AWS para que uma ação seja realizada, como criar um bucket no S3.
Tanto usuários quanto serviços da AWS podem utilizar Roles para interagir com a API de outros serviços. A principal vantagem de utilizar Roles é que elas nos fornecem credenciais temporárias para executar as operações na AWS. Desta forma deixamos o no nosso ambiente mais seguro graças ao rotacionamento automático das credenciais.
Ex: Uma instância do EC2 poderia usar uma Role para publicar mensagens em uma fila do serviço Amazon SQS.
Ao invés de configurarmos uma Access Key e uma Secret Key como acontece com usuários do IAM, usamos as Roles anexadas diretamente ao recurso(EC2) para que ele tenha a permissão necessária para conseguir interagir com a API do Amazon SQS.
Todo o ciclo de vida das credenciais geradas pela Role são tratados de forma automática pela AWS. Por padrão as credencias são válidas durante 1h mas esse tempo pode ser ajustado para mais algumas horas. Uma vez que o tempo de vida da credencial vai chegando ao fim, o próprio recurso onde ela está sendo executada se encarrega de gerar uma nova para que as operações possam continuar sendo executadas sem problemas. Tudo isso de forma totalmente transparente para quem está utilizando.
Em um cenário da vida real seguindo as boas práticas da AWS, as policies estariam anexadas aos grupos, que por sua vez estariam associados aos usuários para que eles pudessem fazer uma chamada para a API de um serviço como na imagem a cima. Da mesma forma, as policies são anexadas às roles para que elas também consigam realizar chamadas de API para os serviços.
Mas na prática, qual é a utilidade das Roles?
Por mais que uma mesma pessoa possa desempenhar uma mescla desses papeis, a ideia é que isso seja evitado. Quando dividimos as especialidades podemos nos dedicar de uma forma mais focada naquilo que precisamos entregar e conseguimos atuar de uma forma mais precisa e organizada já que o número de atribuições fica em um escopo mais reduzido.
Consequentemente por cada grupo desempenhar um papel, seu nível de acesso será diferente. Um Engenheiro, um Carpinteiro e um Pedreiro, por mais que todos façam parte da mesma obra, desempenham atividades diferentes. Isso também é refletido no controle de acesso.
Um microserviço responsável por processar pedidos de compra de um e-commerce que estão armazenados em uma fila do SQS deveria utilizar uma Role exclusiva para este fim e não compartilhar este mesmo acesso com mais ninguém. Não importa se forem usuários, outros serviços de infraestrutura ou mesmo outras aplicações.
Além disso, como as credencias são renovadas de tempos em tempos, o ambiente acaba se tornando mais seguro por padrão e de quebra não precisamos ficar nos preocupando em configurar chaves de acesso que podem ser vazadas e utilizadas de forma mais fácil por agentes maliciosos.