Exemplos de registos para a Workload Identity Federation

Esta página mostra exemplos dos registos de auditoria gerados quando usa a Federação do Workload Identity. Com a Workload Identity Federation, pode permitir que uma carga de trabalho no local ou em várias nuvens aceda a recursos Google Cloud sem usar uma chave de conta de serviço.

Para mais informações sobre como ativar e ver registos de auditoria, consulte o artigo Registo de auditoria da IAM.

Registos para trocar um token do IdP por um token federado

Depois de configurar os Workload Identity Pools e o fornecedor de identidade (IdP), pode criar um token para o seu IdP e trocá-lo por um token federado.

O IAM pode gerar registos de auditoria quando os principais trocam um token. Para receber registos de auditoria para todos os passos do processo de troca de tokens, tem de ativar os registos de auditoria para a atividade de acesso a dados para as seguintes APIs:

  • API Identity and Access Management (IAM) (ative o tipo de registo "Admin Read")
  • API Security Token Service (ative o tipo de registo "Admin Read")

Depois de ativar os registos de auditoria para a atividade de acesso a dados, o IAM gera uma entrada de registo de auditoria sempre que um principal troca um token. A entrada do registo inclui os seguintes campos:

  • protoPayload.authenticationInfo.principalSubject: O assunto do token do IdP.
    • Nos Amazon Web Services (AWS), este campo contém o nome do recurso da Amazon (ARN) do principal que autenticou.
    • No Microsoft Azure, este campo contém o ID do objeto da identidade gerida que especificou como o assunto do token do Azure.
    • Para outros IdPs OIDC, este campo contém o valor da reivindicação sub, ou assunto, do token OIDC.

  • protoPayload.metadata.mapped_principal: o assunto do token, usando a sintaxe do IAM para identificar o principal:

    principal://iam.googleapis.com/projects/project-number/locations/global/workloadIdentityPools/pool-id/subject/identifier

  • protoPayload.resourceName: O fornecedor do Workload Identity Pool ao qual o token está associado.

O exemplo seguinte mostra uma entrada do registo de auditoria para um pedido de troca de um token. Neste exemplo, um token do Microsoft Azure foi trocado por um token federado:

{
  "logName": "projects/my-project/logs/cloudaudit.googleapis.com%2Fdata_access",
  "protoPayload": {
    "@type": "type.googleapis.com/google.cloud.audit.AuditLog",
    "authenticationInfo": {
      "principalSubject": "b6112abb-5791-4507-adb5-7e8cc306eb2e"
    },
    "metadata": {
      "mapped_principal": "principal://iam.googleapis.com/projects/1234567890123/locations/global/workloadIdentityPools/azure-pool/subject/a1234bcd-5678-9012-efa3-4b5cd678ef9a"
    },
    "methodName": "google.identity.sts.v1.SecurityTokenService.ExchangeToken",
    "resourceName": "projects/1234567890123/locations/global/workloadIdentityPools/azure-pool/providers/azure",
    "request": {
      "@type": "type.googleapis.com/google.identity.sts.v1.ExchangeTokenRequest",
      "grantType": "urn:ietf:params:oauth:grant-type:token-exchange"
    }
  },
  "resource": {
    "type": "audited_resource"
  }
}

Registos de afirmações SAML assinadas e encriptadas

Esta secção descreve as entradas de registo dos registos de auditoria da nuvem que o serviço de tokens de segurança cria quando tenta validar afirmações SAML assinadas ou desencriptar afirmações encriptadas enviadas a partir do seu IdP.

Para a federação de identidades da carga de trabalho, a entrada de registo pertinente é semelhante à seguinte:

"keyInfo": [
  {
    "use": "verify"
    "fingerprint": "3C:B2:47:F8:A5:9A:8A:52:BD:1C:BC:96:B5:45:C1:8D:A7:F1:73:2D"
  },
  {
    "use": "decrypt"
    "resourceName": "//iam.googleapis.com/projects/PROJECT_NUMBER/locations/global/workloadIdentityPools/WORKLOAD_POOL_NAME/providers/PROVIDER_NAME/keys/KEY_NAME"
  }
]

Esta saída inclui os seguintes valores:

  • fingerprint: a representação hexadecimal do hash SHA-256 do certificado X.509 que foi usado para validar a assinatura na credencial SAML. O certificado X.509 é extraído dos metadados XML SAML anexados ao fornecedor do Workload Identity Pool.
  • resourceName: o nome do recurso da chave do fornecedor do Workload Identity Pool que foi usado para desencriptar a declaração SAML encriptada. Este campo só está presente se a federação de identidades receber uma resposta SAML encriptada do seu IdP.

Registos para a federação X.509

Esta secção descreve as entradas de registo dos registos de auditoria do Google Cloud que o serviço de tokens de segurança cria quando tenta validar o certificado do cliente mTLS com um repositório fidedigno pré-configurado.

Para a federação de identidades da carga de trabalho, a entrada de registo pertinente é semelhante à seguinte:

"keyInfo": [
  {
    "certificateType": "trust_anchor"
    "timeUntilExpiration": 3333405600s
    "fingerprintSha256": "e33f612a0e426692f29db2c7b17b9e3810ce13f09ad117c67e7227a84fd25ea5"
    "use": "verify"
  }

Esta saída inclui os seguintes valores:

  • certificateType: o tipo de certificado envolvido na validação do certificado de cliente, que pode ser trust_anchor ou intermediate_ca
  • timeUntilExpiration: o tempo restante em segundos até à expiração do certificado quando é usado na validação da cadeia de certificados
  • fingerprintSha256: a representação hexadecimal do hash SHA-256 do certificado X.509

Registos para a criação de credenciais de curta duração para uma conta de serviço

Depois de trocar o token do IdP por um token federado, pode usar o token federado para criar credenciais de curta duração para uma conta de serviço. Todos os serviços Google permitem a autenticação com estas credenciais de curta duração.

Depois de ativar os registos de auditoria do IAM para a atividade de acesso a dados, o IAM gera uma entrada de registo de auditoria sempre que um principal gera credenciais de curta duração para uma conta de serviço. A entrada do registo inclui os seguintes campos:

  • protoPayload.authenticationInfo.principalSubject: o assunto do token federado.
  • resource.labels.email_id: a conta de serviço para a qual foram geradas credenciais de curta duração.

O exemplo seguinte mostra uma entrada do registo de auditoria para um pedido de geração de um token de acesso OAuth 2.0 de curta duração para uma conta de serviço. Neste exemplo, o pedido foi autenticado com credenciais federadas e as credenciais de curta duração foram criadas para a conta de serviço my-service-account@my-project.iam.gserviceaccount.com:

{
  "logName": "projects/my-project/logs/cloudaudit.googleapis.com%2Fdata_access",
  "protoPayload": {
    "@type": "type.googleapis.com/google.cloud.audit.AuditLog",
    "authenticationInfo": {
      "principalSubject": "principal://iam.googleapis.com/projects/1234567890123/locations/global/workloadIdentityPools/aws-pool/subject/012345678901"
    },
    "methodName": "GenerateAccessToken",
    "request": {
      "@type": "type.googleapis.com/google.iam.credentials.v1.GenerateAccessTokenRequest",
      "name": "projects/-/serviceAccounts/my-service-account@my-project.iam.gserviceaccount.com"
    },
    "resourceName": "projects/-/serviceAccounts/123456789012345678901"
  },
  "resource": {
    "labels": {
      "email_id": "my-service-account@my-project.iam.gserviceaccount.com",
      "project_id": "my-project",
      "unique_id": "123456789012345678901"
    },
    "type": "service_account"
  }
}

Registos para autenticação com credenciais para a conta de serviço simulada

Depois de criar credenciais de curta duração para uma conta de serviço, pode usar as credenciais para se fazer passar pela conta de serviço quando chamar as APIs. Google Cloud

Alguns dos métodos que chama podem gerar registos de auditoria. Em geral, estas entradas de registo 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

Por exemplo, suponhamos que o utilizador jamie@example.com cria um token federado para o assunto principal://iam.googleapis.com/projects/1234567890123/locations/global/workloadIdentityPools/aws-pool/subject/jamie@example.com e, em seguida, usa o token federado para criar credenciais de curta duração para a conta de serviço my-service-account@my-project.iam.gserviceaccount.com.

Em seguida, o utilizador cria um novo tópico do Pub/Sub com as credenciais de curta duração para se fazer passar pela conta de serviço. O Pub/Sub gera uma entrada de registo que identifica a conta de serviço, bem como o assunto do token do IdP:

{
  "logName": "projects/my-project/logs/cloudaudit.googleapis.com%2Factivity",
  "protoPayload": {
    "@type": "type.googleapis.com/google.cloud.audit.AuditLog",
    "authenticationInfo": {
      "principalEmail": "my-service-account@my-project.iam.gserviceaccount.com",
      "serviceAccountDelegationInfo": [
        {
          "principalSubject": "principal://iam.googleapis.com/projects/1234567890123/locations/global/workloadIdentityPools/aws-pool/subject/012345678901"
        }
      ]
    },
    "methodName": "google.pubsub.v1.Publisher.CreateTopic",
    "request": {
      "@type": "type.googleapis.com/google.pubsub.v1.Topic",
      "name": "projects/my-project/topics/my-topic"
    },
    "resourceName": "projects/my-project/topics/my-topic"
  },
  "resource": {
    "type": "pubsub_topic"
  }
}

O que se segue?