O blog da AWS
Use suas credenciais de usuários IAM de forma mais segura com infraestrutura como código
Por Vinicius Soares Batista é Arquiteto de Soluções da AWS Brasil
Por Allyson Oliveira é Arquiteto de Soluções da AWS Brasil
O AWS Cloudformation e o Terraform são duas ferramentas de infraestrutura como código(IaC), muito utilizadas para criação de recursos em nuvem através de uma base de código comum que pode ser gerenciada pelos times de desenvolvimento e infra durante a implementação de aplicações. Imaginem o time de infra/devops ou SRE terem que criar mais de 20 servidores diferentes, load balancer, configurar security groups, etc? Com infraestrutura como código, tudo isso fica mais padronizado, além de diminuir a possibilidade de erros manuais, como por exemplo, selecionar um tipo de instância diferente do requisitado.
Mesmo com essa facilidade de utilizar infraestrutura como código, não devemos abrir mão da segurança da informação nesse processo de devops e automação. Com isso em mente, existem algumas situações que podem ser implementadas de forma mais segura. Por exemplo:
Quando um novo integrante entra no time, ou você vai começar a criar um novo projeto na AWS, uma das primeiras tarefas do checklist é criar um novo usuário IAM. A maioria dos clientes já possuem um pipeline para isso, seja no Code Pipeline ou qualquer outra ferramenta de CI/CD. Em algumas situações, o resultado final dessa atividade é enviado por e-mail ao novo membro, e aqui já temos um problema de segurança, que é o usuário e senha trafegando por e-mail.
Outra situação comum é quando times compartilham o access key e secret keys do IAM através de ferramentas de comunicação(discord, slack, telegram, etc). Após receber essa senha, é comum que o engenheiro devops (ou quem vai utilizar a ferramenta de infraestrutura como código), executar o comando aws configure no prompt de comando ou terminal:
➜ ~ aws configure
AWS Access Key ID [****************AAAA]:
AWS Secret Access Key [****************1111]:
Default region name [us-east-1]:
Default output format [None]:
Essas informacões ficam salvas no arquivo credentials, localizado por padrão no diretório ˜/.aws/credentials(Linux e MacOS), ou C:\Users\<usuário>\.aws\credentials(Windows).
Notem que temos as credenciais que foram criadas dentro do IAM da AWS expostas em um arquivo da máquina local. Dependendo da situação, ou das politicas IAM que esse usuário possui, isso pode ser uma brecha de segurança, pois permite a execução de comandos não apenas via terraform, mas também utilizando a aws cli.
No terraform, é comum usarem o arquivo de configuração informando o provedor que irá utilizar dessa maneira:
provider "aws" {
region = "us-west-2"
access_key = "my-access-key"
secret_key = "my-secret-key"
}
Nesse exemplo, se uma pessoal mal intencionada conseguir acesso a esse arquivo de configuração do terraform, ele terá acesso ao seu Access Key e Secret Key do usuário IAM da AWS.
Dependendo de como esteja a configuração das permissões dos seus usuários IAM, o dano pode ser grande (especialmente em casos onde a permissão daquele usuário é muito aberta, permitindo por exemplo a exclusão de recursos). Além do problema relatado acima, que pode ser o envio das credenciais através de alguma ferramenta de comunicação, ainda existe a possibilidade desse código ser enviado para um repositório público no github. O mesmo se aplica para o caso abaixo:
provider "aws" {
region = "us-west-2"
shared_credentials_file = "/Users/tf_user/.aws/creds"
profile = "customprofile"
}
Os arquivos estão salvos dentro do diretório informado no campo “shared_credentials_file“, também no dispositivo do usuário – comprometendo a segurança das credenciais.
Uma forma segura de utilizar o arquivo de configuração do provider no terraform com a AWS é utilizando uma Role(função) de usuário:
provider "aws" {
assume_role {
role_arn = "arn:aws:iam::ACCOUNT_ID:role/ROLE_NAME"
session_name = "SESSION_NAME"
external_id = "EXTERNAL_ID"
}
}
Após a configuração, em ambos os casos (Assume Role e Configuração) é possível realizar os comandos terraform (apply, plan, etc) e criar seus recursos dentro da AWS, porém, vamos focar na função Assume Role dentro da AWS e como ela funciona?
A função Assume Role na AWS
Antes de falarmos especificamente do Assume Role da AWS, vamos entender o que é usuário, acess Key e Secret Key.
Usuário IAM
É um usuário para você acessar os recursos da AWS dentro do console ou através da linha de comando ou de outras ferramentas, com o terraform. Ele pode ser de duas maneiras:
-
- Acesso ao console
- Acesso programático
Access Key e Secret Key
De acordo com a documentação, “as chaves de acesso são credenciais de longo prazo para um usuário IAM ou usuário raiz(root) da conta AWS. Podemos utilizar as chaves de acesso para fazer solicitação via API de forma programática(por exemplo, através do SDK da AWS) ou ainda via AWS CLI”. Tais chaves de acesso consistem em duas partes: um ID de chave de acesso(por exemplo, AKIAIOSFODNN7EXAMPLO) e uma chave de acesso secreta(ou Secret Key – por wJalrXUtnFEMI/K7MDENG/bPxRfiCYEXAMPLEKEY). Como um nome de usuário e uma senha, você deve usar o ID de chave de acesso e a chave de acesso secreta em conjunto para autenticar suas solicitações. Gerencie suas chaves de acesso de forma tão segura quanto você gerencia seu nome de usuário e sua senha.
O que é uma Role?
Role, ou funções do IAM, conforme o link é “Uma função do IAM é muito semelhante a um usuário, pois é uma identidade com políticas de permissão que determinam o que a identidade pode e não pode fazer na AWS. No entanto, uma função não tem quaisquer credenciais (senha ou chaves de acesso) associado a ela. Em vez de ser exclusivamente associada a uma pessoa, uma função destina-se a ser assumível por qualquer pessoa que precisar.” A partir do momento que você tem uma função já criada, você pode usar a API do AWS Security Token Service (STS) chamada Assume Role, onde o usuário passa a ter acesso a determinados recursos da AWS com credenciais de segurança temporárias. Mais informações podem ser encontradas nesse link:
Criando uma Role na Console
- Na console AWS, navegue até a página do IAM
- No menu ao lado esquerdo, selecione Roles
- Clique no botão “Create Role”
- O assistente para criação será aberto. O primeiro passo é encontrar o serviço que desejamos ter a role criada. Nesse caso, o serviço utilizado é o Amazon EC2, sendo assim, selecione “EC2”. A seguir, clique no botão “Next: Permissions”
Para anexar permissões para essa role, podemos utilizar as políticas(policies) disponíveis, ou criar uma nova política específica. Nesse caso, vamos utilizar a política AmazonS3ReadOnlyAccess, que permite acesso somente-leitura aos buckets do Amazon S3.
- No campo de pesquisa, informe o valor “AmazonS3Read”. A tabela de resultados será populada com a política desejada. Marque a caixa de seleção da mesma. Clique em “Next: Tags”
- (Opcional)Informe as tags desejadas para essa Role e clique em “Next: Review”
- Na tela de revisão(Review), informe um nome e uma descrição para a Role. Para finalizar, clique no botão “Create role”.
Utilizando a Role recém-criada em seu script Terraform
- Para fazer uso da role recém criada em seus scripts terraform, precisamos do identificador do recurso da Amazon(ARN) da mesma. Para tal, na tela de roles, selecione a role recém-criada.
- Copie o valor do campo Role ARN
- Utilize esse valor em seus scripts terraform. Por exemplo:
provider "aws" {
assume_role {
role_arn = "arn:aws:iam::1234567890:role/exemplo-s3readonly-role"
session_name = "SESSION_NAME"
external_id = "EXTERNAL_ID"
}
}
Com isso, as instâncias EC2 criadas utilizando esse script terão associadas uma role criada com acesso somente-leitura aos buckets S3.
Removendo a role criada nesse exemplo
- Na tela de Roles, selecione a Role exemplo-s3-reanonly-role e clique no botão
- Confirme a exclusão informando o nome da role, e a seguir clique no botão Delete
- Uma mensagem informando que a Role foi excluída será exibida
Conclusão
Você vai conseguir criar os seus recursos com Terraform ou o AWS Cloudformation com todas as opções, mas é bem melhor criar a sua infraestrutura sem deixar as credenciais expostas em algum lugar, não é mesmo?
Conheça mais sobre segurança da informação no nosso blog.
Sobre os Autores
Allyson Oliveira é Arquiteto de Soluções da AWS Brasil com foco em segurança de containers, devsecops e SRE, atendendo o setor público das regiões sul e sudeste.
Vinicius Soares Batista é Arquiteto de Soluções da AWS Brasil com foco no desenvolvimento de parceiros no setor público. Tem especial interesse por desenvolvimento de software, IoT e migrações.