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

Este tema muestra cómo configurar los permisos de IAM para situaciones de red. Proporciona una guía sobre qué funciones de IAM otorgar a las competencias funcionales relacionadas con la red en tu empresa para las situaciones. Este contenido está dirigido principalmente a administradores de red y empleados que administran las tareas de red para una organización. Las situaciones descritas a continuación suponen que se ha configurado una organización en la nube.

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

Un solo equipo administra la seguridad y la red para 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 red y seguridad de la organización pueden crear subredes, redes privadas virtuales (VPN) y reglas de firewall que todos los proyectos de la red de VPC pueden utilizar.

Las tablas a continuación explican las funciones de IAM que deben otorgarse al equipo de administración y seguridad, al equipo de desarrollo y al nivel de recursos en el que se otorgan las funciones.

Recurso: Organización
Funciones: Administrador de VPC compartida
Administrador de la 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

Para esta situación, necesitarás tres políticas de IAM separadas, ya que se adjuntan en diferentes niveles de la jerarquía y en diferentes proyectos.

La primera política de IAM que debe adjuntarse en el nivel de la organización es otorgar a la red y al equipo de seguridad permisos para administrar proyectos host de VPC compartida. Esto incluye la capacidad de asociar proyectos de servicio con el proyecto host. También otorga al equipo de red y seguridad la capacidad de administrar todos los recursos de red y 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 le 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 a los desarrolladores que usan el proyecto administrar las instancias en el proyecto de servicio y la capacidad de 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 otorgar 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 recomendación es usar grupos para administrar miembros. En el ejemplo anterior, agregarías la identificación de usuario de los usuarios que administran los controles de seguridad y de red al grupo sec-net, y los desarrolladores, al grupo de developers. Cuando necesitas modificar quién es capaz de llevar a cabo la función, simplemente 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 utilizará una VPC compartida y se configurarán los permisos adecuados para los tres grupos de red, seguridad y desarrolladores.

Las tablas a continuación explican las funciones de IAM que deben otorgarse al equipo de administración y seguridad, al equipo de desarrollo y al nivel de recursos en el que se otorgan las funciones.

Recurso: Organización
Funciones: Administrador de VPC compartida
Administrador de la 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

Para esta situación, necesitarás tres políticas de IAM separadas, ya que se adjuntan en diferentes niveles de la jerarquía y en diferentes proyectos.

La primera política de IAM que debe adjuntarse en el nivel de la organización es otorgar a la red y al equipo de seguridad permisos para administrar proyectos host de VPC compartida y para administrar todos los recursos de red. Esto incluye la capacidad de asociar proyectos de servicio con el proyecto host. La función de administrador de red también otorga al equipo de red la capacidad de ver, pero no modificar las reglas del firewall. 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 y le 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 a los desarrolladores que usan el proyecto administrar las instancias en el proyecto de servicio y la capacidad de 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 convierte en GA.

Para cumplir con esta situación, a cada equipo de desarrolladores se le asigna su propia carpeta para que los proyectos individuales creados en la carpeta hereden los permisos apropiados. Cada equipo puede gestionar la red asociada a cada uno de sus proyectos de forma autónoma. La implementación de procesos y políticas de IAM para que incluso dentro de estos equipos autónomos se aplique un privilegio mínimo desde el principio garantizará que no haya fricciones a medida que los equipos comiencen a trabajar más estrechamente juntos.

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

Este enfoque facilita la limitación del acceso a aquellos recursos que el personal temporal necesita o quizás el personal nuevo que necesita capacitación antes de poder modificar los recursos de la 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 carpeta
Miembro: Dev Teamleads
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"
        ]
    }
  ]
}
¿Te sirvió esta página? Envíanos tu opinión:

Enviar comentarios sobre…

Documentación de Cloud Identity and Access Management