IAM roles for Networking-related Job Functions

This topic shows how to configure IAM permissions for networking scenarios. It provides guidance on what IAM roles to grant to the networking-related functional roles in your company for the scenarios. This content is mainly targeted at network administrators and employees who manage networking tasks for an organization. The scenarios described below all assume that a Cloud Organization is configured.

This document does not explain in detail the networking roles and permissions. For a detailed description of roles and permissions associated with compute and networking API's, read Compute Engine IAM roles

Single team manages security & network for organization

In this scenario, a large organization has a central team that manages security and networking controls for the entire organization. Developers do not have permissions to make changes to any network or security settings defined by the security and networking team but they are granted permission to create resources such as virtual machines in shared subnets.

To facilitate this the organization makes use of a shared VPC (Virtual Private Cloud). A shared VPC allows creation of a VPC network of RFC1918 IP spaces that associated projects (service projects) can then use. Developers using the associated projects can create VM instances in the shared VPC network spaces. The organization's network and security admins can create subnets, VPNs, and firewall rules usable by all the projects in the VPC network.

The tables below explain the IAM roles that need to be granted to the security and admin team, the development team, and the resource level at which the roles are granted.

Resource: Organization
Roles: Shared VPC Admin
Network Admin
Security Admin
Member: Security & network admin team
Resource: Host Project This role grants permission to use subnets that the shared VPC has shared.
Role: Network user
Member: Developers
Resource: Service project Note this role allows the permission to use External IP addresses. See the note below for guidance on how to prevent this action.
Role: compute.instanceAdmin
Member: Developers

For this scenario you will need three separate IAM policies as they are attached at different levels of the hierarchy and to different projects.

The first IAM policy that needs to be attached at the organization level is to grant the network and security team permissions to administer shared VPC host projects. This includes the ability to associate service projects with the host project. It also grants the network and security team the ability to manage all network and security resources in all projects in the organization.

{
  "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"
      ]
    }
  ]
}

The second IAM policy needs to be associated with the host project and enables the developers in the organization the ability to use the shared networks in the shared VPC host project.

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

The third IAM policy needs to be associated with each service project. This enables the developers using the project to manage instances in the service project and the ability to use the shared subnets in the host project.

You could place all service projects in a folder and set this particular policy at that level of the hierarchy. This would allow all projects created in that folder to inherit the permissions set at the folder within which the service project is created

You also need to grant the developers the Network User role in the service project.

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

The best practice is to use groups to manage members. In the example above, you would add the user id's of the users who manage the security & network controls to the sec-net group, and developers into the developers group. When you need to modify who is able to carry out the function, you simply need to adjust the group membership, negating the need to update the policy.

Separate network & security teams

In this scenario, a large organization has two central teams: one that manages security controls, and another that manages all other networking resources for the entire organization. Developers do not have permissions to make changes to any network or security settings defined by the security and networking team, but they are granted permission to create resources such as virtual machines in shared subnets.

As with the first scenario, a shared VPC will be used and the appropriate permissions configured for the three groups network, security, and developers.

The tables below explain the IAM roles that need to be granted to the security and admin team, the development team, and the resource level at which the roles are granted.

Resource: Organization
Roles: Shared VPC Admin
Network Admin
Member: Network Admin team
Resource: Organization
Roles: Security Admin
Organization Admin
Member: Security team
Resource: Host Project This role grants permission to use subnets that the shared VPC has shared.
Role: Network user
Member: Developers
Resource: Service project Note this role allows the permission to use External IP addresses. See the note below for guidance on how to prevent this action.
Role: compute.instanceAdmin
Member: Developers

For this scenario you will need three separate IAM policies as they are attached at different levels of the hierarchy and to different projects.

The first IAM policy that needs to be attached at the organization level is to grant the network team permissions to administer shared VPC host projects and to manage all network resources. This includes the ability to associate service projects with the host project. The network admin role also grants the network team the ability to view but not modify firewall rules. It also grants the security team the ability to set IAM policies and manage firewall rules and SSL certificates in all projects in the organization.

{
  "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"
        ]
    }
  ]
}

The second IAM policy needs to be associated with the host project and enables the developers in the organization the ability to use the shared networks in the shared VPC host project.

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

The third IAM policy needs to be associated with each service project. This enables the developers using the project to manage instances in the service project and the ability to use the shared subnets in the host project.

You could place all service projects in a folder and set this particular policy at that level of the hierarchy. This would allow all projects created in that folder to inherit the permissions set at the folder within which the service project is created.

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

Each team can manage its own network

A digital native wants to give their development teams the ability to work in an autonomous manner. They have no central IT admin teams and trust their teams to manage all aspects of their projects.

Despite this, they equally want to be able to put in place some loose controls to allow them to adopt a more formal set-up as they grow and their product goes GA.

To meet this scenario each team of developers are assigned their own folder so that individual projects created under the folder inherit the appropriate permissions. Each team can manage the network associated within each of their projects autonomously. Implementing processes and IAM policies so that even within these autonomous teams least privilege is applied from the outset will ensure that as the teams start working more closely together there will not be any friction.

Even though it will initially be the same team members who will be managing the network resources and the actual resources in the projects creating separate groups for the logical duties is best practice.

This approach facilitates limiting access to those resources that temporary staff need or maybe new staff that need training up before they can modify network resources. It also allows the ability to change who has access to what resources without having to modify the IAM policy every time a personnel changes occurs.

Resource: Folder A service account can be used to create and own projects.
Roles: Project creator
Folder Admin
Member: Dev Teamleads
Service account
Resource: Folder
Roles: Network Admin

Security Admin

Member: Network & security team
Resource: Folder These roles allow the developers to manage all aspects of BigQuery and Compute engine.
Roles: Instance Admin
BigQuery Admin
Member: Developers

This requires an IAM policy bound at each team's allocated folder.

{
  "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"
        ]
    }
  ]
}

Send feedback about...

Cloud Identity and Access Management Documentation