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 Dataflow Dataproc	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.

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.

(Facultatif) Utilisez les recommandations de rôle 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.
Remarque : Pour renforcer la sécurité de votre organisation, vous pouvez désactiver les attributions automatiques de rôles pour les comptes de service.
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.
Remarque : Si vous disposez d'un grand nombre de projets, vous pouvez utiliser l'outil de recherche d'écarts d'autorisations pour identifier les utilisateurs pouvant déployer des applications, mais ne pouvant pas emprunter l'identité du compte de service App Engine par défaut.
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.

Remarque : Cette contrainte de règle d'administration n'est visible que dans les environnements avec l'ancien comportement. Si vous ne voyez pas la contrainte, cela signifie déjà qu'elle est déjà appliquée dans votre environnement.
(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.

Identifiez tous les comptes de service associés à des environnements Cloud Composer :
1. Dans la console Google Cloud, 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.
Confirmez que ces comptes de service suivent le principe du moindre privilège :
- Dans la console Google Cloud, accédez à la page IAM, recherchez les comptes de service et examinez leurs rôles.
  
  Accéder à la page IAM
- Si nécessaire, attribuez un rôle moins permissif au compte de service. Vous pouvez sélectionner un rôle dans la liste Rôles IAM prédéfinis, utiliser un rôle suggéré par une recommandation de rôle ou créer un rôle personnalisé.
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.
Remarque : Si vous disposez d'un grand nombre de projets, vous pouvez utiliser l'outil de recherche d'écarts d'autorisations pour identifier les utilisateurs pouvant déployer des environnements Cloud Composer, mais ne pouvant pas emprunter l'identité de comptes de service.
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.

Remarque : Cette contrainte de règle d'administration n'est visible que dans les environnements avec l'ancien comportement. Si vous ne voyez pas la contrainte, cela signifie déjà qu'elle est déjà appliquée dans votre environnement.
(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 :

Remarque : Dans Cloud Data Fusion, l'utilisation de comptes de service autres que le compte de service Compute Engine par défaut n'est disponible que pour les clients Cloud Data Fusion Enterprise. Pour en savoir plus, consultez Comptes de service Cloud Data Fusion.
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 :
  - Exigences relatives aux comptes de service Dataproc
  - Exigences relatives aux comptes de service Dataflow
  - Les comptes de service Cloud Data Fusion ont les mêmes exigences que les comptes de service Dataproc.
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.
  
  Remarque : Ces contraintes liées aux règles d'administration ne sont visibles que dans les environnements avec l'ancien comportement. Si vous ne voyez pas ces contraintes, cela signifie qu'elles sont déjà appliquées dans votre environnement.
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 les recommandations de rôle 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.
  Remarque : Pour renforcer la sécurité de votre organisation, vous pouvez désactiver les attributions automatiques de rôles pour les comptes de service.
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.
  Remarque : Si vous disposez d'un grand nombre de projets, vous pouvez utiliser l'outil de recherche d'écarts d'autorisations pour identifier les utilisateurs pouvant déployer des ressources, mais ne pouvant pas emprunter l'identité du compte de service Compute Engine par défaut.
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.