Autenticando terraform na Google Cloud sem compartilhamento de chaves
O terraform atualmente é, de longe, a ferramenta de infraestrutura como código mais popular no mundo de TI e de Cloud. Ele tem suporte aos principais provedores de cloud e pode ser utilizado inclusive para provisionar workloads diretamente no Kubernetes.
Um requisito comum para começar a provisionar a infraestrutura na nuvem com o terraform é possuir credenciais de acesso com permissões para criar os recursos desejados. Isso normalmente é feito compartilhando algum tipo de chave chave de um usuário, ou de uma conta de serviço, utilizada no processo de IaC.
A desvantagem dessa abordagem é que ela cria um risco de segurança assim que a chave é gerada e distribuída. Qualquer usuário com acesso a uma chave de conta de serviço poderá se autenticar como essa conta e acessar todos os recursos para os quais a conta de serviço tem permissões.
Na Google Cloud é possível usar a técnica de Service Account impersonation que permite que qualquer usuário, que tenha atribuído a ele a role Service Account Token Creator IAM, possa utilizar as próprias credenciais de acesso para provisionar os recursos na cloud sem que haja a necessidade de compartilhar nenhuma chave de acesso.
Pré-requisitos e vantagens
- Uma conta na GCP com permissão pelo menos de ‘viewer’ no projeto onde os recursos serão provisionados;
- O gcloud instalado na maquina em que o terraform será executado;
- Ter realizado o login na sua conta via: gcloud auth application-default login
- Uma service account com as permissões para executar o provisionamento dos recursos desejados;
- A permissão Service Account Token Creator IAM atribuído a sua conta
- Reduz a superfície de ataque eliminando a distribuição de chaves de conta de serviço (para Terraform)
- Identifique claramente quem (grupo, usuário, conta de serviço) deve ter a capacidade de usar o ‘impersonation’ para contas com privilégios mais altos
- Tire proveito da segurança em torno da autenticação do usuário (que geralmente envolve autenticação multifator) em vez de um arquivo de chave
- Chaves da conta de serviço gerenciado pelo Google
- Funciona em conjunto com credenciais de curta duração, permitindo acesso por tempo limitado a funções que a conta de serviço possui.
Preparando as configurações
Você vai precisar ter a função Service Account Token Creator IAM concedida à sua própria conta de usuário.
Essa função permite que você utilize as permissões de contas de serviço para acessar APIs e recursos. A recomendação é que, aderindo ao princípio de menor privilégio, a função seja concedida a você especificamente na conta de serviço que será utilizada para provisionar os recursos via terraform
Para isso vá em Navigation Menu -> IAM & Admin -> Service accounts, na tela que mostra as services accounts, clique na que você quer adicionar o usuário com a permissão: Service Account Token Creator, em seguida clique na aba PERMISSIONS e daí só clicar no botão ‘GRANT ACCESS’, que fica logo no meio da tela:
Configurando o terraform
Depois de ter uma conta de serviço e a função Service Account Token Creator‘, você pode realizar o ‘impersonation’ para contas de serviço no Terraform de duas maneiras: definir uma variável de ambiente para o e-mail da conta de serviço ou adicionar um bloco de provider extra em seu código do Terraform.
No nosso exemplo vamos optar pela segunda opção pois deixa o código pronto sem a necessidade de definir sempre uma variável de ambiente.
Você precisará adicionar alguns blocos ao código do Terraform (de preferência no arquivo provider.tf) que recuperará as credenciais da conta de serviço.
Primeiro, defina uma variável local para o e-mail da conta de serviço:
Em seguida, crie um provider que será usado para recuperar um token de acesso para a conta de serviço. O provider é “google”, mas note o alias de “impersonation” atribuído a ele:
Em seguida, adicione um bloco de data para recuperar o token de acesso que será usado para autenticar como a conta de serviço. Observe que o bloco faz referência ao provider de impersonation e à conta de serviço especificada acima:
Abaixo o nosso main.tf de exemplo completo:
locals { terraform_service_account = "terraform-iac-compute@terraform-lab-357713.iam.gserviceaccount.com" } provider "google" { alias = "impersonation" project = "terraform-lab-357713" scopes = [ "https://www.googleapis.com/auth/cloud-platform", "https://www.googleapis.com/auth/userinfo.email", ] } data "google_service_account_access_token" "default" { provider = google.impersonation target_service_account = local.terraform_service_account scopes = ["userinfo-email", "cloud-platform"] lifetime = "1200s" } provider "google" { access_token = data.google_service_account_access_token.default.access_token project = "terraform-lab-357713" region = "us-central1" } resource "google_compute_instance" "default" { name = "test" machine_type = "e2-micro" zone = "us-central1-a" boot_disk { initialize_params { image = "debian-cloud/debian-11" } } network_interface { network = "default" } }
Conclusão
Os métodos acima não exigem que nenhuma chave de conta de serviço seja gerada ou distribuída. Embora o terraform dê suporte ao uso de chaves de conta de serviço, gerar e distribuir essas chaves apresenta alguns riscos de segurança que são minimizados com o uso do Service Account impersonation.
Em vez de os administradores criarem, rastrearem e alternarem chaves, o acesso à conta de serviço é centralizado em sua política do IAM correspondente. Ao usar o impersonation, o código se torna mais portável e pode ser usado por qualquer pessoa no projeto com a função Service Account Token Creator IAM, que pode ser facilmente concedida e revogada por um administrador.
Há vários outros benefícios e um baixo overhead de administração na implementação do Service Account impersonation, portanto, recomendo que você experimente.
About author
Você pode gostar também
Entenda a Importância e Utilização das Variáveis de Ambiente em Linux
Costumeiramente em nossos processos diários sempre nos deparamos com uma configuração de uma variável, por conceito em tecnologia, uma variável é um local ou espaço que é designado para armazenar
Guia Prático: Instalação e Funcionamento do Kong API e Kong-Dashboard
Estive envolvido num projeto de migração, algumas aplicações internas para o modelo de micro serviço. No caso, cada parte do código se tornaria um projeto independente, dessa forma, agilizando os
Run Locally, Deploy Globally: Uma Introdução ao LocalStack
Transforme sua maneira de desenvolver na AWS com o LocalStack! Aprenda a testar localmente e implantar globalmente, reduzindo custos e acelerando seu projeto. Descubra o segredo dos desenvolvedores eficientes! “Run