Autenticando terraform na Google Cloud sem compartilhamento de chaves

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

Alguns pré-requisitos devem ser atendidos para que se possa fazer o uso do Service Account impersonation:
  • 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
Alguns benefícios que podemos destacar no uso do Service Account impersonation:
  • 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

Em primeiro lugar você já deve ter um usuário criado no projeto em que o terraform irá provisionar os recursos, esse usuário precisar ter as permissões mínimas, no nosso exemplo estou usando o usuário anderson.bispo@4linux.com.br em um projeto de teste com o id: terraform-lab-357713
Além disso já estou com o gcloud instalado, configurado e com acesso ao projeto:
O próximo passo é realizar o login para permitir que o terraform faça o provisionamento com nosso usuário:

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:

Na tela ‘Grant access to “<your-service-account-name>”‘ selecione seu usuário e em seguida selecione a função Service Account Token Creator, daí é só clicar em salvar.

 

 

Após clicar em salvar na própria tela permissions é possível validar que a função foi atribuída a seu usuário:

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:

E, finalmente, inclua um segundo provider “google” que usará o token de acesso da sua conta de serviço. Sem ‘alias’, ele será o provedor padrão usado para todos os recursos do Google em seu código do Terraform:

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.

 

 

 

 

Anterior Entenda o Middleware: A espinha dorsal da conectividade digital
Próxima Automatizando Tarefas com Shell Script

About author

Anderson Bispo
Anderson Bispo 5 posts

Formado em Sistemas de Informação, pela Universidade Salvador. Possui especialização em Gestão e Governança de TI e MBA em BI/DW. Atua com TI desde 2001 principalmente como SysAdmin Unix/Linux, DBA Oracle e Cloud Architect. Possui certificações ITIL, Scrum Master, Oracle OCP, Oracle Cloud Architect, Google Cloud Engineer, entre outras. Atualmente é servidor público do Tribunal de Justiça da Bahia e consultor, instrutor e conteudista da 4Linux.

View all posts by this author →

Você pode gostar também

Carreiras

Descubra o futuro do desenvolvimento de software com Docker e Kubernetes

Docker, Kubernetes, Openshift, enfim … escalabilidade! A tecnologia de containers está moldando o futuro do desenvolvimento de software e está causando uma mudança estrutural no mundo da computação, principalmente quando

Infraestrutura TI

Prepare sua empresa para 2022 com a Consultoria e Cursos 4Linux

Sua empresa está preparada para 2022? Em um mercado cada vez mais competitivo, e principalmente após uma pandemia, a inovação e tecnologia são fundamentais para a sobrevivência e podem ser

DevOps

Participe do Beta Test da nova certificação DEVOPS do LPI

O Linux e o mundo open source estão em constante evolução e o LPI trabalha arduamente para garantir que os seus exames de certificação reflitam os mais recentes avanços na