Use Workload Identity Federation for GCP auth
Nadie ha tomado este issue todavía.
Evaluación
- Dificultad
- 4/5
- Tiempo estimado
- 3-5 días
- Aptitud para principiantes
- 55/100
Línea de trabajo
Revisa primero .github/workflows/weekly_run.yml y el workflow pr_validation; después, confirma el GCP Workload Identity Pool/Provider y los dos secretos de repositorio indicados. Actualiza todos los workflows de GitHub para que utilicen credenciales de federación de corta duración, configura gcloud explícitamente solo donde sea necesario y elimina GCP_SERVICE_ACCOUNT_KEY después de confirmar que la integración funciona.
Escrito por el modelo de indexación a partir del texto del issue.
Descripción
This comment came up as part of a Copilot review in https://github.com/oppia/analytics-data-platform/pull/1#discussion_r3790752232:
This workflow relies on a long-lived service account JSON key and assumes gcloud is available on the runner. Prefer GitHub’s recommended GCP auth approach (Workload Identity Federation via google-github-actions/auth) and, if gcloud is needed, install/configure it explicitly (e.g., google-github-actions/setup-gcloud). This reduces key-leak risk and avoids failures on runners without gcloud.
If we go this route, this would need to be done for all our github workflows (e.g. pr_validation and weekly_run). It requires setting up a Workload Identity Pool/Provider in GCP and adding two new repo secrets, GCP_WORKLOAD_IDENTITY_PROVIDER and GCP_SERVICE_ACCOUNT_EMAIL, then removing the old GCP_SERVICE_ACCOUNT_KEY secret once the integration is confirmed working.
Sample patch file with expected changes:
--- a/.github/workflows/weekly_run.yml
+++ b/.github/workflows/weekly_run.yml
@@ -9,7 +9,7 @@ name: Weekly Production Analytics Run
#
# Environment Target: Production (oppia-analytics-prod)
# Key Operations:
-# 1. Authenticates to GCP using an automated service account.
+# 1. Authenticates to GCP via Workload Identity Federation (no long-lived keys).
# 2. Dynamically isolates database credentials to prevent local Git leaks.
# 3. Runs data quality assertions and transforms fresh production analytics logs.
# ==============================================================================
@@ -25,6 +25,9 @@ jobs:
dbt_run:
name: Execute dbt Production Pipeline
runs-on: ubuntu-latest
+ permissions:
+ contents: read
+ id-token: write # required to mint the OIDC token for Workload Identity Federation
steps:
# Clone the repository codebase onto the temporary GitHub virtual runner
@@ -43,21 +46,14 @@ jobs:
pip install --upgrade pip
pip install dbt-bigquery
- # Exchange GitHub secret tokens for active, authenticated Google Cloud sessions
- - name: Authenticate to GCP Natively
- run: |
- # Write the secret JSON token safely as a raw literal string
- cat << 'EOF' > ${HOME}/gcp_key.json
- ${{ secrets.GCP_SERVICE_ACCOUNT_KEY }}
- EOF
-
- # Activate the service account using the pre-installed gcloud CLI
- gcloud auth activate-service-account --key-file=${HOME}/gcp_key.json
-
- # Set the application default credentials environment variable for dbt
- echo "GOOGLE_APPLICATION_CREDENTIALS=${HOME}/gcp_key.json" >> $GITHUB_ENV
+ # Keyless auth: exchanges a GitHub OIDC token for short-lived GCP credentials
+ - name: Authenticate to GCP via Workload Identity Federation
+ uses: google-github-actions/auth@v2
+ with:
+ workload_identity_provider: ${{ secrets.GCP_WORKLOAD_IDENTITY_PROVIDER }}
+ service_account: ${{ secrets.GCP_SERVICE_ACCOUNT_EMAIL }}
- # Generate a production connection profile using service-account credentials
+ # Generate a production connection profile using the ADC credentials from the auth step
- name: Create dynamic profiles.yml for dbt
run: |
cat << EOF > profiles.yml
@@ -66,8 +62,7 @@ jobs:
outputs:
prod:
type: bigquery
- method: service-account
- keyfile: ${{ env.GOOGLE_APPLICATION_CREDENTIALS }}
+ method: oauth
project: oppia-analytics-prod
dataset: analytics_production
threads: 4
- Lenguaje dominante
- Sin datos de lenguaje
- Estrellas
- 0
- Forks
- 1
- Métricas de merge de PR
- Sin PR fusionados en 30 d
Preparar el entorno
Este proyecto no incluye contenedor de desarrollo, Dockerfile ni guía de contribución, así que la configuración corre por tu cuenta: empieza por su README y consulta nuestra guía para la primera contribución para los pasos generales.
Primeros pasos
- Lee el issue completo y luego la guía de contribución del proyecto.
- Comenta en el issue que vas a ocuparte — evita que dos personas hagan lo mismo.
- Haz un fork del repositorio y trabaja en una rama.
- Abre un pull request que haga referencia al número del issue.
Issues similares
-
Dificultad 2/5 1-3 horas Aptitud para principiantes 78/100
Los mantenedores suelen responder en 1 día
-
[guide] AGENTS.md claims the coverage gate, e2e and full lint run on every PR after ADR 0011 focused validationPosiblemente ocupada @hivecommons-hive la tomó hoy. Abiertoagent/guide documentation hive/claimed-by-guide stage/040-covered-by-pr
Dificultad 2/5 1-3 horas Aptitud para principiantes 81/100
cncf/endusers#2006 · 1 comentario ·
Los mantenedores suelen responder en 1 día
-
Dificultad 1/5 1-3 horas Aptitud para principiantes 76/100
Los mantenedores suelen responder en 1 día
-
Dificultad 2/5 1-3 horas Aptitud para principiantes 76/100
Los mantenedores suelen responder en 1 día
-
Mend: dependency security vulnerability untriaged
Dificultad 2/5 1-3 horas Aptitud para principiantes 66/100
opensearch-project/agent-health#603 ·
Los mantenedores suelen responder en 2 días