Introdução às APIs do Google: Contas de Serviço (Parte 1)

Entenda como as APIs do Google exigem diferentes tipos de credenciais, dependendo da API e de quem é o proprietário dos dados. Este artigo aborda as service accounts, um tipo de credencial usado para APIs do Google Cloud (GCP) e para gerenciar domínios do Google Workspace (GWS). Se você usa APIs GCP, gerencia domínios GWS ou utiliza a ferramenta GAM, este guia é para você. Caso contrário, o conteúdo pode ser opcional.

Este blog é dedicado ao uso das APIs do Google com Python e Node.js, buscando facilitar a integração e o uso dessas ferramentas. O foco é cobrir tópicos que não estão presentes na documentação oficial do Google, como:

• Google Cloud/GCP (AI/ML, serverless)
• Google Workspace/GWS (Gmail, Drive, Docs, Sheets)
• YouTube
• Maps
• Gemini
• Credenciais (chaves de API, OAuth client IDs, service accounts)

Antes de mergulharmos nas service accounts, vamos revisar os diferentes tipos de credenciais para entender melhor onde elas se encaixam.

Visão Geral de Credenciais e Autorização

O acesso às APIs do Google envolve autenticação (authn), que verifica quem você é, e autorização (authz), que verifica se você tem acesso aos dados via API. Sua conta Google, Gmail ou Workspace cuida da autenticação, enquanto as credenciais cuidam da autorização.

As APIs do Google suportam três tipos de credenciais:

1. Chaves de API
2. OAuth client IDs
3. Service accounts

A credencial necessária depende de quem é o proprietário dos dados acessados pela API:

1. Chaves de API: usadas para APIs que acessam dados públicos, como procurar lugares no Google Maps, enviar uma imagem para a API Cloud Vision, pesquisar vídeos no YouTube ou analisar texto com a API Natural Language. As APIs do Maps usam apenas chaves de API, pois acessam dados públicos.
2. OAuth client IDs: usadas para APIs que acessam dados de usuários. Seu aplicativo precisa da permissão do usuário para acessar documentos no Drive, mensagens no Gmail ou vídeos nas playlists do YouTube. APIs do GWS usam OAuth client IDs, já que lidam com dados pessoais.
3. Service accounts: usadas para APIs que acessam dados pertencentes a um aplicativo ou projeto. Em aplicativos baseados na nuvem, não há um usuário para solicitar permissões, e os dados não são de propriedade de humanos. A autorização é concedida via service account e IAM (Identity and Access Management), com chaves pública e privada criadas com permissões específicas. APIs do GCP se encaixam aqui.

Algumas APIs do Google aceitam mais de um tipo de credencial. Por exemplo, a API Cloud Vision geralmente usa service accounts, mas enviar uma imagem (em vez de ler um arquivo do Google Drive ou de um bucket do Cloud Storage) é considerado “dado público”, então uma chave de API funciona. Outro exemplo é um aplicativo que usa OAuth client IDs para chamar a API Vision, lendo imagens do Google Drive do usuário. Usar uma chave de API ou service account misturaria as credenciais, complicando o código. Embora as chaves de API sejam suficientes, credenciais mais rigorosas (OAuth client IDs ou service accounts) são aceitáveis para a API Vision.

Service accounts: O Que São e Como Funcionam

O universo das service accounts é vasto, e será preciso mais de um artigo para explorar todas as suas funcionalidades. Este artigo serve como uma introdução de alto nível aos conceitos básicos.

Service accounts Também São Principals

Service accounts são principals, que podem ser entendidas como “usuários” em um sentido geral. Principals geralmente se referem a usuários humanos identificados por endereços de e-mail. Uma service account também é um principal, pois também é identificada por um endereço de e-mail, mas não pertence a uma pessoa. Pense em uma service account como uma “conta de robô”.

Diferenças Entre Service accounts e Autorização de Usuário

Mas onde entra a parte da “credencial”? Como mencionado antes, service accounts são usadas principalmente quando aplicativos acessam recursos na nuvem, dados pertencentes a um projeto na nuvem e não a usuários humanos.

Com OAuth IDs, há desenvolvedores humanos e usuários finais humanos. Quem executa o código, o dono dos dados, deve conceder as permissões necessárias para o aplicativo funcionar, por meio de scopes. Alguns scopes exigem mais análise antes que o aplicativo possa ser disponibilizado aos usuários.

Ao testar um aplicativo, você assume ambos os papéis: desenvolvedor e usuário final. Mas agora estamos falando de dados que não pertencem ao usuário, então OAuth client IDs não funcionam. Os dados estão na nuvem, e não há um usuário final para pedir permissão.

Em resumo, uma service account é um principal com privilégios predefinidos para acessar os dados que precisa. Em vez de scopes de permissão, as permissões da service account vêm na forma de funções e permissões do Identity and Access Management (IAM). As permissões já foram concedidas, então não é necessário solicitar permissão ao usuário.

Um artigo do blog do Google Cloud resume:

1. “Service accounts representam usuários não humanos e são destinadas a cenários onde um aplicativo precisa acessar recursos ou realizar ações sob sua própria identidade.”
2. “Diferente de usuários normais, service accounts não podem se autenticar usando uma senha ou single sign-on (SSO).”

Tipos de Service accounts

Existem três tipos de service accounts:

Na maioria das vezes, seu aplicativo usará user-managed service accounts. As default service accounts são diferentes, “gerenciadas pelo usuário”, mas criadas pelo Google para plataformas como App Engine ou Compute Engine.

Aplicativos no App Engine e Compute Engine VMs podem chamar várias APIs do GCP porque as default service accounts concedem permissões amplas e são anexadas a essas plataformas, simplificando a prototipagem. Para produção, mude para user-managed service accounts com permissões restritas, o suficiente para o aplicativo funcionar corretamente e aderir ao princípio do menor privilégio.

Service agents são as mais simples. Elas são criadas pelo Google e usadas apenas pelo Google, feitas sob medida para produtos específicos. Elas ajudam cada produto do GCP a “fazer seu trabalho”.

Formatos de Service accounts

Agora que você conhece os tipos de service accounts, vamos ver como elas se parecem. Elas são endereços de e-mail, mas não são bonitas. Aqui estão alguns exemplos:

1. google@appspot.gserviceaccount.com
2. 123456789-compute@developer.gserviceaccount.com
3. firebase-adminsdk-y7bg@google.iam.gserviceaccount.com
4. svcacct1@google.iam.gserviceaccount.com
5. service-123456789@container-engine-robot.iam.gserviceaccount.com
6. service-123456789@serverless-robot-prod.iam.gserviceaccount.com
7. 123456789@cloudservices.gserviceaccount.com

Não é claro quais são user-managed, default ou service agents. Embora variem, todas têm um “nome de domínio” de gserviceaccount.com, indicando que são algum tipo de service account. As que você cria e usa provavelmente se parecerão com a número 4. Esse é um exemplo de uma user-managed service account, criada por você. O gráfico abaixo ajudará a determinar o tipo de service account que você está vendo:

Onde…

O primeiro par são default service accounts, criadas automaticamente e que fornecem permissões amplas para ajudar seus aplicativos App Engine ou Compute Engine a decolar rapidamente. As user-managed service accounts são as que você mais usará. As três últimas são service agents, criadas pelo Google e “para uso interno” pelo projeto GCP para o qual foram criadas.

Todos os projetos têm nomes, IDs e números. Você escolhe o primeiro. IDs de projeto são strings que identificam um projeto, enquanto números de projeto são valores numéricos gerados pelo Google, também identificando projetos. Qualquer confusão pode ser esclarecida nesta página da documentação.

Usando Service accounts com o Workspace

Embora a maioria do uso de service accounts ocorra no GCP, como aplicativos executados em plataformas de computação do GCP que chamam APIs do GCP, ou acessando dados em produtos de dados do GCP, há um caso de uso para usar service accounts com o GWS. Ao gerenciar muitos usuários finais em domínios do Workspace, administradores de domínio frequentemente precisam realizar tarefas de manutenção em nome de seus usuários. Para isso, eles podem usar service accounts com delegação em todo o domínio.

Isso permite que “aplicativos internos e de terceiros acessem os dados do Google Workspace dos usuários, ignorando o consentimento do usuário final… crie uma service account no console do Google Cloud e delegue a autoridade em todo o domínio para a conta no console de administração do Google”. Sem exigir permissões de cada usuário no domínio, os administradores podem concluir tarefas importantes em tempo hábil. Isso concede amplas permissões aos administradores, que devem aderir às melhores práticas de delegação em todo o domínio.

Para saber mais sobre segurança e gerenciamento de dados, confira este artigo sobre Procon alerta sobre riscos do Goldcard TV e IPTV barato.

Conclusão Sobre Service accounts

Este artigo introdutório sobre service accounts abordou o básico, como a diferença entre service accounts e outros tipos de credenciais de API do Google, como chaves de API e OAuth client IDs. Elas acessam dados privados que exigem authz, mas onde você tem dados que vivem na nuvem e pertencem a um projeto do Cloud, em vez de um usuário humano, e onde não há usuários humanos para solicitar authz. Elas são um principal, mas recebem permissões predeterminadas do Cloud IAM.

Existem diferentes tipos de service accounts, incluindo default service accounts e service agents. No entanto, o principal tipo de service account com o qual você interage são as user-managed service accounts. Cada um desses tipos de service account vem em vários formatos.

Para uma visão mais ampla sobre tecnologias Google, descubra o que o novo Gemini e o Project Astra prometem para o futuro.

Embora as service accounts sejam normalmente usadas para aplicativos ou dados que vivem no GCP, elas também podem ser úteis para administradores de domínio do GWS que precisam realizar tarefas de manutenção em nome dos usuários finais. Nesses casos, service accounts com delegação em todo o domínio podem concluir essas tarefas sem exigir o consentimento do usuário.

Próximos Passos

Agora que você sabe o que são service accounts, os próximos artigos mostrarão como usá-las. Se você encontrou um erro neste artigo ou gostaria que eu abordasse um tópico específico, além de service accounts, deixe um comentário abaixo. Para serviços profissionais, entre em contato com a CyberWeb.

Referências

Abaixo estão vários recursos relevantes para este artigo que você pode achar úteis.

• Introdução rápida às service accounts
• Visão geral completa das service accounts
• Tipos de service accounts
• Credenciais de service accounts
• Melhores práticas
• Princípio do menor privilégio
• Artigo do blog sobre service accounts
• Delegação em todo o domínio do GWS com service accounts
• Melhores práticas de delegação em todo o domínio
• Ferramenta de gerenciamento de administrador de domínio GAM GWS

Este conteúdo foi auxiliado por Inteligência Artificial, mas escrito e revisado por um humano.

Via dev.to