Las políticas de alcance 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 y los niveles de acceso de los Controles del servicio de VPC a los administradores a nivel de la carpeta y del proyecto.
Las organizaciones solo pueden tener una política de acceso a nivel de la organización, y puedes aplicar la política de acceso a nivel de la organización a cualquier carpeta o proyecto de tu organización.
Es posible que haya casos en los que desees delegar la administración de una política para un subconjunto de los 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 y los niveles de acceso de los Controles del servicio de VPC a los administradores a nivel de la carpeta y del proyecto, puedes usar políticas con alcance.
Cuando delegas la administración de una política de 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 centradas limitan los recursos que se pueden restringir en un perímetro de Controles del servicio de VPC y la visibilidad de los niveles 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 centradas. Puedes especificar vinculaciones de administración de identidades y accesos (IAM) directamente en la política de Access Context Manager y permitir una mayor delegación de la administración de políticas de Access Context Manager a otros usuarios de la organización. Un administrador de políticas centradas puede configurar perímetros de servicio y niveles de acceso en las políticas. Sin embargo, un administrador de políticas de alcance no puede crear una política nueva ni cambiar su alcance para aplicarla a otra carpeta o proyecto.
Esta es una secuencia de cómo los administradores administran las políticas centradas:
El administrador a nivel de la organización crea una política de acceso nueva con un campo de alcance que hace referencia a una carpeta o un proyecto específicos.
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 en la política con alcance, pero no tiene permisos en ninguna otra política, a menos que el administrador a nivel de la organización se los asigne de forma explícita.
El administrador delegado ahora puede editar la política para configurar los niveles de acceso y los perímetros de servicio. El administrador delegado también puede otorgar permisos de IAM en 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 trasladas un proyecto a otro nodo en la jerarquía de la organización, la política centrada en el proyecto no se modifica automáticamente. Debes borrar la política asociada con el proyecto y, luego, volver a crearla y especificar el alcance.
Jerarquía de políticas con alcance
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 del nodo de organización. Las carpetas son un mecanismo de agrupación por sobre los proyectos. Las carpetas y los proyectos existen como nodos secundarios del recurso de 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 dev, prueba y producción.
En la organización de ejemplo, se aplican las siguientes restricciones a un perímetro de servicio o a un nivel de acceso en una política centrada:
Los perímetros de servicio en una política con alcance 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 centrada en la carpeta de ingeniería puede proteger los proyectos example-dev, example-prod y example-test, ya que los proyectos se encuentran en la carpeta de ingeniería.
Si la política centrada se aplica a la carpeta de ventas, los perímetros de servicio de esa política no pueden proteger ninguno de los proyectos example-dev, example-prod y example-test. Sin embargo, el perímetro de servicio en la política de alcance puede permitir el acceso a proyectos en otras carpetas mediante reglas de entrada y salida.
Los niveles de acceso en una política con alcance solo son visibles dentro del alcance de la política. Si creas un nivel de acceso en la política con el alcance de la carpeta de Ingeniería, solo los perímetros de servicio y los niveles de acceso de la carpeta de Ingeniería podrán 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 contengan 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 según las siguientes reglas:
Una política puede contener solo un permiso, 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 establecer la carpeta de Ingeniería como el alcance de ninguna otra política. Puedes establecer otra política con el permiso configurado en 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 un elemento 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 el alcance establecido en la organización example.com puede definir un perímetro de servicio con example-dev. Una política con el alcance establecido en la carpeta de Ingeniería o 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.