Las políticas con ámbito son políticas de acceso que se aplican a carpetas o proyectos específicos, además de una política de acceso que puedes aplicar a toda la organización. Puedes usar políticas de ámbito para delegar la administración de perímetros y niveles de acceso de Controles de Servicio de VPC en administradores a nivel de carpeta y de proyecto.
Las organizaciones solo pueden tener una política de acceso a nivel de organización, y puedes aplicar la política de acceso a nivel de organización a cualquier carpeta o proyecto de tu organización.
Puede haber casos en los que quieras delegar la gestión de una política de un subconjunto de los recursos de una organización (por ejemplo, una carpeta) en un administrador delegado. Puedes crear políticas de acceso que se limiten a carpetas o proyectos específicos, así como 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 Controles de Servicio de VPC en administradores a nivel de carpeta y de proyecto, puedes usar políticas con ámbito.
Cuando delegas la administración de una política con ámbito, los administradores delegados pueden modificar o leer esa política específica, pero no la política del Administrador de contextos de acceso de la organización. Las políticas con ámbito limitan los recursos que se pueden restringir en un perímetro de Controles de Servicio de VPC y la visibilidad de los niveles de acceso.
Gestión de políticas con ámbito
Como administrador de Administrador de contextos de acceso a nivel de organización, puedes crear, modificar y eliminar políticas con ámbito. Puedes especificar enlaces de gestión de identidades y accesos (IAM) directamente en la política del Administrador de contextos de acceso y permitir que otros usuarios de la organización deleguen la administración de la política del Administrador de contextos de acceso. Un administrador de políticas con ámbito puede configurar perímetros de servicio y niveles de acceso en las políticas. Sin embargo, un administrador de políticas con ámbito no puede crear una política ni cambiar el ámbito de la política para que se aplique a otra carpeta u otro proyecto.
A continuación, se muestra una secuencia de cómo gestionan los administradores las políticas con ámbito:
El administrador a nivel de organización crea una política de acceso con un campo de ámbito que hace referencia a una carpeta o un proyecto específicos.
El administrador a nivel de organización asigna permisos de gestión de identidades y accesos al administrador delegado directamente en el recurso de política de acceso. El administrador delegado ahora tiene permisos en la política de ámbito, pero no tiene permisos en ninguna otra política, a menos que el administrador de nivel de organización se los asigne explícitamente.
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 conceder permisos de gestión de identidades y accesos en esa política a cualquier otro usuario.
Cuando eliminas una carpeta o un proyecto, también se elimina la política que tiene la carpeta o el proyecto eliminados como ámbito. Además, si mueves un proyecto a otro nodo de la jerarquía de la organización, la política definida para el proyecto no se modificará automáticamente. Debe eliminar la política asociada al proyecto y, a continuación, volver a crearla y especificar el ámbito.
Jerarquía de políticas con ámbito
El recurso de organización es el nodo raíz de la Google Cloud jerarquía de recursos y todos los recursos que pertenecen a una organización son elementos secundarios del nodo de la organización. Las carpetas son un mecanismo de agrupación que se añade a los proyectos. Las carpetas y los proyectos son nodos secundarios del recurso de organización.
En el siguiente diagrama se muestra una organización de ejemplo que contiene carpetas para cada departamento. Estas 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 a un nivel de acceso en una política acotada:
Los perímetros de servicio de una política con ámbito solo pueden restringir los recursos que se encuentren en el ámbito de esa política. Por ejemplo, un perímetro de servicio de una política cuyo ámbito sea la carpeta de ingeniería puede proteger los proyectos example-dev, example-prod y example-test porque están en la carpeta de ingeniería.
Si la política con ámbito se aplica a la carpeta de ventas, los perímetros de servicio de esa política no pueden proteger los proyectos example-dev, example-prod y example-test. Sin embargo, el perímetro de servicio de la política con ámbito puede permitir el acceso a proyectos de otras carpetas mediante reglas de entrada y salida.
Los niveles de acceso de una política con ámbito solo se pueden ver en el ámbito de la política. Si creas un nivel de acceso en la política con el ámbito de la carpeta de ingeniería, solo podrán usarlo los perímetros de servicio y los niveles de acceso de la carpeta de ingeniería. Los perímetros de servicio y los niveles de acceso de 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 organización example.com puede tener varias políticas que contengan un nivel de acceso o un perímetro de servicio. Cuando hay varias políticas, una solicitud de recursos en la organización example.com se evalúa según las siguientes reglas:
Una política solo puede contener un ámbito, como una carpeta, pero puedes crear una política para cada nivel de una organización. Por ejemplo, si el ámbito de la política 1 es la carpeta de ingeniería, no puedes definir la carpeta de ingeniería como el ámbito de ninguna otra política. Puedes definir otra política con el ámbito definido en la carpeta secundaria de la carpeta de ingeniería, como example-prod.
Si el ámbito de una política se aplica a un proyecto o a un elemento superior del proyecto, puedes añadir el proyecto a la política. Sin embargo, un proyecto solo puede ser miembro de un perímetro de servicio en todas las políticas. Por ejemplo, una política con el ámbito definido en la organización example.com puede definir un perímetro de servicio con example-dev. Una política con el ámbito definido en la carpeta de ingeniería o en el proyecto example-dev también puede añadir el proyecto example-dev a un perímetro definido en cualquiera de ellos. Sin embargo, solo una de esas tres políticas puede contener este proyecto.