En este artículo se muestra cómo configurar permisos de gestión de identidades y accesos (IAM) en escenarios de redes. En función del caso, te aconsejamos sobre qué roles de IAM debes asignar a cada función relacionada con las redes que se desempeñe en la empresa. Este contenido está dirigido principalmente a los administradores de red y a los empleados que gestionan las tareas de redes de una organización. En todos los casos que se describen a continuación, se da por hecho que hay una organización configurada. Google Cloud
En este documento no se explican los roles y permisos de redes de forma exhaustiva. Para obtener una descripción detallada de los roles y permisos asociados a las APIs de computación y redes, consulta Roles de gestión de identidades y accesos predefinidos de Compute Engine.
Un solo equipo gestiona la seguridad y la red de la organización
En este caso, una organización grande tiene un equipo central que gestiona los controles de seguridad y de redes de toda la organización. Los desarrolladores no tienen permiso para cambiar los ajustes de red o de seguridad definidos por el equipo de seguridad y redes, pero sí para crear recursos, como máquinas virtuales, en subredes compartidas.
Para facilitar esta tarea, la organización utiliza una VPC compartida (nube privada virtual). Una VPC compartida permite crear una red de VPC con espacios de direcciones IP RFC 1918 que los proyectos asociados (proyectos de servicio) pueden usar. Los desarrolladores que usen los proyectos asociados pueden crear instancias de VM en los espacios de la red de VPC compartida. Los administradores de red y de seguridad de la organización pueden crear subredes, VPNs y reglas de cortafuegos que puedan usar todos los proyectos de la red de VPC.
En las tablas que se incluyen más adelante, se explican los roles de gestión de identidades y accesos que se deben asignar a los equipos de seguridad, de administración y de desarrollo, así como el nivel de recurso correspondiente.
| Recurso: | Organización | |
|---|---|---|
| Funciones: | Administrador de VPC compartida Administrador de red Administrador de seguridad |
|
| Principal: | Equipo de administración de seguridad y redes |
| Recurso: | Proyecto del host | Este rol concede permiso para usar las subredes que ha compartido la VPC compartida. |
|---|---|---|
| Rol | Usuario de la red | |
| Principal: | Desarrolladores |
| Recurso: | Proyecto de servicio | Ten en cuenta que este rol permite usar direcciones IP externas. Consulta la nota de abajo para obtener información sobre cómo evitar esta acción. |
|---|---|---|
| Rol | compute.instanceAdmin | |
| Principal: | Desarrolladores |
En este ejemplo, se necesitan tres políticas de permiso independientes: una para la organización, otra para el proyecto host y otra para los proyectos de servicio.
La primera política de permiso, que debe vincularse a nivel de organización, concede al equipo de redes y seguridad los roles que necesita para administrar proyectos de host de VPC compartidas. Esto incluye la posibilidad de asociar proyectos de servicio al proyecto del host. También permite al equipo de redes y seguridad gestionar todos los recursos de redes y seguridad de 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 permiso debe asociarse al proyecto del host y permite a los desarrolladores de la organización usar las redes compartidas en el proyecto del host de la VPC compartida.
{
"bindings": [
{
"role": "roles/compute.networkUser",
"members": [
"group:developers@example.com"
]
}
]
}
La tercera política de permiso debe asociarse a cada proyecto de servicio. De esta forma, los desarrolladores que usen el proyecto podrán gestionar las instancias del proyecto de servicio y usar las subredes compartidas del proyecto del host.
Podrías colocar todos los proyectos de servicio en una carpeta y definir esta política de permiso concreta en ese nivel de la jerarquía. De esta forma, todos los proyectos creados en esa carpeta heredarán los permisos definidos en la carpeta en la que se cree el proyecto de servicio.
También debes conceder a los desarrolladores el rol 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 los grupos para gestionar las entidades. En el ejemplo anterior, añadirías los IDs de los usuarios que gestionan los controles de seguridad y de red al grupo sec-net y los desarrolladores al grupo developers.
Si en algún momento necesitas modificar quién tiene permiso para realizar la función, puedes ajustar los grupos a los pertenece una persona, sin que sea necesario actualizar la política de permiso.
Equipos de redes y seguridad independientes
En este caso, una organización grande tiene dos equipos centrales: uno que gestiona los controles de seguridad y otro que gestiona todos los demás recursos de red de toda la organización. Los desarrolladores no tienen permiso para hacer cambios en ningún ajuste de red o de seguridad definido por el equipo de seguridad y redes, pero sí pueden crear recursos, como máquinas virtuales, en subredes compartidas.
Al igual que en el primer caso, se usará una VPC compartida y se configurarán los permisos adecuados para los tres grupos: red, seguridad y desarrolladores.
En las tablas que se incluyen más adelante, se explican los roles de gestión de identidades y accesos que se deben asignar a los equipos de seguridad y administración, así como al equipo de desarrollo, y el nivel de recurso correspondiente.
| Recurso: | Organización | |
|---|---|---|
| Funciones: | Administrador de VPC compartida Administrador de redes |
|
| Principal: | Equipo de administradores de red |
| Recurso: | Organización | |
|---|---|---|
| Funciones: | Administrador de seguridad Administrador de la organización |
|
| Principal: | Equipo de seguridad |
| Recurso: | Proyecto del host | Este rol concede permiso para usar las subredes que ha compartido la VPC compartida. |
|---|---|---|
| Rol | Usuario de la red | |
| Principal: | Desarrolladores |
| Recurso: | Proyecto de servicio | Ten en cuenta que este rol permite usar direcciones IP externas. Consulta la nota de abajo para obtener información sobre cómo evitar esta acción. |
|---|---|---|
| Rol | compute.instanceAdmin | |
| Principal: | Desarrolladores |
En este ejemplo, se necesitan tres políticas de permiso independientes: una para la organización, otra para el proyecto host y otra para los proyectos de servicio.
La primera política de permiso, que debe adjuntarse a nivel de organización, concede al equipo de redes los roles que necesita para administrar los proyectos de host de VPC compartida y para gestionar todos los recursos de red. Esto incluye la posibilidad de asociar proyectos de servicio al proyecto del host. El rol de administrador de red también permite al equipo de red ver las reglas de cortafuegos, pero no modificarlas. También permite al equipo de seguridad definir políticas de permiso y gestionar reglas de cortafuegos 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 permiso debe asociarse al proyecto host. Esta política permite que los desarrolladores de la organización usen las redes compartidas en el proyecto del host de la VPC compartida.
{
"bindings": [
{
"role": "roles/compute.networkUser",
"members": [
"group:developers@example.com"
]
}
]
}
La tercera política de permiso debe asociarse a cada proyecto de servicio. De esta forma, los desarrolladores que usen el proyecto podrán gestionar las instancias del proyecto de servicio y usar las subredes compartidas del proyecto del host.
Podrías colocar todos los proyectos de servicio en una carpeta y definir esta política de permiso concreta en ese nivel de la jerarquía. De esta forma, todos los proyectos creados en esa carpeta heredarán los permisos definidos en la carpeta en la que se cree 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 gestionar su propia red
Una empresa nativa digital quiere que sus equipos de desarrollo puedan trabajar de forma autónoma. No tienen equipos de administradores de TI centrales y confían en que sus equipos gestionen todos los aspectos de sus proyectos.
A pesar de ello, también quieren poder implementar algunos controles flexibles para adoptar una configuración más formal a medida que crezcan y su producto se lance.
Para implementar este caso, se asigna una carpeta a cada equipo de desarrolladores. Esta estructura asegura que los proyectos creados en la carpeta hereden los permisos adecuados y, al mismo tiempo, permite que cada equipo trabaje de forma independiente. Cada equipo debe seguir el principio de mínimos accesos al definir las políticas de permiso para sus propios recursos.
Aunque al principio sean los mismos miembros del equipo los que gestionen los recursos de la red y los recursos reales de los proyectos, es recomendable crear grupos independientes para las tareas lógicas.
Este enfoque facilita la limitación del acceso a los recursos que necesitan los empleados temporales o los nuevos empleados que necesitan formació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 permisos cada vez que se produce un cambio de personal.
| Recurso: | Carpeta | Una cuenta de servicio se puede usar para crear proyectos y ser su propietaria. |
|---|---|---|
| Funciones: | Creador del proyecto Administrador de carpetas |
|
| Principal: | Jefes de equipo de desarrollo Cuenta de servicio |
| Recurso: | Carpeta | |
|---|---|---|
| Funciones: | Administrador de red Administrador de seguridad |
|
| Principal: | Equipo de redes y seguridad |
| Recurso: | Carpeta | Estos roles permiten a los desarrolladores gestionar todos los aspectos de BigQuery y Compute Engine. |
|---|---|---|
| Funciones: | Administrador de instancia Administrador de BigQuery |
|
| Principal: | Desarrolladores |
Para ello, se necesita una política de permiso vinculada a la carpeta asignada a 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"
]
}
]
}