Compatibilidad con carpetas en perímetros de servicio

La función de membresía basada en carpetas de los Controles del servicio de VPC te permite definir perímetros de servicio con carpetas de Google Cloud como miembros. Esta función te ayuda a proteger una jerarquía de carpetas completa con una sola configuración de perímetro, lo que reduce la sobrecarga administrativa de la administración de perímetros a gran escala.

En este documento, se explica cómo funciona la compatibilidad con carpetas en los perímetros y se abordan los siguientes temas:

  • Conceptos básicos, comportamientos y beneficios de usar carpetas en perímetros.

  • Interacciones entre la membresía basada en carpetas, los recursos anidados y las reglas de jerarquía de recursos, como la herencia y la prioridad de evaluación.

  • Cómo buscar perímetros configurados para proyectos y carpetas

  • Prácticas recomendadas y limitaciones conocidas para usar esta función.

Acerca de la pertenencia de carpetas en los perímetros

Una carpeta deGoogle Cloud puede contener varios proyectos, otras carpetas o una combinación de ambos. Aunque puedes agregar proyectos individuales dentro de una carpeta a un perímetro de servicio, te recomendamos que agregues la carpeta superior. Cuando especificas una carpeta como un recurso protegido cuando creas un perímetro, los Controles del servicio de VPC incluyen todos los recursos dentro de esa carpeta, como proyectos y carpetas anidadas.

Cuando agregas proyectos a una carpeta que configuraste en un perímetro, los Controles del servicio de VPC agregan automáticamente esos proyectos al mismo perímetro. No es necesario que actualices la configuración del perímetro para incluir estos proyectos. Del mismo modo, cuando quitas proyectos de la carpeta, los Controles del servicio de VPC quitan automáticamente esos proyectos del perímetro.

Carpetas anidadas y herencia

Los Controles del servicio de VPC restringen todos los recursos dentro de una carpeta que hayas configurado en un perímetro, como las carpetas anidadas y sus recursos. Cuando agregas una carpeta a un perímetro, los Controles del servicio de VPC restringen automáticamente todos los proyectos de esa carpeta y sus subcarpetas.

Precedencia de la evaluación de la membresía de recursos

Un recurso de Google Cloud solo puede estar protegido por un perímetro de servicio normal en modo de aplicación forzosa y uno en modo de ejecución de prueba. Si un recurso o sus carpetas superiores están asociados con varios perímetros, la asociación de nivel más bajo en la jerarquía de recursos determina el perímetro efectivo.

Los Controles del servicio de VPC evalúan la precedencia de forma independiente para el modo de aplicación forzosa y el modo de ejecución de prueba:

  • Prioridad del modo de aplicación forzosa: El perímetro de aplicación forzosa vigente se determina por el recurso más bajo de la jerarquía (el proyecto en sí o su carpeta principal más cercana) que se asigna de forma explícita a un perímetro de aplicación forzosa.
  • Prioridad del modo de ejecución de prueba: El perímetro de ejecución de prueba efectivo se determina por el recurso más bajo de la jerarquía que se asigna de forma explícita a un perímetro de ejecución de prueba o se hereda de forma implícita de un recurso aplicado asignado de forma explícita.

Configurar un perímetro de ejecución de prueba para un proyecto o una subcarpeta no inhabilita ni anula un perímetro de aplicación forzosa configurado en una carpeta principal.

Ejemplos de prioridad

  • Ejemplo 1 (Anulación directa del proyecto en modo de aplicación forzosa): Si configuras una carpeta superior (folders/1) en un perímetro de aplicación forzosa (sp1) y configuras de forma explícita un proyecto dentro de esa carpeta (projects/1) en un perímetro de aplicación forzosa diferente (sp2), sp2 protege a projects/1. La asignación directa del proyecto tiene prioridad sobre la herencia de la carpeta. Todos los demás proyectos de folders/1 (como projects/2) siguen protegidos por sp1 a través de la herencia de carpetas.

  • Ejemplo 2 (herencia de carpetas en el modo de ejecución de prueba): Cuando configuras una carpeta (folders/1) en un perímetro de servicio en el modo de ejecución de prueba, todos los proyectos dentro de esa carpeta (projects/1 y projects/2) heredan la configuración del perímetro de ejecución de prueba (sp1), a menos que se inhabilite de forma explícita. La herencia de la ejecución de prueba se comporta de manera idéntica a la herencia del modo de aplicación forzosa, a menos que un recurso anidado se configure de forma explícita con un perímetro de ejecución de prueba diferente.

  • Ejemplo 3 (Evaluación independiente de los perímetros de aplicación forzosa y de ejecución de prueba): Los Controles del servicio de VPC evalúan las asociaciones de aplicación forzosa y de ejecución de prueba de forma independiente. Si configuras una carpeta superior (folders/1) en un perímetro de aplicación forzosa (sp1) y asignas de forma explícita un proyecto dentro de esa carpeta (projects/1) a un perímetro de ejecución de prueba (sp2), projects/1 permanece protegido por sp1 en el modo de aplicación forzosa y, al mismo tiempo, sp2 lo evalúa en el modo de ejecución de prueba. Asignar un proyecto a un perímetro de ejecución de prueba no anula ni inhabilita el perímetro de aplicación forzosa de la carpeta superior.

  • Ejemplo 4 (jerarquía de carpetas de varios niveles y precedencia de subcarpetas): En una jerarquía de carpetas de varios niveles, los Controles del servicio de VPC evalúan la precedencia en cada nivel de la jerarquía. Si una carpeta principal (folders/2) se configura en un perímetro de aplicación forzosa (sp1), todos los proyectos contenidos (projects/1 y projects/2) heredan la aplicación forzosa de sp1. Cuando los perímetros de ejecución de prueba se asignan en diferentes niveles, como asignar el ancestro folders/2 al perímetro de ejecución de prueba sp2 y el proyecto projects/2 (en la subcarpeta folders/1) al perímetro de ejecución de prueba sp1, cada proyecto hereda la configuración de ejecución de prueba de su ancestro más cercano. Como resultado, projects/1 se evalúa en la ejecución de prueba sp2, pero projects/2 se evalúa en la ejecución de prueba sp1.

Busca los perímetros configurados vigentes

Debido a que los recursos pueden heredar la protección del perímetro de las carpetas principales, puedes usar el método LookupConfiguredServicePerimeter para identificar qué perímetros de servicio protegen un proyecto o una carpeta.

La API devuelve lo siguiente:

  • servicePerimeter: Es el nombre completamente calificado del perímetro de aplicación forzosa vigente.
  • servicePerimeterDryRun: Es el nombre completamente calificado del perímetro de ejecución de prueba efectivo.
  • restrictedResource: Es el recurso específico (proyecto o carpeta) al que se adjunta directamente el perímetro de aplicación forzosa.
  • restrictedResourceDryRun: Es el recurso específico al que se adjunta directamente el perímetro de ejecución de prueba.

Para obtener más información, consulta Busca perímetros configurados.

Exclusión de proyectos de los perímetros

Para excluir un proyecto de un perímetro a nivel de la carpeta, asígnalo de forma explícita a un perímetro independiente que no restrinja ningún servicio y permita todo el tráfico de entrada y salida. Debido a que las configuraciones explícitas del proyecto tienen prioridad sobre los perímetros a nivel de carpeta, el proyecto se excluye del perímetro de la carpeta.

Para obtener información sobre cómo actualizar perímetros, consulta Actualiza un perímetro de servicio.

Políticas con alcance

Los perímetros de servicio dentro de una política con alcance restringen solo los recursos que existen dentro del alcance de esa política. Para que una carpeta se incluya como miembro en un perímetro con alcance, la política de acceso debe tener alcance en esa carpeta o en un ancestro de esa carpeta (como una carpeta superior o la organización).

Prácticas recomendadas

Revisa las siguientes prácticas recomendadas cuando administres perímetros basados en carpetas.

Migración segura de proyectos a perímetros de carpetas

Cuando realices la transición de membresías de proyectos explícitas a membresías basadas en carpetas, sigue estos pasos para evitar interrupciones involuntarias en la aplicación de políticas del perímetro:

  1. Agrega la carpeta superior de destino al perímetro de servicio.
  2. Mueve los proyectos a esa carpeta superior en la jerarquía de recursos.
  3. Conserva las entradas de proyecto explícitas en la configuración del perímetro hasta que se complete la propagación de la jerarquía de recursos en todos los sistemas. Por lo general, la propagación tarda unos minutos, pero, en algunos casos, puede tardar más.
  4. Quita las configuraciones explícitas del proyecto del perímetro. Los proyectos permanecen protegidos a través de la herencia de carpetas.

Movimientos de jerarquía

Mover carpetas o proyectos cambia su protección perimetral efectiva. Para evitar denegaciones de acceso inesperadas, coordina todos los movimientos de jerarquía con tu administrador de Resource Manager.

Si mueves proyectos que configuraste en un perímetro a otra carpeta y agregas esa carpeta al mismo perímetro, conserva las configuraciones de membresía de proyectos explícitas existentes en el perímetro hasta que se complete la propagación de la jerarquía de recursos. La propagación suele tardar unos minutos, pero puede tardar más. Este período de espera ayuda a evitar problemas inesperados de aplicación de políticas del perímetro cuando quitas las configuraciones explícitas del proyecto del perímetro.

Limitaciones

  • La membresía basada en carpetas no se admite en los puentes perimetrales. Los puentes perimetrales solo aceptan recursos de proyecto.

  • Los Controles del servicio de VPC no admiten recursos de la API a nivel de carpeta.

  • Debido a un problema conocido, configurar un proyecto de red de VPC como un recurso protegido en un perímetro de ejecución de prueba anula la aplicación de políticas basada en carpetas. Si un proyecto de red se agrega de forma explícita a un perímetro de ejecución de prueba, pierde la protección del perímetro de aplicación forzosa heredada de sus carpetas principales.

  • La membresía de carpetas no se admite para las APIs que no sean deGoogle Cloud y los perímetros configurados con allowed_service_patterns. Para permitir el acceso a estos patrones de servicio, los proyectos o las redes de VPC de origen se deben agregar de forma explícita al perímetro, en lugar de heredarse a través de una carpeta.

¿Qué sigue?