Las políticas con permiso son políticas de acceso que se aplican a carpetas o proyectos específicos junto con una política de acceso que puedes aplicar a toda la organización. Puedes usar políticas con alcance para delegar la administración de los perímetros de los Controles del servicio de VPC y los niveles de acceso a los administradores a nivel de carpeta y de proyecto.
Las organizaciones solo pueden tener una política de acceso a nivel de la organización, y puedes aplicarla a cualquier carpeta o proyecto de tu organización.
Puede haber instancias en las que desees delegar la administración de una política para un subconjunto de recursos de una organización, como una carpeta, a un administrador delegado. Puedes crear políticas de acceso con alcance para carpetas o proyectos específicos, junto con una política de acceso que se pueda aplicar a toda la organización. Para delegar la administración de los perímetros de los Controles del servicio de VPC y los niveles de acceso a los administradores a nivel de carpeta y de proyecto, puedes usar políticas con alcance.
Cuando delegas la administración de una política con alcance, los administradores delegados pueden modificar o leer esa política específica y no la política de Access Context Manager de la organización. Las políticas con permiso limitan los recursos que se pueden restringir en un perímetro de Controles del servicio de VPC y la visibilidad de cualquier nivel de acceso.
Administración de políticas con alcance
Como administrador de Access Context Manager a nivel de la organización, puedes crear, modificar y borrar políticas con permiso. Puedes especificar vinculaciones de Identity and Access Management (IAM) directamente en la política de Access Context Manager y permitir la delegación adicional de la administración de políticas de Access Context Manager a otros usuarios de la organización. Un administrador de políticas con permiso puede configurar perímetros de servicio y niveles de acceso en las políticas. Sin embargo, un administrador de políticas con permiso no puede crear una política nueva ni cambiar el alcance de la política para que se aplique a otra carpeta o proyecto.
Esta es una secuencia de cómo los administradores gestionan las políticas con alcance:
El administrador a nivel de la organización crea una nueva política de acceso con un campo de permiso que hace referencia a una carpeta o proyecto específico.
El administrador a nivel de la organización asigna permisos de IAM al administrador delegado directamente en el recurso de la política de acceso. El administrador delegado ahora tiene permisos para la política con permiso, pero no los tiene en ninguna otra política, a menos que el administrador a nivel de la organización los asigne de forma explícita al administrador delegado.
El administrador delegado ahora puede editar la política para configurar niveles de acceso y perímetros de servicio. El administrador delegado también puede otorgar permisos de IAM sobre esa política a cualquier otro usuario.
Cuando borras una carpeta o un proyecto, también se borra la política que tiene la carpeta o el proyecto borrados como su alcance. Además, si mueves un proyecto a otro nodo en la jerarquía de la organización, la política cuyo alcance para el proyecto no se modifica de forma automática. Debes borrar la política asociada con el proyecto y, luego, volver a crearla y especificar el alcance.
Jerarquía de políticas con permiso
El recurso de organización es el nodo raíz de la jerarquía de recursos de Google Cloud, y todos los recursos que pertenecen a una organización existen como elementos secundarios de este. Las carpetas son un mecanismo de agrupación por encima de los proyectos. Las carpetas y los proyectos existen como nodos secundarios del recurso de la organización.
En el siguiente diagrama, se muestra una organización de ejemplo que contiene carpetas para cada departamento y las carpetas contienen proyectos de desarrollo, prueba y producción.
En la organización de ejemplo, se aplican las siguientes restricciones a un perímetro de servicio o un nivel de acceso en una política con permiso:
Los perímetros de servicio en una política con permiso solo pueden restringir los recursos que existen dentro del alcance de esa política. Por ejemplo, un perímetro de servicio en una política con alcance a la carpeta de ingeniería puede proteger los proyectos example-dev, example-prod y example-test porque los proyectos están en la carpeta de ingeniería.
Si la política con alcance se aplica a la carpeta de ventas, los perímetros de servicio de esa política no pueden proteger proyectos de example-dev, example-prod ni example-test. Sin embargo, el perímetro de servicio en la política con permiso puede permitir el acceso a proyectos en otras carpetas mediante reglas de entrada y salida.
Los niveles de acceso en una política con permiso solo son visibles dentro del alcance de la política. Si creas un nivel de acceso en la política que se limita a la carpeta de ingeniería, solo los perímetros de servicio y los niveles de acceso en la carpeta de ingeniería pueden usarlo. Los perímetros de servicio y los niveles de acceso en otras carpetas no pueden usar el nivel de acceso definido en la carpeta de ingeniería.
Una ubicación, como una carpeta, en la jerarquía de recursos de la organización de example.com puede tener varias políticas que contienen un nivel de acceso o un perímetro de servicio. Cuando existen varias políticas, una solicitud de recursos en la organización example.com se evalúa en función de las siguientes reglas:
Una política solo puede contener un alcance, como una carpeta, pero puedes crear una política para cada nivel de una organización. Por ejemplo, si el alcance de la política 1 es la carpeta de ingeniería, no puedes establecerla como el alcance de ninguna otra política. Puedes establecer otra política con el alcance configurado como el elemento secundario de la carpeta de ingeniería, como example-prod.
Si el alcance de una política se aplica a un proyecto o a uno superior del proyecto, puedes agregar el proyecto a la política. Sin embargo, un proyecto puede ser miembro de un solo perímetro de servicio en todas las políticas. Por ejemplo, una política con alcance configurado en la organización example.com puede definir un perímetro de servicio con example-dev. Una política con alcance configurado en la carpeta de ingeniería o el alcance configurado en el proyecto example-dev también puede agregar el proyecto example-dev a un perímetro definido dentro de cualquiera de ellos. Sin embargo, solo una de esas tres políticas puede contener este proyecto.