Funciones de IAM para funciones de trabajo relacionadas con las herramientas de redes

En este tema, se muestra cómo configurar los permisos de administración de identidades y accesos (IAM) para situaciones de herramientas de redes. Se proporciona orientación sobre las funciones de IAM que se deben otorgar a las funciones prácticas relacionadas con las herramientas de redes de tu empresa para esas situaciones. Este contenido está dirigido, sobre todo, a los administradores de red y los empleados que administran las tareas de herramientas de redes de una organización. En todas las situaciones que se describen a continuación, se supone que se configuró una organización de Google Cloud.

Este documento no explica en detalle los permisos y las funciones de las herramientas de redes. Para obtener una descripción detallada de las funciones y los permisos asociados con las API de procesamiento y de herramientas de redes, lee Funciones predefinidas de IAM de Compute Engine.

Un solo equipo administra la seguridad y la red de la organización

En esta situación, una organización grande tiene un equipo central que administra la seguridad y los controles de red para toda la organización. Los desarrolladores no tienen permisos para realizar cambios en ninguna configuración de red o seguridad definida por el equipo de seguridad y redes, pero se les otorga permiso para crear recursos como máquinas virtuales en subredes compartidas.

Para facilitar esto, la organización hace uso de una VPC compartida (nube privada virtual). Una VPC compartida permite la creación de una red de VPC de espacios IP RFC 1918 que los proyectos asociados (proyectos de servicio) pueden usar. Los desarrolladores que usan los proyectos asociados pueden crear instancias de VM en los espacios de red de VPC compartida. Los administradores de redes y seguridad de la organización pueden crear subredes, VPN y reglas de firewall que todos los proyectos de la red de VPC pueden usar.

En las siguientes tablas, se explican las funciones de IAM que se deben otorgar al equipo de seguridad y administración y al de desarrollo, además del nivel de recursos en el que se otorgarán las funciones.

Recurso: Organización
Funciones: Administrador de VPC compartida
Administrador de red
Administrador de seguridad
Miembro: Equipo de administración de seguridad y red.
Recurso: Proyecto host Esta función otorga permiso para usar subredes que la VPC compartida ha compartido.
Función: Usuario de red
Miembro: Desarrolladores
Recurso: Proyecto de servicio Ten en cuenta que esta función habilita el permiso para utilizar direcciones IP externas. Consulta la nota a continuación como una guía sobre cómo prevenir esta acción.
Función: compute.instanceAdmin
Miembro: Desarrolladores

En esta situación, necesitarás tres políticas de IAM diferentes: una para la organización, una para el proyecto host y otra para los proyectos de servicio.

La primera política de IAM, que se debe vincular a nivel de organización, otorga al equipo de redes y seguridad las funciones que necesita para administrar proyectos host de la VPC compartida. Esto incluye la capacidad de asociar proyectos de servicio con el proyecto host. También otorga al equipo de redes y seguridad la capacidad de administrar todos los recursos de red y de seguridad en todos los proyectos de la organización.

{
  "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 segunda política de IAM debe estar asociada con el proyecto host y les otorga a los desarrolladores de la organización la capacidad de usar las redes compartidas en el proyecto host de VPC compartida.

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

La tercera política de IAM debe estar asociada con cada proyecto de servicio. Esto permite que los desarrolladores que usan el proyecto administren las instancias en el proyecto de servicio y puedan usar las subredes compartidas en el proyecto host.

Puedes colocar todos los proyectos de servicio en una carpeta y configurar esta política en particular en ese nivel de la jerarquía. Esto permitiría que todos los proyectos creados en esa carpeta hereden los permisos configurados en la carpeta dentro de la cual se crea el proyecto de servicio.

También debes otorgarles a los desarrolladores la función de usuario de red en el proyecto de servicio.

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

La práctica recomendada es usar grupos para administrar miembros. En el ejemplo anterior, agregarías el ID de usuario de los usuarios que administran los controles de seguridad y red al grupo sec-net, y los desarrolladores al grupo developers. Cuando necesitas modificar quién es capaz de llevar a cabo la función, solo debes ajustar la membresía del grupo, sin necesidad de actualizar la política.

Equipos separados de red y seguridad

En esta situación, una organización grande tiene dos equipos centrales, uno que administra los controles de seguridad y otro que administra los recursos de red para toda la organización. Los desarrolladores no tienen permisos para realizar cambios en ninguna configuración de red o seguridad definida por el equipo de seguridad y redes, pero se les otorga permiso para crear recursos como máquinas virtuales en subredes compartidas.

Al igual que en la primera situación, se usará una VPC compartida y los permisos adecuados configurados para la red, la seguridad y los desarrolladores de los tres grupos.

En las siguientes tablas, se explican las funciones de IAM que se deben otorgar al equipo de seguridad y administración y al de desarrollo, además del nivel de recursos en el que se otorgarán las funciones.

Recurso: Organización
Funciones: Administrador de VPC compartida
Administrador de red
Miembro: Equipo administrador de red
Recurso: Organización
Funciones: Administrador de seguridad
Administrador de la organización
Miembro: Equipo de seguridad
Recurso: Proyecto host Esta función otorga permiso para usar subredes que la VPC compartida ha compartido.
Función: Usuario de red
Miembro: Desarrolladores
Recurso: Proyecto de servicio Ten en cuenta que esta función habilita el permiso para utilizar direcciones IP externas. Consulta la nota a continuación como una guía sobre cómo prevenir esta acción.
Función: compute.instanceAdmin
Miembro: Desarrolladores

En esta situación, necesitarás tres políticas de IAM diferentes: una para la organización, una para el proyecto host y otra para los proyectos de servicio.

La primera política de IAM, que se debe vincular a nivel de organización, otorga al equipo de redes las funciones que necesita para administrar los proyectos host de la VPC compartida y todos los recursos de red. Esto incluye la capacidad de asociar proyectos de servicio con el proyecto host. La función de administrador de redes también otorga al equipo de redes la capacidad de ver las reglas de firewall, pero no de modificarlas. También otorga al equipo de seguridad la capacidad de establecer políticas de IAM y administrar reglas de firewall y certificados SSL en todos los proyectos de la organización.

{
  "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 segunda política de IAM debe estar asociada con el proyecto host. Esta política permite que los desarrolladores de la organización usen las redes compartidas en el proyecto host de la VPC compartida.

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

La tercera política de IAM debe estar asociada con cada proyecto de servicio. Esto permite que los desarrolladores que usan el proyecto administren las instancias en el proyecto de servicio y puedan usar las subredes compartidas en el proyecto host.

Puedes colocar todos los proyectos de servicio en una carpeta y configurar esta política en particular en ese nivel de la jerarquía. Esto permitiría que todos los proyectos creados en esa carpeta hereden los permisos configurados en la carpeta dentro de la cual se crea el proyecto de servicio.

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

Cada equipo puede administrar su propia red

Un nativo digital quiere dar a sus equipos de desarrollo la capacidad de trabajar de manera autónoma. No tienen equipos centrales de administración de TI y confían en sus equipos para administrar todos los aspectos de sus proyectos.

A pesar de esto, también quieren poder implementar algunos controles sueltos que les permitan adoptar una configuración más formal a medida que crecen y su producto se lanza al mercado.

Para implementar esta situación, se le asigna a cada equipo de desarrolladores su propia carpeta. Mediante esta estructura, se garantiza que los proyectos individuales creados en la carpeta hereden los permisos adecuados y, a la vez, se permite que cada equipo trabaje de forma independiente. Cada equipo debe respetar el principio de privilegio mínimo cuando establece políticas de IAM en sus propios recursos.

A pesar de que, en un principio, serán los mismos miembros del equipo quienes administrarán los recursos de red y los recursos de los proyectos, se recomienda crear distintos grupos para las tareas lógicas.

Este enfoque facilita la limitación del acceso a aquellos recursos que necesita el personal temporal o quizás el personal nuevo, que necesita capacitación antes de poder modificar los recursos de red. También permite cambiar quién tiene acceso a qué recursos sin tener que modificar la política de IAM cada vez que se produce un cambio de personal.

Recurso: Carpeta Se puede utilizar una cuenta de servicio para crear y poseer proyectos.
Funciones: Creador del proyecto
Administrador de carpetas
Miembro: Líderes de equipo de desarrollo
Cuenta de servicio
Recurso: Carpeta
Funciones: Administrador de la red

Administrador de seguridad

Miembro: Equipo de seguridad y red
Recurso: Carpeta Estas funciones permiten a los desarrolladores administrar todos los aspectos de BigQuery y de Compute Engine.
Funciones: Administrador de instancias
Administrador de BigQuery
Miembro: Desarrolladores

Esto requiere una política de IAM vinculada a la carpeta asignada de cada equipo.

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