Authentifier les développeurs

Outre les actions administratives telles que la création, la mise à jour et la suppression de services, les développeurs souhaitent souvent tester des services en privé avant de les lancer publiquement. Cette option concerne les services Cloud Run et non les jobs Cloud Run.

Avant de commencer

Veillez à bien accorder des autorisations d'accès aux services auxquels vous vous authentifiez. Vous devez attribuer le rôle Demandeur Cloud Run au développeur ou au groupe de développeurs :

Console (UI)

  1. Accédez à Google Cloud Console :

    Accéder à Google Cloud Console

  2. Sélectionnez le service, mais ne cliquez pas dessus.

  3. Cliquez sur l'onglet Autorisations dans le panneau latéral droit. (Vous devrez peut-être d'abord cliquer sur Afficher le panneau d'informations dans l'angle supérieur droit.)

  4. Cliquez sur Ajouter un compte principal.

  5. Dans le champ Nouveaux comptes principaux, saisissez l'adresse e-mail du compte de développeur.

  6. Sélectionnez le rôle Cloud Run Invoker dans le menu déroulant Rôle.

  7. Cliquez sur Enregistrer.

gcloud

Utilisez la commande gcloud run services add-iam-policy-binding :

gcloud run services add-iam-policy-binding SERVICE \
  --member='USER:EMAIL' \
  --role='roles/run.invoker'

Où :

  • SERVICE est le nom du service ;
  • USER correspond à la valeur user ou group selon que vous autorisez un développeur individuel ou un groupe de développeurs ;

  • EMAIL est le compte de messagerie.

    Exemple :

    gcloud run services add-iam-policy-binding myservice \
--member='user:test-user@gmail.com' \
--role='roles/run.invoker'

Tester votre service privé

Vous pouvez utiliser le proxy Cloud Run ou curl pour tester votre service privé.

Utiliser le proxy Cloud Run dans Google Cloud CLI

Le moyen le plus simple de tester vos services privés consiste à utiliser le proxy Cloud Run dans Google Cloud CLI. Le service privé est relayé par proxy à http://localhost:8080 (ou au port spécifié avec --port), en fournissant le jeton du compte actif ou un autre jeton que vous spécifiez. Cela vous permet d'utiliser un navigateur Web ou un outil tel que curl. Il s'agit de la méthode recommandée pour tester en privé un site Web ou une API dans votre navigateur.

Vous pouvez relayer un service en local par proxy à l'aide de la ligne de commande suivante dans un environnement Linux, macOS, WSL (de préférence) ou cygwin :

gcloud run services proxy SERVICE --project PROJECT-ID

Utiliser curl

Vous pouvez également tester des services privés sans le proxy en utilisant un outil tel que curl et en transmettant un jeton d'authentification dans l'en-tête Authorization :

curl -H "Authorization: Bearer $(gcloud auth print-identity-token)" SERVICE_URL

Pour que la commande curl fonctionne, vous devez transmettre un jeton d'identité valide pour un utilisateur disposant de l'autorisation run.routes.invoke, tel que Administrateur Cloud Run ou Demandeur Cloud Run. Consultez la page Rôles IAM Cloud Run pour obtenir la liste complète des rôles et des autorisations associées.

Pour obtenir un jeton d'ID valide pour l'identité connectée à la gcloud CLI, utilisez la commande gcloud auth print-identity-token. Vous pouvez utiliser des jetons créés par la gcloud CLI pour appeler des requêtes HTTP dans n'importe quel projet, à condition que votre compte dispose de l'autorisation run.routes.invoke sur le service.

À des fins de développement, utilisez les jetons d'ID générés par la gcloud CLI. Notez toutefois que ces jetons ne sont pas revendiqués, ce qui les rend sensibles aux attaques par répétitions. Dans les environnements de production, utilisez des jetons d'ID émis pour un compte de service avec l'audience appropriée spécifiée. Cette approche améliore la sécurité en limitant l'utilisation des jetons au service prévu uniquement. Pour les comptes autres que Google, utilisez la fédération des identités des employés pour appeler votre service Cloud Run afin que vous n'ayez pas à télécharger de clé de compte de service.

Nous vous recommandons d'allouer l'ensemble minimal d'autorisations requises pour développer et utiliser vos services. Assurez-vous que les stratégies IAM associées à vos services sont limitées au nombre minimal d'utilisateurs et de comptes de service.