Exiger l'autorisation de rattacher des comptes de service aux ressources

Lorsque vous créez certaines ressources Google Cloud, vous avez la possibilité de rattacher un compte de service. Le compte de service rattaché agit comme l'identité de toute tâche exécutée sur la ressource, permettant ainsi aux tâches de s'authentifier auprès des API Google Cloud.

Pour la plupart des services Google Cloud, les utilisateurs doivent être autorisés à emprunter l'identité d'un compte de service pour pouvoir le rattacher à une ressource. En d'autres termes, l'utilisateur a besoin de l'autorisation iam.serviceAccounts.actAs sur le compte de service.

Cependant, certains services permettaient auparavant aux utilisateurs de rattacher des comptes de service aux ressources, même si ces derniers n'étaient pas autorisés à usurper l'identité des comptes de service. Cette configuration était susceptible de permettre aux utilisateurs de ces services d'obtenir des autorisations élevées non évidentes.

Le tableau suivant répertorie les services qui disposent de cette configuration, ainsi que l'ancien comportement de chaque service :

Service Ancien comportement
App Engine Les utilisateurs pouvaient déployer des applications App Engine (qui utilisent l'identité du compte de service App Engine par défaut), même s'ils n'étaient pas autorisés à emprunter l'identité du compte de service App Engine par défaut.
Cloud Composer Les utilisateurs pouvaient rattacher n'importe quel compte de service du projet à un environnement Cloud Composer, même s'ils n'avaient pas l'autorisation d'usurper l'identité de l'un des comptes de service du projet.
Cloud Data Fusion Les utilisateurs pouvaient associer le compte de service Compute Engine par défaut à des ressources, même s'ils n'étaient pas autorisés à emprunter l'identité du compte de service par défaut.
Dataflow
Dataproc

Nous exigeons désormais de ces services qu'ils vérifient que les utilisateurs sont autorisés à usurper l'identité des comptes de service lorsqu'ils les rattachent à des ressources. Toutefois, l'ancien comportement existe toujours pour les types d'organisations suivants :

  • Organisations avec des utilisateurs autorisés à déployer des applications App Engine, mais qui ne sont pas autorisés à emprunter l'identité du compte de service App Engine par défaut.
  • Organisations avec des utilisateurs autorisés à déployer des environnements Cloud Composer, mais qui ne sont pas autorisés à emprunter l'identité d'un compte de service.
  • Organisations avec des utilisateurs autorisés à déployer des ressources Cloud Data Fusion, Dataflow ou Dataproc, mais qui ne sont pas autorisés à emprunter l'identité du compte de service Compute Engine par défaut.

Si l'ancien comportement continue d'affecter votre organisation, vous recevrez une communication expliquant comment le désactiver manuellement. Pour obtenir des instructions détaillées, vous pouvez également vous reporter aux sections ci-dessous.

Sécuriser App Engine

Pour désactiver manuellement l'ancien comportement pour App Engine, assurez-vous que les utilisateurs sont autorisés à emprunter l'identité du compte de service App Engine. Activez ensuite une contrainte de règle d'administration pour appliquer des contrôles d'autorisation de compte de service lors du déploiement d'applications qui utilisent l'identité du compte de service App Engine par défaut.

  1. (Facultatif) Utilisez l'outil de recommandation IAM pour réduire le champ d'application des autorisations de façon sécurisée pour le compte de service App Engine par défaut.

    Le compte de service App Engine par défaut reçoit automatiquement le rôle très permissif Éditeur (roles/editor). Toutefois, nous ne recommandons pas l'utilisation d'un rôle aussi permissif dans les configurations de production.

  2. Assurez-vous que tous les utilisateurs qui déploient des applications peuvent emprunter l'identité du compte de service App Engine par défaut.

    Pour ce faire, attribuez aux utilisateurs un rôle incluant l'autorisation iam.serviceAccounts.actAs, tel que le rôle Utilisateur du compte de service (roles/iam.serviceAccountUser). Vous pouvez accorder ce rôle au niveau du projet ou du compte de service App Engine par défaut. Pour obtenir les instructions nécessaires, consultez Gérer l'usurpation d'un compte de service.

  3. Activez la contrainte de règle d'administration constraints/appengine.enforceServiceAccountActAsCheck pour appliquer des contrôles d'autorisation de compte de service lors du déploiement d'applications.

  4. (Facultatif) Utilisez l'outil d'application de règle d'administration booléenne pour vérifier que la contrainte de règle d'administration est bien appliquée dans tous vos projets.

Sécuriser Cloud Composer

Pour désactiver manuellement l'ancien comportement pour Cloud Composer, assurez-vous que les utilisateurs sont autorisés à emprunter l'identité des comptes de service qu'ils associent à de nouveaux environnements. Activez ensuite une contrainte de règle d'administration pour appliquer des contrôles d'autorisation de compte de service lors de l'association de comptes de service à des environnements.

  1. Identifiez tous les comptes de service associés à des environnements Cloud Composer :

    1. Dans Cloud Console, accédez à la page Environnements Composer.

      Accéder à la page Environnements Composer

    2. Cliquez sur le nom d'un environnement.

    3. Dans l'onglet Configuration de l'environnement, recherchez le champ Compte de service et notez le nom du compte de service.

    4. Répétez les étapes précédentes pour tous les environnements Cloud Composer de votre projet.

  2. Confirmez que ces comptes de service suivent le principe du moindre privilège :

  3. Assurez-vous que tous les utilisateurs qui déploient ou gèrent des environnements Cloud Composer ont la possibilité d'usurper l'identité des comptes de service utilisés par les environnements.

    Pour ce faire, attribuez aux utilisateurs un rôle qui inclut l'autorisation iam.serviceAccounts.actAs, comme le rôle "Utilisateur du compte de service" (roles/iam.serviceAccountUser). Vous pouvez accorder ce rôle sur le projet ou sur un compte de service individuel. Pour obtenir les instructions nécessaires, consultez Gérer l'usurpation d'un compte de service.

  4. Activez la contrainte de règle d'administration constraints/composer.enforceServiceAccountActAsCheck pour appliquer des contrôles d'autorisation de compte de service lors de l'association de comptes de service à des environnements.

  5. (Facultatif) Utilisez l'outil d'application de règle d'administration booléenne pour vérifier que la contrainte de règle d'administration est bien appliquée dans tous vos projets.

Sécuriser Dataproc, Dataflow et Cloud Data Fusion

Pour désactiver manuellement l'ancien comportement pour Dataproc, Dataflow et Cloud Data Fusion, assurez-vous que les utilisateurs sont autorisés à emprunter l'identité des comptes de service qu'ils associent à de nouvelles ressources. Activez ensuite des contraintes de règle d'administration pour appliquer des contrôles d'autorisation de compte de service lors de l'association de comptes de service à des ressources.

Suivez les instructions correspondant au type de compte de service que vous souhaitez rattacher à de nouvelles ressources :

  • Si vous souhaitez cesser de rattacher le compte de service Compute Engine par défaut à de nouvelles ressources, procédez comme suit :

    1. Créez un compte de service et attribuez-lui les rôles nécessaires pour exécuter des tâches sur la ressource. Veillez à suivre le principe du moindre privilège.

      Pour connaître les rôles dont un compte de service a besoin pour exécuter des tâches sur les ressources Dataproc, Dataflow et Cloud Data Fusion, consultez les pages suivantes :

    2. Autorisez tous les utilisateurs qui déploient ces ressources à usurper l'identité du nouveau compte de service.

      Pour ce faire, attribuez aux utilisateurs un rôle qui inclut l'autorisation iam.serviceAccounts.actAs, comme le rôle "Utilisateur du compte de service" (roles/iam.serviceAccountUser). Vous pouvez accorder ce rôle sur le projet ou sur le compte de service. Pour obtenir les instructions nécessaires, consultez Gérer l'usurpation d'un compte de service.

    3. Activez les contraintes de règle d'administration suivantes pour appliquer des contrôles d'autorisation de compte de service lors de l'association de comptes de service à des ressources.

      • constraints/dataflow.enforceComputeDefaultServiceAccountCheck
      • constraints/dataproc.enforceComputeDefaultServiceAccountCheck

      La contrainte de règle d'administration constraints/dataproc.enforceComputeDefaultServiceAccountCheck effectue également des contrôles d'autorisation pour Cloud Data Fusion.

    4. (Facultatif) Utilisez l'outil d'application de règle d'administration booléenne pour vérifier que les contraintes de règle d'administration sont bien appliquées dans tous vos projets.

    5. Lorsque vous déployez de nouvelles ressources, utilisez le nouveau compte de service au lieu du compte de service Compute Engine par défaut.

  • Si vous souhaitez continuer à rattacher le compte de service Compute Engine par défaut aux nouvelles ressources, procédez comme suit :

    1. (Facultatif) Utilisez l'outil de recommandation IAM pour réduire le champ d'application des autorisations de façon sécurisée pour le compte de service Compute Engine par défaut.

      Le compte de service Compute Engine par défaut reçoit automatiquement le rôle très permissif Éditeur (roles/editor). Toutefois, nous ne recommandons pas l'utilisation d'un rôle aussi permissif dans les configurations de production.

    2. Assurez-vous que tous les utilisateurs qui déploient ces ressources ont la possibilité d'usurper l'identité du compte de service Compute Engine par défaut.

      Pour ce faire, attribuez aux utilisateurs un rôle qui inclut l'autorisation iam.serviceAccounts.actAs, comme le rôle "Utilisateur du compte de service" (roles/iam.serviceAccountUser). Vous pouvez accorder ce rôle sur le projet ou sur le compte de service Compute Engine par défaut. Pour obtenir les instructions nécessaires, consultez Gérer l'usurpation d'un compte de service.

    3. Activez les contraintes de règle d'administration suivantes pour appliquer des contrôles d'autorisation de compte de service lors de l'association de comptes de service à des ressources.

      • constraints/dataflow.enforceComputeDefaultServiceAccountCheck
      • constraints/dataproc.enforceComputeDefaultServiceAccountCheck
    4. (Facultatif) Utilisez l'outil d'application de règle d'administration booléenne pour vérifier que les contraintes de règle d'administration sont bien appliquées dans tous vos projets.