ServicesÀ proposNotesContact Me contacter →
EN FR
Note

Authentification OIDC de Cloud Scheduler pour les déclencheurs HTTP

Comment Cloud Scheduler s'authentifie auprès des endpoints HTTP sécurisés via des tokens OIDC — les prérequis du compte de service, la configuration gcloud, et le pattern pour Cloud Functions et Cloud Run.

Planté
gcpdata engineeringautomation

Cloud Scheduler peut déclencher n’importe quel endpoint HTTP selon un planning cron. Lorsque l’endpoint cible nécessite une authentification — ce qui devrait être le cas pour tout ce qui est connecté à une infrastructure de données de production — Scheduler a besoin d’un moyen de prouver son identité. Le mécanisme standard sur GCP est les tokens OIDC.

Ce cas se présente le plus souvent lors de la planification de Cloud Functions ou de Cloud Run Jobs. Ces deux services peuvent exiger que les appelants présentent un token d’identité valide, et Cloud Scheduler peut être configuré pour en générer un et l’attacher automatiquement.

Comment fonctionne l’authentification OIDC

Les tokens OIDC (OpenID Connect) sont des tokens JWT à durée de vie courte et signés qui attestent une identité. Lorsque Cloud Scheduler effectue une requête HTTP avec l’authentification OIDC, il :

  1. Génère un token au nom du compte de service configuré
  2. Le signe avec l’infrastructure de Google
  3. L’attache en tant qu’en-tête Authorization: Bearer <token>
  4. Le service destinataire valide le token par rapport aux clés publiques de Google

Le service destinataire (Cloud Functions 2e génération, Cloud Run, ou tout endpoint qui valide les tokens d’identité GCP) vérifie que le token est valide et que l’identité dispose du rôle IAM correct pour invoquer l’endpoint.

Pour que cela fonctionne, le compte de service utilisé par Cloud Scheduler nécessite deux permissions :

  • roles/iam.serviceAccountTokenCreator sur lui-même — pour pouvoir générer des tokens en son propre nom
  • roles/cloudfunctions.invoker (ou roles/run.invoker) sur la ressource cible

Le script de configuration

Ce script configure un job Cloud Scheduler avec authentification OIDC pointant vers un déclencheur HTTP Cloud Function :

Terminal window
# Variables
FUNCTION_URL="YOUR_CLOUD_FUNCTION_TRIGGER_URL"
SCHEDULER_JOB_NAME="daily-dbt-run-job"
PROJECT_ID="YOUR_PROJECT_ID"
LOCATION="YOUR_LOCATION_ID"
SERVICE_ACCOUNT_EMAIL="YOUR_SERVICE_ACCOUNT_EMAIL"
TIME_ZONE="YOUR_TIME_ZONE"
CRON_SCHEDULE="0 7 * * *"  # daily at 7 AM by default


# Étape 1 : S'assurer que le compte de service a le rôle "Service Account Token Creator"
gcloud iam service-accounts add-iam-policy-binding $SERVICE_ACCOUNT_EMAIL \
    --member="serviceAccount:$SERVICE_ACCOUNT_EMAIL" \
    --role="roles/iam.serviceAccountTokenCreator" \
    --project=$PROJECT_ID
echo "Added Service Account Token Creator role to $SERVICE_ACCOUNT_EMAIL."


# Étape 2 : Créer le job Cloud Scheduler
gcloud scheduler jobs create http $SCHEDULER_JOB_NAME \
    --location=$LOCATION \
    --schedule="$CRON_SCHEDULE" \
    --http-method=GET \
    --uri=$FUNCTION_URL \
    --oidc-service-account-email=$SERVICE_ACCOUNT_EMAIL \
    --oidc-token-audience=$FUNCTION_URL \
    --time-zone="$TIME_ZONE" \
    --project=$PROJECT_ID
echo "Cloud Scheduler job created: $SCHEDULER_JOB_NAME"

Le paramètre --oidc-token-audience doit correspondre exactement à l’URL de la Cloud Function. Le token OIDC est limité à cette audience — un token généré pour une URL ne sera pas accepté par une URL différente.

Le piège LOCATION vs REGION

Les jobs Cloud Scheduler sont régionaux, et le paramètre LOCATION doit correspondre à la région où le service Scheduler est disponible. Il s’agit d’un sur-ensemble des régions Cloud Functions — la plupart des régions qui prennent en charge Cloud Functions prennent également en charge Cloud Scheduler, mais vérifiez les régions supportées si vous utilisez une région moins courante.

Pour Cloud Functions, FUNCTION_URL provient de la sortie du déploiement. Après gcloud functions deploy, l’URL est affichée comme httpsTriggerUrl. Vous pouvez également la récupérer avec :

Terminal window
gcloud functions describe dbt_run --region=europe-west1 --format="value(serviceConfig.uri)"

Format CRON et fuseaux horaires

Cloud Scheduler utilise le format cron Unix standard :

minute  hour  day-of-month  month  day-of-week
0       7     *             *      *            = tous les jours à 7h
0       */4   *             *      *            = toutes les 4 heures
30      6     *             *      1-5          = jours de semaine à 6h30

Le paramètre --time-zone accepte le format de la base de données tz (ex. Europe/Paris, America/New_York, UTC). Cela est important si votre pipeline de données a des dépendances temporelles — une “exécution à 7h” signifie des choses différentes selon les fuseaux horaires, et la valeur par défaut est UTC si vous ne le spécifiez pas.

Vous pouvez trouver des identifiants de fuseau horaire valides sur la liste tz database de Wikipedia ou en exécutant timedatectl list-timezones sur n’importe quelle machine Linux.

Cloud Run Jobs vs Cloud Functions

Le pattern OIDC s’applique aux deux, mais la configuration du job Scheduler diffère légèrement :

Pour Cloud Functions (déclencheur HTTP) :

Terminal window
gcloud scheduler jobs create http my-scheduler-job \
    --uri=$FUNCTION_URL \
    --http-method=GET \
    --oidc-service-account-email=$SA_EMAIL \
    --oidc-token-audience=$FUNCTION_URL \
    --schedule="0 7 * * *" \
    --location=$REGION

Pour Cloud Run Jobs :

Terminal window
gcloud scheduler jobs create http my-scheduler-job \
    --uri="https://$REGION-run.googleapis.com/apis/run.googleapis.com/v1/namespaces/$PROJECT_ID/jobs/$JOB_NAME:run" \
    --http-method=POST \
    --oauth-service-account-email=$SA_EMAIL \
    --schedule="0 7 * * *" \
    --location=$REGION

À noter : Cloud Run Jobs utilise --oauth-service-account-email (token OAuth 2.0), tandis que Cloud Functions utilise --oidc-service-account-email (token OIDC). Ce sont des mécanismes similaires mais les flags sont différents et ne sont pas interchangeables. Le Pattern de script de déploiement Cloud Run Jobs contient la version complète pour Cloud Run.

À noter également que pour Cloud Run, l’URI est l’endpoint de l’API Admin Cloud Run avec :run ajouté au nom du job, et non l’URL propre du job. C’est un point de confusion fréquent.

Tester le Scheduler

Après la configuration, déclenchez manuellement le scheduler pour vérifier la chaîne complète sans attendre l’heure planifiée :

Terminal window
gcloud scheduler jobs run daily-dbt-run-job --location=$LOCATION

Vérifiez ensuite les logs d’exécution de Cloud Function pour confirmer qu’il a bien reçu la requête et s’est exécuté avec succès :

Terminal window
gcloud functions logs read dbt_run --region=europe-west1 --limit=50

Si le scheduler se déclenche mais que la fonction retourne un 403, le compte de service manque du rôle roles/cloudfunctions.invoker. Si la fonction retourne un 401, l’audience du token OIDC ne correspond pas à l’URL de la fonction. Ces deux erreurs sont fréquentes lors du premier déploiement et sont faciles à corriger une fois identifiées.