Credenciais da conta de serviço

Como qualquer principal, uma conta de serviço pode se autenticar no Google, conseguir um token de acesso do OAuth 2.0 e chamar as APIs do Google. No entanto, esse processo funciona de maneira diferente para contas de serviço e para usuários.

As contas de serviço são autenticadas seguindo um destes procedimentos:

Como conseguir credenciais de curta duração
Usar uma chave de conta de serviço para assinar um JSON Web Token (JWT) e trocá-lo por um token de acesso

Credenciais de conta de serviço de curta duração

A maneira mais segura de autenticar uma conta de serviço é receber credenciais de curta duração para ela na forma de um token de acesso OAuth 2.0. Por padrão, esses tokens expiram após uma hora.

As credenciais de curta duração para contas de serviço são úteis quando você precisa atribuir acesso limitado a recursos para contas de serviço confiáveis. Elas também oferecem menos risco do que as credenciais de longa duração, como as chaves de conta de serviço.

Em muitos casos, essas credenciais são recebidas automaticamente, ou seja, você não precisa criá-las nem gerenciá-las. Confira alguns exemplos:

Se você executar um comando da Google Cloud CLI e incluir a sinalização --impersonate-service-account, a CLI gcloud criará credenciais de curta duração para a conta de serviço e executará o comando com essas credenciais.
Se você anexar uma conta de serviço a uma instância de máquina virtual (VM) do Compute Engine, as cargas de trabalho nessa instância poderão usar as bibliotecas de cliente do Cloud para acessar os serviços do Google Cloud. As bibliotecas de cliente do Cloud usam o Application Default Credentials (ADC) para receber credenciais de curta duração para a conta de serviço.

Para saber mais sobre esse processo, consulte Como autenticar aplicativos usando as credenciais da conta de serviço.
Se você configurou a federação de identidade de carga de trabalho, as bibliotecas de cliente do Cloud podem usar credenciais do seu provedor de identidade para gerar credenciais de conta de serviço de curta duração.

Também é possível usar a API Service Account Credentials para criar credenciais de curta duração manualmente. Por exemplo, é possível criar um serviço que conceda aos usuários credenciais de conta de serviço de curta duração para permitir que eles acessem temporariamente os recursos do Google Cloud.

A API Service Account Credentials pode criar os seguintes tipos de credenciais:

Tokens de acesso do OAuth 2.0
Tokens de ID do OpenID Connect (OIDC)
JSON Web Tokens (JWTs) autoassinados
Blobs binários autoassinados

Para mais informações, consulte Como criar credenciais de conta de serviço de curta duração.

Como interpretar registros de auditoria

Os registros de auditoria do Cloud ajudam você a responder às perguntas "quem fez o quê, onde e quando?" para os recursos do Google Cloud.

Quando você usa credenciais de curta duração para representar uma conta de serviço, a maioria dos serviços do Google Cloud cria entradas de registro que mostram as seguintes identidades:

A conta de serviço que as credenciais de curta duração estão representando
A identidade que criou as credenciais de curta duração

Use essas entradas de registro para identificar o principal que criou as credenciais de curta duração, bem como a conta de serviço que o principal representa.

Para ver exemplos de entradas de registro de auditoria que mostram a representação da conta de serviço, consulte Como representar uma conta de serviço para acessar o Google Cloud.

Autorepresentação

A autorepresentação ocorre quando você usa as próprias credenciais de uma conta de serviço para gerar uma nova credencial para a conta de serviço.

A API Service Account Credentials proíbe os seguintes tipos de falsificação de identidade:

Usar uma credencial de curta duração para gerar um novo token de acesso para a conta de serviço.

JSON Web Tokens (JWTs) autoassinados são a exceção a essa regra. É possível usar um JWT autoassinado para uma conta de serviço a fim de gerar um novo token de acesso.
Usar uma credencial de curta duração para que uma conta de serviço assine um objeto binário (blob) ou JWT que possa ser usado para chamar as seguintes APIs:

O Google Cloud proíbe esse tipo de autorepresentação porque permite que atores mal-intencionados atualizem tokens roubados indefinidamente.

Se você tentar usar a autorepresentação de uma das maneiras proibidas, poderá encontrar o seguinte erro:

FAILED_PRECONDITION: You can't create a token for the same service account that
you used to authenticate the request.

Se você encontrar esse erro, tente usar credenciais diferentes para gerar a nova credencial de curta duração para sua conta de serviço. Por exemplo, as credenciais de usuário final ou as credenciais de uma conta de serviço diferente.

Chaves da conta de serviço

Cada conta de serviço está associada a um par de chaves RSA públicas/privadas. A API Service Account Credentials usa esse par de chaves internas para criar credenciais de conta de serviço de curta duração e assinar blobs e tokens JSON da Web (JWTs, na sigla em inglês). Esse par é conhecido como par de chaves gerenciado pelo Google.

Além disso, é possível criar vários pares de chaves RSA públicas/privadas, conhecidos como pares de chaves gerenciadas pelo usuário, e usar a chave privada para autenticar com as APIs do Google. Essa chave privada é conhecida como chave da conta de serviço.

Pares de chaves gerenciadas pelo Google

Os pares de chaves gerenciados pelo Google são usados pela API Service Account Credentials e pelos serviços do Google Cloud, como o App Engine e o Compute Engine, para gerar credenciais de curta duração para contas de serviço.

As chaves gerenciadas pelo Google que são usadas ativamente para assinatura são rotacionadas regularmente de acordo com as práticas recomendadas de segurança. O processo de rotação é probabilístico, e o uso da nova chave aumentará ou diminuirá gradualmente ao longo do ciclo de vida da chave.

A chave privada em um par de chaves gerenciado pelo Google sempre é mantida em garantia, e nunca é possível acessá-la diretamente.

A chave pública em um par de chaves gerenciado pelo Google é acessível publicamente para que qualquer pessoa possa verificar as assinaturas criadas com a chave privada. É possível acessar a chave pública em vários formatos diferentes:

Certificado X.509: https://www.googleapis.com/service_accounts/v1/metadata/x509/SERVICE_ACCOUNT_EMAIL
Chave da Web JSON (JWK): https://www.googleapis.com/service_accounts/v1/jwk/SERVICE_ACCOUNT_EMAIL
Formato bruto: https://www.googleapis.com/service_accounts/v1/metadata/raw/SERVICE_ACCOUNT_EMAIL

Se você fizer o download e o armazenamento em cache da chave pública, recomendamos armazená-la em cache por no máximo 24 horas para garantir que você sempre tenha a chave atual. Independentemente da data de recuperação da chave pública, ela será válida por pelo menos 24 horas após a recuperação.

Pares de chaves gerenciadas pelo usuário

É possível criar pares de chaves gerenciadas pelo usuário para uma conta de serviço e, em seguida, usar a chave privada de cada par de chaves para autenticar com as APIs do Google. Essa chave privada é conhecida como chave da conta de serviço.

As bibliotecas de cliente do Cloud podem usar chaves de conta de serviço para receber um token de acesso do OAuth 2.0 automaticamente. Também é possível usar uma chave de conta de serviço para assinar um JWT manualmente e, em seguida, usar o JWT assinado para solicitar um token de acesso. Para mais detalhes, consulte Como usar o OAuth 2.0 para aplicativos de servidor para servidor.

Cada conta de serviço pode ter até 10 chaves de conta de serviço. O Google armazena apenas a parte pública de um par de chaves gerenciado pelo usuário.

Existem algumas maneiras diferentes de criar um par de chaves gerenciado pelo usuário para uma conta de serviço:

Use a API IAM para criar um par de chaves gerenciado pelo usuário automaticamente. O Google gera um par de chaves pública/privada, só armazena a chave pública e retorna a chave privada para você.
Crie um par de chaves gerenciado pelo usuário e faça upload apenas da chave pública. O Google nunca vê a chave privada.

Chaves gerenciadas pelo usuário são credenciais muito eficientes. Para limitar o uso de chaves gerenciadas pelo usuário, é possível aplicar as seguintes restrições de política da organização a uma organização, um projeto ou uma pasta:

constraints/iam.disableServiceAccountKeyCreation: impede que os principais criem chaves de conta de serviço gerenciadas por usuários.
constraints/iam.disableServiceAccountKeyUpload: impede que os principais façam upload de uma chave pública para uma conta de serviço.

Se você impor essas restrições porque está usando a federação de identidade da carga de trabalho, considere usar as restrições da política da organização para a federação da identidade da carga de trabalho para especificar quais provedores de identidade são permitidos.

Tempos de expiração para chaves gerenciadas pelo usuário

Por padrão, quando você cria uma chave de conta de serviço gerenciada pelo usuário, a chave nunca expira. É possível alterar esse padrão definindo um prazo de validade para todas as chaves recém-criadas no projeto, na pasta ou na organização. O prazo de validade especifica o número de horas para as quais uma chave recém-criada é válida.

Use prazos de validade quando você precisar de acesso temporário a um sistema que exija uma chave de conta de serviço. Por exemplo, use prazos de validade nos seguintes casos:

O desenvolvimento de código em um ambiente de não produção para um aplicativo só pode autenticar com chaves de conta de serviço
O uso de uma ferramenta de terceiros só pode autenticar com chaves de conta de serviço

Evite usar prazos de validade nestes cenários:

Cargas de trabalho de produção. Na produção, uma chave de conta de serviço expirada pode causar uma interrupção acidental. Em vez disso, use chaves que não expirem e gerencie o ciclo de vida delas com a rotação de chaves.
Cargas de trabalho de não produção que precisam de acesso permanente, como um pipeline de integração contínua (CI).
Sistemas de rotação de chaves que impedem o uso de uma chave após um período especificado. Para saber mais sobre as estratégias recomendadas de rotação de chaves, consulte Rotação de chaves de conta de serviço.

Para evitar interrupções, recomendamos que você não defina um prazo de validade, a menos que a restrição da política da organização constraints/iam.disableServiceAccountKeyCreation esteja em vigor por um longo período. Ao definir um prazo de validade, você também precisa interromper a aplicação da restrição constraints/iam.disableServiceAccountKeyCreation. Para detalhes sobre essa restrição, consulte Limitar o ciclo de vida das chaves de contas de serviço.

Para definir um prazo de validade, faça o seguinte:

Identifique o projeto, a pasta ou a organização em que você quer definir um prazo de expiração para as chaves de conta de serviço.
Adicione uma política da organização que aplique a restrição constraints/iam.serviceAccountKeyExpiryHours. Depois de aplicar essa restrição no seu projeto, pasta ou organização, o prazo de validade se aplica a todas as chaves de conta de serviço recém-criadas nesse recurso pai. As chaves não são afetadas.

Os tempos de validade são medidos em horas. Como prática recomendada, use prazos de validade curtos, como oito horas, 24 horas (1 dia) ou 168 horas (7 dias). Tempos de expiração curtos ajudam a garantir que sua equipe tenha um processo bem testado para atualizar chaves. Comece com o prazo de validade mais curto que atenda às suas necessidades e aumente-o apenas se necessário.