Tal como qualquer principal, uma conta de serviço pode autenticar-se no Google, obter um token de acesso do OAuth 2.0 e chamar APIs Google. No entanto, este processo funciona de forma diferente para contas de serviço do que para utilizadores.
As contas de serviço são autenticadas através de uma das seguintes ações:
- Obter credenciais de curta duração
- Usar uma chave de conta de serviço para assinar um símbolo da Web JSON (JWT) e trocá-lo por um token de acesso
Credenciais da conta de serviço de curta duração
A forma mais segura de autenticar como uma conta de serviço é obter credenciais de curta duração para a conta de serviço sob a forma de um token de acesso OAuth 2.0. Por predefinição, estes tokens expiram após 1 hora.
As credenciais da conta de serviço de curta duração são úteis para cenários em que tem de conceder acesso limitado a recursos para contas de serviço fidedignas. Também criam menos risco do que as credenciais de longa duração, como as chaves de contas de serviço.
Em muitos casos, estas credenciais são obtidas automaticamente. Não tem de as criar nem gerir. Seguem-se alguns exemplos:
- Se executar um comando da CLI gcloud e incluir a flag
--impersonate-service-account, a CLI gcloud cria credenciais de curta duração para a conta de serviço e executa o comando com essas credenciais. Se 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 podem usar as bibliotecas cliente da Google Cloud para aceder aos Trusted Cloud serviços. As bibliotecas cliente da Google Cloud usam as Credenciais padrão da aplicação (ADC) para obter credenciais de curta duração para a conta de serviço.
Para ver detalhes sobre este processo, consulte o artigo Autenticar aplicações através de credenciais da conta de serviço.
Se configurou a federação de identidades de carga de trabalho, as bibliotecas de cliente da Google Cloud podem usar credenciais do seu fornecedor de identidade para gerar credenciais de contas de serviço de curta duração.
Também pode usar a API Service Account Credentials para criar credenciais de curta duração manualmente. Por exemplo, pode criar um serviço que forneça aos utilizadores credenciais de contas de serviço de curta duração para lhes permitir aceder temporariamente a recursos Trusted Cloud .
A API Service Account Credentials pode criar os seguintes tipos de credenciais:
- Chaves de acesso OAuth 2.0
- Tokens de ID do OpenID Connect (OIDC)
- Símbolos da Web JSON (JWTs) autoassinados
- Blobs binários autoassinados
Para mais informações, consulte o artigo Criar credenciais de conta de serviço de curta duração.
Interpretar registos de auditoria
Os registos de auditoria da nuvem ajudam a responder às perguntas "quem fez o quê, onde e quando?" para os seus Trusted Cloud recursos.
Quando usa credenciais de curta duração para se fazer passar por uma conta de serviço, a maioria dos Trusted Cloud serviços cria entradas de registo que mostram as seguintes identidades:
- A conta de serviço que as credenciais de curta duração estão a representar
- A identidade que criou as credenciais de curta duração
Pode usar estas entradas do registo para identificar o principal que criou as credenciais de curta duração, bem como a conta de serviço que o principal representou.
Para ver exemplos de entradas do registo de auditoria que mostram a simulação da conta de serviço, consulte o artigo Simular uma conta de serviço para aceder Trusted Cloud.
Roubo de identidade próprio
A autopersonificação ocorre quando 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 representação de si próprio:
Usar uma credencial de curta duração para uma conta de serviço para gerar um novo token de acesso para a conta de serviço.
Os tokens Web JSON (JWTs) autoassinados são a exceção a esta regra. Pode usar um JWT autoassinado para uma conta de serviço para gerar uma nova chave de acesso para a conta de serviço.
Usar uma credencial de curta duração para uma conta de serviço para assinar um objeto binário (blob) ou um JWT que pode ser usado para chamar as seguintes APIs:
Trusted Cloud proíbe este tipo de roubo de identidade porque permite que atores maliciosos atualizem tokens roubados indefinidamente.
Se tentar usar a representação de si próprio de uma das formas proibidas, pode receber o seguinte erro:
FAILED_PRECONDITION: You can't create a token for the same service account that you used to authenticate the request.
Se encontrar este erro, experimente usar credenciais diferentes para gerar a nova credencial de curta duração para a sua conta de serviço, por exemplo, as credenciais do utilizador final ou as credenciais de uma conta de serviço diferente.
Chaves de contas de serviço
Cada conta de serviço está associada a um par de chaves RSA públicas/privadas. A API de credenciais da conta de serviço usa este par de chaves interno para criar credenciais da conta de serviço de curta duração e para assinar blobs e tokens da Web JSON (JWTs). Este par de chaves é conhecido como o Google Cloud-powered key par.
Além disso, pode criar vários pares de chaves RSA públicas/privadas, conhecidos como pares de chaves geridos pelo utilizador, e usar a chave privada para fazer a autenticação nas APIs Google. Esta chave privada é conhecida como chave da conta de serviço.
Google Cloud-powered key pares
Google Cloud-powered key são usadas pela API Service Account Credentials e por serviços como o App Engine e o Compute Engine para gerar credenciais de curta duração para contas de serviço. Trusted Cloud
Google Cloud-powered keys que são ativamente usadas para a assinatura são rodadas regularmente de acordo com as práticas recomendadas de segurança. O processo de rotação é probabilístico. A utilização da nova chave vai aumentar e diminuir gradualmente ao longo da duração da chave.
A chave privada num Google Cloud-powered key par é sempre mantida em depósito caucionado e nunca pode aceder diretamente à mesma.
A chave pública num Google Cloud-powered key par é acessível publicamente, para que qualquer pessoa possa validar as assinaturas criadas com a chave privada. Pode aceder à chave pública em vários formatos diferentes:
- Certificado X.509:
https://www.googleapis.com/service_accounts/v1/metadata/x509/SERVICE_ACCOUNT_EMAIL - Chave Web JSON (JWK):
https://www.googleapis.com/service_accounts/v1/jwk/SERVICE_ACCOUNT_EMAIL - Formato não processado:
https://www.googleapis.com/service_accounts/v1/metadata/raw/SERVICE_ACCOUNT_EMAIL
Se transferir e colocar em cache a chave pública, recomendamos que a coloque em cache durante, no máximo, 24 horas para garantir que tem sempre a chave atual. Independentemente do momento em que obtém a chave pública, esta é válida durante, pelo menos, 24 horas após a obtenção.
Pares de chaves geridos pelo utilizador
Pode criar pares de chaves geridos pelo utilizador para uma conta de serviço e, em seguida, usar a chave privada de cada par de chaves para fazer a autenticação nas APIs Google. Esta chave privada é conhecida como chave de conta de serviço.
As bibliotecas cliente do Google Cloud podem usar chaves de contas de serviço para obter automaticamente uma chave de acesso OAuth 2.0. Também pode usar uma chave de conta de serviço para assinar um JWT manualmente e, em seguida, usar o JWT assinado para pedir uma chave de acesso. Para ver detalhes, consulte o artigo Usar o OAuth 2.0 para aplicações de servidor a servidor.
Cada conta de serviço pode ter até 10 chaves de conta de serviço. A Google armazena apenas a parte pública de um par de chaves gerido pelo utilizador.
Existem várias formas de criar um par de chaves gerido pelo utilizador para uma conta de serviço:
- Use a API IAM para criar automaticamente um par de chaves gerido pelo utilizador. A Google gera um par de chaves pública/privada, armazena apenas a chave pública e devolve a chave privada ao utilizador.
- Crie um par de chaves geridas pelo utilizador e, em seguida, carregue apenas a chave pública. A Google nunca vê a chave privada.
As chaves geridas pelo utilizador são credenciais extremamente poderosas. Para limitar a utilização de chaves geridas pelo utilizador, pode aplicar as seguintes restrições da política da organização numa organização, num projeto ou numa pasta:
constraints/iam.disableServiceAccountKeyCreation: Impede que os principais criem chaves de contas de serviço geridas pelo utilizador.constraints/iam.disableServiceAccountKeyUpload: impede que os principais carreguem uma chave pública para uma conta de serviço.
Se aplicar estas restrições porque está a usar a federação de identidades de cargas de trabalho, considere usar as restrições de políticas da organização para a federação de identidades de cargas de trabalho para especificar que fornecedores de identidade são permitidos.
Tempos de expiração para chaves geridas pelo utilizador
Por predefinição, quando cria uma chave de conta de serviço gerida pelo utilizador, a chave nunca expira. Pode alterar esta predefinição definindo um prazo de validade para todas as chaves criadas recentemente no seu projeto, pasta ou organização. Uma hora de validade especifica o número de horas durante as quais uma chave criada recentemente é válida.
Use prazos de validade quando precisar de acesso temporário a um sistema que requer uma chave de conta de serviço. Por exemplo, use horas de validade quando estiver a fazer o seguinte:
- Desenvolver código num ambiente de não produção para uma aplicação que só pode autenticar com chaves de contas de serviço
- Usar uma ferramenta de terceiros que só pode autenticar com chaves de contas de serviço
Evite usar horas de validade para estes 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 alternativa, use chaves que não expirem e faça a gestão do respetivo ciclo de vida 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 (IC).
- Sistemas de rotação de chaves que impedem a utilização de uma chave após um período especificado. Para saber mais sobre as estratégias de rotação de chaves recomendadas, consulte o artigo Rotação de chaves de contas de serviço.
Para ajudar a evitar interrupções, recomendamos que não defina uma hora de validade, a menos que a restrição da política da organização constraints/iam.disableServiceAccountKeyCreation
esteja em vigor durante um período prolongado. Quando define uma hora de validade, também tem de parar de aplicar a restrição constraints/iam.disableServiceAccountKeyCreation. Para ver
detalhes sobre esta restrição, consulte o artigo
Limite a duração das chaves de contas de serviço.
Para definir uma hora de validade, faça o seguinte:
- Identifique o projeto, a pasta ou a organização onde quer definir um tempo de expiração para as chaves de contas de serviço.
- Adicione uma política da organização que aplique a restrição
constraints/iam.serviceAccountKeyExpiryHours. Depois de aplicar esta restrição ao seu projeto, pasta ou organização, a hora de validade aplica-se a todas as chaves de contas de serviço criadas recentemente no recurso principal. As chaves existentes não são afetadas.
Os tempos de expiração são medidos em horas. Como prática recomendada, use prazos de validade curtos, como 8 horas, 24 horas (1 dia) ou 168 horas (7 dias). Os prazos de validade curtos ajudam a garantir que a sua equipa tem um processo bem testado para atualizar as chaves. Comece com o tempo de expiração mais curto que satisfaça as suas necessidades e aumente-o apenas se for necessário.