This document outlines the necessary steps to add Workload Identity Federation (WIF) support to the existing GCP authentication module in Vector.  These changes will allow Vector to authenticate using external_account credentials, enabling OIDC-based authentication using short-lived access tokens.

Key Tasks:

• Modify the GCP authentication logic to check first for external_account credentials type.
• Introduce new structs to handle new credential file format (ExternalCredentials, CredentialsType).
• Implement the WIF authentication flow:
  • Fetch the local OpenShift Service Account token from credentials file path.
  • Exchange the OpenShift token for a Google Identity Token via Google STS.
  • Exchange the Identity Token for an Access Token via IAM impersonation.

• Ensure compatibility with existing service account authentication.
• Define acceptance criteria to validate functionality.

Modify AuthConfig and add module to support external_account

• The existing logic for GCP authentication code is built for only service_account type credentials file.
• Implement a new token_source module by adding a check for the type field in the credentials JSON file.
• task: Add GcpAuthFileSource struct to determine whether the credentials file is a service account or an external account.

Introduce ExternalCredentials Struct

• This struct will hold the fields necessary for Workload Identity Federation.
• It includes all values necessary for OIDC authentication.
• task: Add ExternalCredentials struct  to map to the external_account credentials JSON format.

Implement WIF Authentication Flow

We need to check the credentials file type, then get the path and read the local token, then make two HTTP requests to the cloud api in order to authenticate via WIF:

1. Read the GCP credentials JSON file and determine which auth to implement (existing service_account type or new external_account type).
   • Extract credential_source.file path from the external_account file type
   • Read the OpenShift bound service account token from local file.   This token is typically located at /var/run/ocp-collector/serviceaccount/token.
2. Exchange for a Google Identity Token via STS:
   Send a POST request to the Security Token Service (STS) endpoint with the service account token to obtain a Google Identity Token.
3. Exchange the Identity Token for an Access Token via Google IAM impersonation:
   Send a POST request to the service_account_impersonation_url with the Identity Token to receive a short-lived Access Token.

Step 1: Read OpenShift Service Account Token

• The first token is a Bound Service Account Token, projected into the openshift pod
• We need to parse the credentials file to determine the type, then read the token from local disk ( wherever it is mounted)\
• Implement method to: get_credentials_type
• then a method to:  fetch_bound_service_account_token

Step 2: Exchange OpenShift Token for Google Identity Token (STS Request)

• The first API request sends the OpenShift service account token to Google Security Token Service (STS).
• Response should include a Google Identity Token.
• Implement method to: fetch_identity_token_from_sts

Step 3: Exchange Identity Token for Access Token (Impersonation Request)

• Exchange the Google Identity Token for a Google Access Token.
• Implement method to fetch_impersonated_token

5. Acceptance Criteria

• Ensure creds file and bound (ocp) service account token is correctly read.
• Verify STS request returns a valid Identity Token.
• Verify impersonation request returns a valid Access Token.
• Ensure existing service account authentication is unaffected.
• Confirm Stackdriver logs are sent successfully with the new access token.
• Create unit tests for get_creds_type, fetch_bound_service_account_token, fetch_identity_token_from_sts, and fetch_impersonated_token.