Rôles IAM pour les postes liés au réseau

Cette rubrique explique comment configurer les autorisations IAM (Identity and Access Management) pour des scénarios de mise en réseau. Elle fournit des indications sur les rôles IAM qu'il convient d'attribuer aux rôles fonctionnels liés à la mise en réseau dans votre entreprise pour ces différents scénarios. Ce contenu est principalement destiné aux administrateurs réseau et aux employés qui gèrent des tâches de mise en réseau pour une organisation. Les scénarios décrits ci-dessous supposent tous qu'une organisation Google Cloud est configurée.

Ce document ne décrit pas en détail les rôles ni les autorisations relatifs à la mise en réseau. Pour une description détaillée des rôles et des autorisations associés aux API de calcul et de mise en réseau, consultez la section Rôles IAM prédéfinis Compute Engine.

Une seule équipe gère la sécurité et le réseau pour toute l'organisation

Dans ce scénario, une grande organisation dispose d'une équipe centrale qui gère les contrôles de sécurité et de mise en réseau pour l'ensemble de cette organisation. Les développeurs ne sont pas autorisés à modifier les paramètres de réseau ou de sécurité définis par l'équipe chargée de la sécurité et de la mise en réseau, mais ils ont l'autorisation de créer des ressources telles que des machines virtuelles dans des sous-réseaux partagés.

Pour faciliter cela, l'organisation utilise un VPC (Virtual Private Cloud) partagé. Un VPC partagé permet de créer un réseau VPC d'espaces IP RFC 1918, que les projets (de service) associés peuvent ensuite utiliser. Les développeurs utilisant les projets associés peuvent créer des instances de machine virtuelle dans les espaces réseau VPC partagés. Les administrateurs réseau et de sécurité de l'organisation peuvent créer des sous-réseaux, des VPN et des règles de pare-feu utilisables par tous les projets du réseau VPC.

Les tableaux ci-dessous décrivent les rôles IAM qu'il convient d'attribuer à l'équipe de sécurité et d'administration et à l'équipe de développement, ainsi que le niveau de ressource pour lequel ces rôles doivent être attribués.

Ressource : Organisation
Rôles : Administrateur de VPC partagé
Administrateur réseau
Administrateur de sécurité
Compte principal : Équipe de sécurité et d'administration réseau
Ressource : Projet hôte Ce rôle accorde la permission d'utiliser des sous-réseaux partagés par le VPC partagé.
Rôle : Utilisateur du réseau
Compte principal : Développeurs
Ressource : Projet de service Notez que ce rôle autorise l'utilisation d'adresses IP externes. Reportez-vous à la remarque ci-dessous pour savoir comment éviter cette action.
Rôle : compute.instanceAdmin
Compte principal : Développeurs

Pour ce scénario, vous avez besoin de trois stratégies d'autorisation distinctes : une pour l'organisation, une pour le projet hôte et une pour les projets de service.

La première stratégie d'autorisation, qui doit être associée au niveau de l'organisation, accorde à l'équipe réseau et de sécurité les rôles nécessaires à l'administration des projets hôtes de VPC partagé. Cela inclut la possibilité d'associer des projets de service au projet hôte. Cette stratégie permet également à l'équipe réseau et de sécurité de gérer toutes les ressources réseau et de sécurité disponibles dans tous les projets de l'organisation.

{
  "bindings": [
    {
      "role": "roles/compute.xpnAdmin",
      "members": [
        "group:sec-net@example.com"
      ]
    },
    {
      "role":"roles/compute.networkAdmin",
      "members": [
        "group:sec-net@example.com"
      ]
    },
    {
      "role": "roles/compute.securityAdmin",
      "members": [
        "group:sec-net@example.com"
      ]
    }
  ]
}

La deuxième stratégie d'autorisation doit être associée au projet hôte. Elle permet aux développeurs de l'organisation d'utiliser les réseaux partagés dans le projet hôte de VPC partagé.

{
  "bindings": [
    {
      "role": "roles/compute.networkUser",
      "members": [
        "group:developers@example.com"
      ]
    }
  ]
}

La troisième stratégie d'autorisation doit être associée à chaque projet de service. Elle permet aux développeurs utilisant le projet de gérer des instances dans le projet de service, avec la possibilité d'utiliser les sous-réseaux partagés définis dans le projet hôte.

Vous pourriez placer tous les projets de service dans un dossier et définir cette stratégie d'autorisation particulière à ce niveau de la hiérarchie. Dans ce cas, tous les projets créés dans ce dossier pourraient hériter des autorisations définies dans le dossier dans lequel le projet de service a été créé.

Vous devez également attribuer aux développeurs le rôle d'utilisateur de réseau dans le projet de service.

{
  "bindings": [
    {
      "role": "roles/compute.networkUser",
      "members": [
        "group:developers@example.com"
        ]
    },
    {
      "role": "roles/compute.instanceAdmin",
      "members": [
        "group:developers@example.com"
        ]
    }
  ]
}

Il est recommandé d'utiliser des groupes afin de gérer les comptes principaux. Dans l'exemple ci-dessus, vous devez ajouter les ID utilisateur des utilisateurs gérant les contrôles de sécurité et les contrôles réseau au groupe sec-net, et ceux des développeurs, au groupe developers. Lorsque vous devez modifier la liste des personnes autorisées à assurer la fonction, il vous suffit de modifier les membres du groupe, ce qui vous évite de mettre à jour la stratégie d'autorisation.

Les équipes réseau et de sécurité sont séparées

Dans ce scénario, une grande entreprise dispose de deux équipes centrales : l'une est chargée des contrôles de sécurité et l'autre gère toutes les autres ressources réseau pour l'ensemble de l'organisation. Les développeurs ne sont pas autorisés à modifier les paramètres de réseau ou de sécurité définis par l'équipe chargée de la sécurité et de la mise en réseau, mais ils ont l'autorisation de créer des ressources telles que des machines virtuelles dans des sous-réseaux partagés.

Comme dans le premier scénario, il faudra utiliser un VPC partagé et configurer les autorisations appropriées pour les trois groupes (réseau, sécurité et développeurs).

Les tableaux ci-dessous décrivent les rôles IAM à attribuer à l'équipe de sécurité et d'administration et à l'équipe de développement, ainsi que le niveau de ressource auquel les rôles sont attribués.

Ressource : Organisation
Rôles : Administrateur de VPC partagé
Administrateur réseau
Compte principal : Équipe d'administration réseau
Ressource : Organisation
Rôles : Administrateur de sécurité
Administrateur de l'organisation
Compte principal : Équipe de sécurité
Ressource : Projet hôte Ce rôle accorde la permission d'utiliser des sous-réseaux partagés par le VPC partagé.
Rôle : Utilisateur du réseau
Compte principal : Développeurs
Ressource : Projet de service Notez que ce rôle autorise l'utilisation d'adresses IP externes. Reportez-vous à la remarque ci-dessous pour savoir comment éviter cette action.
Rôle : compute.instanceAdmin
Compte principal : Développeurs

Pour ce scénario, vous avez besoin de trois stratégies d'autorisation distinctes : une pour l'organisation, une pour le projet hôte et une pour les projets de service.

La première stratégie d'autorisation, qui doit être associée au niveau de l'organisation, attribue à l'équipe réseau les rôles nécessaires pour administrer les projets hôtes de VPC partagé et gérer toutes les ressources réseau. Cela inclut la possibilité d'associer des projets de service au projet hôte. Le rôle d'administrateur réseau permet également à l'équipe réseau de visualiser les règles de pare-feu, mais pas de les modifier. Cette stratégie permet également à l'équipe de sécurité de définir les stratégies d'autorisation ainsi que de gérer les règles de pare-feu et les certificats SSL dans tous les projets de l'organisation.

{
  "bindings": [
  {
    "role": "roles/compute.xpnAdmin",
    "members": [
      "group:networks@example.com"
      ]
  },
  {
    "role": "roles/compute.networkAdmin",
    "members": [
      "group:networks@example.com"
      ]
  },
  {
    "role": "roles/compute.securityAdmin",
    "members": [
      "group:security@example.com"
      ]
    },
    {
      "role": "roles/resourcemanager.organizationAdmin",
      "members": [
        "group:security@example.com"
        ]
    }
  ]
}

La deuxième stratégie d'autorisation doit être associée au projet hôte. Elle permet aux développeurs de l'organisation d'utiliser les réseaux partagés dans le projet hôte de VPC partagé.

{
  "bindings": [
    {
      "role": "roles/compute.networkUser",
      "members": [
        "group:developers@example.com"
        ]
    }
  ]
}

La troisième stratégie d'autorisation doit être associée à chaque projet de service. Elle permet aux développeurs utilisant le projet de gérer des instances dans le projet de service, avec la possibilité d'utiliser les sous-réseaux partagés définis dans le projet hôte.

Vous pourriez placer tous les projets de service dans un dossier et définir cette stratégie d'autorisation particulière à ce niveau de la hiérarchie. Dans ce cas, tous les projets créés dans ce dossier pourraient hériter des autorisations définies dans le dossier dans lequel le projet de service a été créé.

{
  "bindings": [
    {
      "role": "roles/compute.networkUser",
      "members": [
        "group:developers@example.com"
        ]
      },
      {
        "role": "roles/compute.instanceAdmin",
        "members": [
          "group:developers@example.com"
          ]
      }
    ]
}

Chaque équipe peut gérer son propre réseau

Une entreprise "digital native" souhaite donner à ses équipes de développement la capacité de travailler de manière autonome. Ne disposant d'aucune équipe d'administration informatique centralisée, elle fait confiance à chacune de ses équipes pour gérer tous les aspects de ses projets.

Malgré cela, l'entreprise souhaite également pouvoir mettre en place des contrôles relativement lâches lui permettant d'adopter une configuration plus formelle à mesure qu'elle se développe et que son produit accède à la phase de disponibilité générale.

Pour mettre en œuvre ce scénario, chaque équipe de développeurs se voit attribuer son propre dossier. Cette structure garantit que les projets individuels créés dans le dossier héritent des autorisations appropriées, tout en permettant à chaque équipe de travailler de manière indépendante. Chaque équipe doit toujours respecter le principe du moindre privilège lorsqu'elle définit des stratégies d'autorisation pour ses propres ressources.

Même si ce sont initialement les mêmes membres de l'équipe qui gèrent les ressources réseau et les ressources réelles des projets, il est recommandé de créer des groupes distincts pour les tâches logiques.

Une telle approche permet de limiter facilement l'accès aux ressources requises pour le personnel temporaire ou, le cas échéant, pour de nouvelles recrues devant suivre une formation avant de pouvoir modifier des ressources réseau. Elle offre également la possibilité de redéfinir les droits d'accès de chaque employé aux différentes ressources sans avoir à modifier la stratégie d'autorisation à chaque changement de personne.

Ressource : Dossier Un compte de service peut être utilisé pour créer des projets et en assumer la propriété.
Rôles : Créateur de projet
Administrateur de dossier
Compte principal : Chefs d'équipe de développement
Compte de service
Ressource : Dossier
Rôles : Administrateur réseau

Administrateur de sécurité
Compte principal : Équipe réseau et de sécurité
Ressource : Dossier Ces rôles permettent aux développeurs de gérer tous les aspects de BigQuery et de Compute Engine.
Rôles : Administrateur d'instances
Administrateur BigQuery
Compte principal : Développeurs

Cet exemple suppose qu'une stratégie d'autorisation est liée au dossier alloué à chaque équipe.

{
  "bindings": [
    {
      "role": "roles/resourcemanager.foldersAdmin",
      "members": [
        "group:devteamleads01@example.com",
        "serviceAccount:dev01-project-creator@shared-resources-proj.iam.gserviceaccount.com"
        ]
    },
    {
      "role":"roles/resourcemanager.projectCreator",
      "members": [
        "group:devteamleads01@example.com",
        "serviceAccount:dev01-project-creator@shared-resources-proj.iam.gserviceaccount.com"
      ]
    },
    {
      "role": "roles/compute.securityAdmin",
      "members": [
        "group:net-sec-dev01@example.com"
        ]
    },
    {
      "role": "roles/compute.networkAdmin",
      "members": [
        "group:net-sec-dev01@example.com"
        ]
    },
    {
      "role": "roles/compute.instanceAdmin",
      "members": [
        "group:dev01@example.com"
        ]
    },
    {
      "role": "roles/bigquery.admin",
      "members": [
        "group:dev01@example.com"
        ]
    }
  ]
}