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 à usurper 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
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 rattacher le compte de service Compute Engine par défaut aux ressources, même s'ils n'avaient pas l'autorisation d'usurper son identité.
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 ressources Cloud Data Fusion, Dataflow ou Dataproc, mais qui ne sont pas autorisés à usurper l'identité du compte de service Compute Engine par défaut.
  • Organisations avec des utilisateurs autorisés à déployer des environnements Cloud Composer, mais qui ne sont pas autorisés à usurper l'identité d'un compte de service.

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 Cloud Composer

Pour désactiver manuellement l'ancien comportement pour Cloud Composer, assurez-vous d'abord que les utilisateurs sont autorisés à usurper l'identité des comptes de service qu'ils associent aux nouvelles ressources. Ensuite, activez une contrainte de règle d'administration pour exiger une autorisation lorsque les comptes de service sont rattachés aux ressources.

  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 suivante pour exiger l'autorisation iam.serviceAccounts.actAs lors de la liaison d'une ressource à un compte de service :

    • constraints/composer.enforceServiceAccountActAsCheck
  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 précédente est appliquée dans tous vos projets.

Sécuriser Dataproc, Dataflow et Cloud Data Fusion

Pour désactiver manuellement l'ancien comportement de Dataproc, Dataflow et Cloud Data Fusion, commencez par vous assurer que les utilisateurs sont autorisés à usurper l'identité des comptes de service qu'ils rattachent aux nouvelles ressources. Activez ensuite les contraintes des règles d'administration pour exiger une autorisation lors du rattachement 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 exiger l'autorisation iam.serviceAccounts.actAs lors de la liaison d'une ressource à un compte de service :

      • 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 précédentes sont 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. Utilisez l'outil de recommandation IAM pour désactiver en toute sécurité les autorisations du compte de service Compute Engine par défaut.

      Le compte de service Compute Engine par défaut se voit automatiquement attribuer le rôle d'"Éditeur" qui est très permissif. Toutefois, nous déconseillons d'utiliser 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 exiger l'autorisation iam.serviceAccounts.actAs lors de la liaison d'une ressource à un compte de service :

      • 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 précédentes sont appliquées dans tous vos projets.