Si vous ne spécifiez pas de compte de service, Cloud Run associe une révision ou une tâche au compte de service par défaut qui dispose d'autorisations étendues sur toutes les API Google Cloud. Nous vous recommandons d'utiliser l'identité par service et d'accorder des autorisations sélectives à la place.
À propos du compte de service par défaut
Par défaut, les révisions et les tâches Cloud Run s'exécutent en tant que compte de service Compute Engine par défaut. Le compte de service Compute Engine par défaut dispose du rôle IAM Éditeur de projet qui accorde des autorisations de lecture et d'écriture sur toutes les ressources de votre projet Google Cloud.
Bien qu'il puisse être pratique d'utiliser le compte de service par défaut, Google recommande de créer votre propre compte de service géré par l'utilisateur avec les autorisations les plus précises possibles et d'attribuer ce compte de service en tant qu'identité de votre service ou tâche Cloud Run. Ce document explique comment configurer des identités par service avec Cloud Run.
Utiliser l'identité par service
Google recommande d'attribuer une identité dédiée à chaque service ou tâche Cloud Run en attribuant un compte de service géré par l'utilisateur plutôt que d'utiliser le compte de service par défaut. Les comptes de service gérés par l'utilisateur vous permettent de contrôler les accès en accordant un ensemble minimal d'autorisations à l'aide d'Identity and Access Management.
La CLI Google Cloud et les bibliothèques clientes Google Cloud détectent automatiquement leur exécution sur Google Cloud et utilisent le compte de service d'exécution de la version actuelle de Cloud Run. Cela signifie que si votre code utilise gcloud CLI ou une bibliothèque cliente Google Cloud officielle, il détecte et s'authentifie automatiquement en tant que compte de service d'exécution du service Cloud Run. Cette stratégie est appelée identifiants par défaut de l'application et permet la portabilité du code dans plusieurs environnements.
L'attribution d'une identité par service présente deux aspects :
- Les autorisations requises pour attribuer une identité par service
- Les autorisations dont l'identité attribuée elle-même a besoin pour fonctionner
Autorisations requises pour attribuer des comptes de service gérés par l'utilisateur
Pour déployer un service Cloud Run à l'aide d'un compte de service géré par l'utilisateur, vous devez être autorisé à emprunter l'identité (iam.serviceAccounts.actAs
) de ce compte de service. Cette autorisation peut être accordée via le rôle IAM roles/iam.serviceAccountUser
. Tous les comptes principaux (par exemple, les utilisateurs ou les comptes de service) doivent disposer de cette autorisation sur le compte de service géré par l'utilisateur pour pouvoir déployer un service Cloud Run en tant que compte de service géré par l'utilisateur.
Vous pouvez accorder cette autorisation à l'aide de la console Google Cloud, via l'API (YAML) ou à l'aide de gcloud CLI comme suit :
gcloud iam service-accounts add-iam-policy-binding "SERVICE_ACCOUNT_EMAIL" \
--member "PRINCIPAL" \
--role "roles/iam.serviceAccountUser"
Remplacez :
- SERVICE_ACCOUNT_EMAIL par l'adresse e-mail du compte de service, par exemple
PROJECT_NUMBER-compute@developer.gserviceaccount.com
. - PRINCIPAL par le compte principal pour lequel vous ajoutez la liaison. Utilisez le format
user:email
, par exempleuser:test-user@gmail.com
.
Pour savoir comment accorder des autorisations, consultez la page Accorder, modifier et révoquer les accès à des ressources.
Déployer un nouveau service avec un compte de service géré par l'utilisateur
Si vous ne possédez pas encore de compte de service géré par l'utilisateur, créez-en un.
Vous pouvez définir le compte de service du service Cloud Run à l'aide de la console Google Cloud, de gcloud CLI ou de l'API (YAML) lorsque vous créez un service ou déployez une nouvelle révision :
Console
Dans la console Google Cloud, accédez à Cloud Run :
Cliquez sur Créer un service si vous configurez un nouveau service sur lequel effectuer un déploiement. Si vous configurez un service existant, cliquez sur celui-ci puis sur Modifier et déployer la nouvelle révision.
Si vous configurez un nouveau service, remplissez la page initiale des paramètres du service selon vos besoins, puis cliquez sur Conteneur(s), volumes, mise en réseau et sécurité pour développer la page de configuration du service.
Cliquez sur l'onglet Security (Sécurité).
- Cliquez sur le menu déroulant Service account (Compte de service), puis sélectionnez le compte de service souhaité.
Cliquez sur Créer ou Déployer.
gcloud
Vous pouvez mettre à jour un service existant de façon à disposer d'un nouveau compte de service d'exécution à l'aide de la commande suivante :
gcloud run services update SERVICE --service-account SERVICE_ACCOUNT
Remplacez :
- SERVICE par le nom de votre service.
- SERVICE_ACCOUNT par le compte de service associé à la nouvelle identité. Cette valeur correspond à l'adresse e-mail du compte de service, par exemple
example@myproject.iam.gserviceaccount.com
.
Vous pouvez également définir un compte de service lors du déploiement à l'aide de la commande suivante :
gcloud run deploy --image IMAGE_URL --service-account SERVICE_ACCOUNT
Remplacez :
- IMAGE_URL par une référence à l'image de conteneur, par exemple
us-docker.pkg.dev/cloudrun/container/hello:latest
. Si vous utilisez Artifact Registry, le dépôt REPO_NAME doit déjà être créé. L'URL se présente sous la forme suivante :REGION-docker.pkg.dev/PROJECT_ID/REPO_NAME/PATH:TAG
. - SERVICE_ACCOUNT par le compte de service associé à la nouvelle identité. Cette valeur correspond à l'adresse e-mail du compte de service, par exemple
example@myservice.iam.gserviceaccount.com
.
YAML
Vous pouvez télécharger et afficher les configurations de service existantes à l'aide de la commande gcloud run services describe --format export
, qui renvoie les résultats nettoyés au format YAML.
Vous pouvez ensuite modifier les champs décrits ci-dessous et importer le fichier YAML modifié à l'aide de la commande gcloud run services replace
.
Veillez à ne modifier que les champs indiqués.
Pour afficher et télécharger la configuration, exécutez la commande suivante :
gcloud run services describe SERVICE --format export > service.yaml
Mettez à jour l'attribut
serviceAccountName:
:apiVersion: serving.knative.dev/v1 kind: Service metadata: name: SERVICE spec: template: spec: serviceAccountName: SERVICE_ACCOUNT
Remplacez :
- SERVICE par le nom de votre service Cloud Run ;
- SERVICE_ACCOUNT par le compte de service associé à la nouvelle identité. Cette valeur correspond à l'adresse e-mail du compte de service, par exemple
example@myproject.iam.gserviceaccount.com
.
Remplacez la configuration du service en utilisant la commande suivante :
gcloud run services replace service.yaml
Terraform
Pour savoir comment appliquer ou supprimer une configuration Terraform, consultez la page Commandes Terraform de base.
Pour créer un compte de service, ajoutez la ressource suivante à votre fichier main.tf
existant :
Créez ou mettez à jour un service Cloud Run et incluez votre compte de service :
Utiliser des comptes de service dans d'autres projets
Vous pouvez également utiliser un compte de service géré par l'utilisateur qui réside dans un projet Google Cloud différent de celui du service Cloud Run. Si le compte de service et le service Cloud Run se trouvent dans des projets différents :
Le projet contenant ce compte de service nécessite que la règle d'organisation
iam.disableCrossProjectServiceAccountUsage
soit définie sur "false/unenforced" (False/Non-appliqué) au niveau du dossier ou héritée des paramètres au niveau du projet. Par défaut, cette valeur est définie surtrue
.Le compte de service doit bénéficier du rôle
roles/iam.serviceAccountTokenCreator
pour l'agent de service du projet de déploiement :service-PROJECT_NUMBER@serverless-robot-prod.iam.gserviceaccount.com
où
PROJECT_NUMBER
est le numéro du projet.Le compte de service doit bénéficier du rôle
roles/iam.serviceAccountUser
pour l'identité (utilisateur ou automatisation) qui effectue l'opération de déploiement.
Vous pouvez attribuer des rôles directement à la ressource du compte de service ou hériter des niveaux supérieurs de la hiérarchie des ressources.
Autorisations requises par les comptes de service gérés par l'utilisateur pour exploiter Cloud Run
Si un service Cloud Run n'accède à aucune autre partie de Google Cloud, son compte de service ne doit pas disposer de rôles ni d'autorisations.
Lorsque vous créez un compte de service à partir de Google Cloud Console, l'étape facultative "Autoriser ce compte de service à accéder au projet" concerne tout accès supplémentaire requis. Par exemple, un service Cloud Run peut appeler un autre service Cloud Run privé ou il peut avoir besoin d'accéder à une base de données Cloud SQL, et ces actions nécessitent toutes deux des rôles IAM spécifiques. Pour en savoir plus, consultez la documentation sur la gestion des accès.
Récupérer des jetons d'identité et d'accès à l'aide du serveur de métadonnées
Si le code de votre service Cloud Run utilise une bibliothèque cliente Google Cloud, celle-ci obtient automatiquement les jetons d'accès pour authentifier les requêtes de votre code à l'aide du compte de service d'exécution du service.
Si vous utilisez votre propre code personnalisé, vous pouvez utiliser le serveur de métadonnées pour récupérer manuellement les jetons d'accès et d'identité. Notez que vous ne pouvez pas interroger ce serveur directement à partir de votre ordinateur local, car le serveur de métadonnées n'est disponible que pour les charges de travail exécutées sur Google Cloud.
Voici les deux types de jetons que vous pouvez récupérer avec le serveur de métadonnées :
- Des jetons d'accès OAuth 2.0, qui permettent d'appeler la plupart des API Google.
- Des jetons d'ID, qui permettent d'appeler d'autres services Cloud Run ou Cloud Functions, ou d'appeler un service pour valider un jeton d'ID.
Pour récupérer un jeton, sélectionnez l'une des options suivantes :
Jetons d'accès
Par exemple, si vous souhaitez créer un sujet Pub/Sub, utilisez la méthode projects.topics.create
.
Utilisez le serveur Compute Metadata pour récupérer un jeton d'accès :
curl "http://metadata.google.internal/computeMetadata/v1/instance/service-accounts/default/token" \ --header "Metadata-Flavor: Google"
Ce point de terminaison renvoie une réponse JSON avec un attribut
access_token
.Dans votre requête HTTP, la requête doit être authentifiée à l'aide d'un jeton d'accès dans l'en-tête
Authorization
:PUT https://pubsub.googleapis.com/v1/projects/
PROJECT_ID
/topics/TOPIC_ID
Authorization: BearerACCESS_TOKEN
Où :
PROJECT_ID
est l'ID de votre projet.TOPIC_ID
est l'ID de votre sujet.ACCESS_TOKEN
correspond au jeton d'accès que vous avez récupéré à l'étape précédente.
Solution :
{ "name": "projects/
PROJECT_ID
/topics/TOPIC_ID
" }
Jetons d'ID
Utilisez le serveur Compute Metadata pour récupérer un jeton d'identité avec une audience spécifique :
curl "http://metadata.google.internal/computeMetadata/v1/instance/service-accounts/default/identity?audience=AUDIENCE" \
--header "Metadata-Flavor: Google"
Où AUDIENCE
est l'audience JWT demandée.
Pour les services Cloud Run, l'audience doit être l'URL du service que vous appelez ou une audience personnalisée, telle qu'un domaine personnalisé, configurée pour le service.
https://service.domain.com
Pour les autres ressources, il s'agit probablement de l'ID client OAuth d'une ressource protégée par IAP :
1234567890.apps.googleusercontent.com
Obtenir des recommandations pour créer des comptes de service dédiés
L'outil de recommandation fournit automatiquement des recommandations pour la création d'un compte de service dédié avec un ensemble minimal d'autorisations requises.
Étapes suivantes
Découvrez comment gérer les accès à vos services ou authentifier les développeurs, les services et les utilisateurs finaux de manière sécurisée.
Pour découvrir un tutoriel détaillé portant sur une application utilisant l'identité du service afin de minimiser les risques de sécurité, suivez le tutoriel sur la sécurisation des services Cloud Run.