Identité des fonctions (1re génération)

Remarque : Ce contenu ne s'applique qu'aux fonctions Cloud Run (1re génération) (anciennement Cloud Functions (1re génération).)

Pour obtenir la version de ce document correspondant à Cloud Run Functions, consultez Identité de la fonction.

Pour la plupart des interactions entre les entités dans Google Cloud, chaque entité doit posséder une identité vérifiable, sécurisée à l'aide d'un secret, tel qu'un mot de passe ou une clé. Tout comme les autres entités ont besoin d'une identité pour accéder à Cloud Run Functions, les fonctions elles-mêmes ont souvent besoin d'accéder à d'autres ressources dans Google Cloud pour effectuer leur travail. Chaque fonction est associée à un compte de service qui sert d'identité lorsque la fonction accède à d'autres ressources. Le compte de service utilisé par une fonction en tant qu'identité est également appelé compte de service d'exécution.

Pour une utilisation en production, Google recommande d'attribuer une identité dédiée à chaque fonction en lui attribuant un compte de service géré par l'utilisateur. 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.

Compte de service d'exécution

À moins que vous ne spécifiez un autre compte de service d'exécution lors du déploiement d'une fonction, Cloud Run Functions utilise un compte de service par défaut comme identité pour l'exécution de la fonction :

• Les fonctions Cloud Run utilisent le compte de service App Engine par défaut, [e-mail].

  Notez que le numéro de projet est différent de l'ID du projet et du nom du projet. Le numéro de projet se trouve sur la page du tableau de bord de la console Google Cloud.

Ces comptes de service par défaut disposent du rôle d'éditeur, ce qui leur permet d'accéder à de nombreux services Google Cloud. Bien qu'il s'agisse du moyen le plus rapide de développer des fonctions, Google recommande d'utiliser le compte de service par défaut à des fins de test et de développement uniquement. Pour la production, vous ne devez attribuer au compte de service que l'ensemble minimal d'autorisations requis pour atteindre son objectif.

Pour sécuriser vos fonctions en production, procédez comme suit :

• Modifier les autorisations sur le compte de service d'exécution par défaut, ou
• Créer des comptes de service individuels pour vos fonctions

Modifier les autorisations sur le compte de service d'exécution par défaut

Avertissement : La modification des autorisations sur le compte de service par défaut App Engine ou le compte de service Compute par défaut affecte toutes les ressources associées à ces comptes de service, incluant potentiellement d'autres services Cloud Run Functions et App Engine et d'autres ressources Compute Engine.

Console

1. Accédez à la page "IAM" de la console Google Cloud :

   Accéder à Google Cloud Console

2. Dans le tableau, sélectionnez le compte de service App Engine par défaut ou le compte de service Compute par défaut.

3. Cliquez sur l'icône de crayon à droite de la ligne pour afficher l'onglet Modifier les autorisations.

4. Ajoutez ou supprimez des rôles dans la liste déroulante Rôle pour définir l'accès selon le principe du moindre privilège.

5. Cliquez sur Enregistrer.

gcloud

Supprimez le rôle d'éditeur, puis exécutez la commande gcloud projects add-iam-policy-binding pour ajouter un rôle :

# Remove the Editor role
gcloud projects remove-iam-policy-binding PROJECT_ID \
--member="SERVICE_ACCOUNT_EMAIL" \
--role="roles/editor"

# Add the desired role
gcloud projects add-iam-policy-binding PROJECT_ID \
--member="SERVICE_ACCOUNT_EMAIL" \
--role="ROLE"

Où PROJECT_ID est l'ID du projet que vous utilisez, SERVICE_ACCOUNT_EMAIL est l'adresse e-mail du compte de service d'exécution par défaut, comme indiqué précédemment dans Compte de service d'exécution, et ROLE est le nouveau rôle à attribuer au compte de service d'exécution par défaut.

Utiliser des comptes de service individuels pour vos fonctions

Pour plus de flexibilité dans le contrôle des accès à vos fonctions, vous pouvez octroyer à chacune d'elles son propre compte de service géré par l'utilisateur.

1. Créez le compte de service. Notez son nom.
2. Accordez-lui les rôles appropriés, en fonction des ressources auxquelles la fonction doit accéder pour effectuer son travail.

3. Si le compte de service et la fonction se trouvent dans des projets différents, procédez comme suit dans le projet où se trouve le compte de service :

   1. Configurez le compte de service pour qu'il fonctionne sur tous les projets.

   2. Attribuez le rôle de créateur de jetons de compte de service (roles/iam.serviceAccountTokenCreator) à l'agent de service Cloud Run Functions ([e-mail]), où PROJECT fait référence au projet dans lequel réside la fonction. L'agent de service Cloud Run Functions gère l'accès entre projets de votre compte de service.

   3. Accordez l'autorisation iam.serviceaccounts.actAs à l'agent de service Cloud Run Functions sur le compte de service de l'autre projet.

4. Accordez au compte de service l'accès à la ressource. La façon de procéder dépend du type de ressource.

5. Associez le compte de service à la fonction. Vous pouvez définir cette association au moment du déploiement, ou en mettant à jour une fonction précédemment déployée.

Remarque : Pour déployer une fonction avec un compte de service autre que celui par défaut, l'utilisateur à l'origine du déploiement doit disposer de l'autorisation iam.serviceAccounts.actAs sur le compte de service en cours de déploiement. Si vous avez créé le compte de service, cette autorisation vous est automatiquement accordée. Dans le cas contraire, une personne disposant des autorisations appropriées doit vous accorder cette autorisation sur le compte de service.

Ajouter un compte de service géré par l'utilisateur lors du déploiement

Console

1. Accédez à Google Cloud Console :

   Accéder à Google Cloud Console

2. Spécifiez et configurez la fonction selon vos besoins.

3. Cliquez sur Exécution, compilation... pour afficher des paramètres supplémentaires.

4. Sélectionnez l'onglet Environnement d'exécution.

5. Cliquez sur le menu déroulant Compte de service, puis sélectionnez le compte de service souhaité.

6. Cliquez sur Suivant puis sur Déployer.

gcloud

Lorsque vous déployez une fonction à l'aide de gcloud functions deploy, ajoutez l'option --service-account. Exemple :

gcloud functions deploy --no-gen2 FUNCTION_NAME --service-account SERVICE_ACCOUNT_EMAIL

Où FUNCTION_NAME est le nom de votre fonction et SERVICE_ACCOUNT_EMAIL est l'adresse e-mail du compte de service.

Mettre à jour le compte de service d'une fonction existante

Vous pouvez mettre à jour le compte de service d'exécution d'une fonction existante.

Console

1. Accédez à Google Cloud Console :

   Accéder à Google Cloud Console

2. Cliquez sur le nom de la fonction souhaitée pour accéder à sa page d'informations.

3. Cliquez sur le crayon Modifier situé en haut de la page d'informations pour modifier la fonction.

4. Cliquez sur Exécution, compilation... pour afficher des paramètres supplémentaires.

5. Sélectionnez l'onglet Environnement d'exécution.

6. Cliquez sur le menu déroulant Compte de service, puis sélectionnez le compte de service souhaité.

7. Cliquez sur Suivant puis sur Déployer.

gcloud

Lorsque vous déployez une fonction à l'aide de gcloud functions deploy, ajoutez l'option --service-account :

gcloud functions deploy FUNCTION_NAME --service-account SERVICE_ACCOUNT_EMAIL

Où FUNCTION_NAME est le nom de votre fonction et SERVICE_ACCOUNT_EMAIL est le compte de service.

La fonction redéployée utilise désormais le nouveau compte de service d'exécution.

Utiliser le serveur de métadonnées pour acquérir des jetons

Bien que les comptes de service définis par IAM soient la méthode privilégiée pour l'identification et l'autorisation dans Google Cloud, certains services peuvent nécessiter d'autres modes, tels qu'une clé API, un client OAuth 2.0 ou une clé de compte de service. L'accès à une ressource externe peut également nécessiter d'autres méthodes.

Si votre service cible nécessite la génération d'un jeton d'identité OpenID Connect ou d'un jeton d'accès Oauth 2.0, vous pouvez peut-être utiliser le serveur Compute Metadata pour récupérer ces jetons, plutôt que de configurer un client OAuth complet.

Remarque : Vous ne pouvez pas interroger le serveur de métadonnées directement à partir de votre ordinateur local.

Jetons d'identité

Le serveur Compute Metadata permet de récupérer des jetons d’identité pour une audience spécifique de la façon suivante :

curl "http://metadata.google.internal/computeMetadata/v1/instance/service-accounts/default/identity?audience=AUDIENCE" \
  -H "Metadata-Flavor: Google"

Où AUDIENCE correspond à l'audience demandée, par exemple, l'URL d'un service que vous appelez, telle que https://service.domain.com, ou à l'ID client OAuth d'une ressource IAP protégée, comme 1234567890.apps.googleusercontent.com.

Jetons d'accès

Les jetons d'accès OAuth 2.0 utilisent des champs d'application pour définir les autorisations d'accès. Par défaut, les jetons d'accès Google Cloud ont le champ d'application cloud-platform. Pour accéder à d'autres API Google ou Google Cloud, vous devez récupérer un jeton d'accès avec un champ d'application approprié.

Vous pouvez utiliser le serveur Compute Metadata pour récupérer des jetons d'accès.

Si vous avez besoin d'un jeton d'accès avec un champ d'application spécifique, vous pouvez le générer de la façon suivante :

curl "http://metadata.google.internal/computeMetadata/v1/instance/service-accounts/default/token?scopes=SCOPES" \
  -H "Metadata-Flavor: Google"

où SCOPES correspond à une liste de champs d'application OAuth séparés par une virgule, par exemple, https://www.googleapis.com/auth/drive,https://www.googleapis.com/auth/spreadsheets.

Consultez la liste complète des champs d'application Google OAuth pour trouver ceux dont vous avez besoin.

Remarque :Le paramètre de requête ?scopes= n'est disponible que dans App Engine et les fonctions Cloud Run.

Étapes suivantes

Apprenez à autoriser l'accès à vos fonctions ou à authentifier les développeurs et autres fonctions pour qu'ils puissent appeler vos fonctions.