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 Google Cloud como miembros. Esta función te ayuda a proteger toda una jerarquía de carpetas 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, comportamientos y beneficios principales del uso de 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 precedencia de evaluación.

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

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

Acerca de la membresía de carpetas en perímetros

Una Google Cloud carpeta puede contener varios proyectos, otras carpetas o una combinación de ambos. Si bien 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 configuraste 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 membresía de recursos

Un recurso de Google Cloud solo puede estar protegido por un perímetro de servicio regular en modo de aplicación forzosa y uno en modo de ejecución de prueba. Si un recurso o sus carpetas principales 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 efectivo se determina según 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 según 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 que 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 superior.

Ejemplos de precedencia

  • Ejemplo 1 (anulación directa del proyecto en modo de aplicación forzosa): Si configuras una carpeta principal (folders/1) en un perímetro de aplicación forzosa (sp1) y configuras explícitamente un proyecto dentro de esa carpeta (projects/1) en un perímetro de aplicación forzosa diferente (sp2), projects/1 estará protegido por sp2. La asignación directa del proyecto tiene prioridad sobre la herencia de carpetas. Todos los demás proyectos en folders/1 (como projects/2) permanecen 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 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 principal (folders/1) en un perímetro de aplicación forzosa (sp1) y asignas explícitamente 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 principal.

  • 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) está configurada en un perímetro de aplicación forzosa (sp1), todos los proyectos incluidos (projects/1 y projects/2) heredan la aplicación de sp1. Cuando se asignan perímetros de prueba de validación en diferentes niveles (por ejemplo, se asigna el elemento superior folders/2 al perímetro de prueba de validación sp2 y el proyecto projects/2 [en la subcarpeta folders/1] al perímetro de prueba de validación sp1), cada proyecto hereda la configuración de prueba de validación de su elemento superior más cercano. Como resultado, projects/1 se evalúa en la ejecución de prueba de sp2, pero projects/2 se evalúa en la ejecución de prueba de sp1.

Cómo buscar perímetros configurados efectivos

Dado que los recursos pueden heredar la protección del perímetro de las carpetas superiores, 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 aplicado efectivo.
  • servicePerimeterDryRun: Es el nombre completamente calificado del perímetro de simulación 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 la prueba de ejecución.

Para obtener más información, consulta Cómo buscar 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ígnale explícitamente ese proyecto a un perímetro independiente que no restrinja ningún servicio y permita todo el tráfico de entrada y salida. Dado que las configuraciones explícitas del proyecto tienen prioridad sobre los perímetros a nivel de la 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 solo restringen 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 elemento superior de esa carpeta (como una carpeta principal 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 explícitas del proyecto a membresías basadas en carpetas, sigue estos pasos para evitar interrupciones involuntarias en la aplicación del perímetro:

  1. Agrega la carpeta principal de destino al perímetro de servicio.
  2. Mueve los proyectos a esa carpeta principal en la jerarquía de recursos.
  3. Espera al menos 48 horas: Conserva las entradas explícitas del proyecto en la configuración del perímetro durante al menos 48 horas. Este período de espera permite que la propagación de la jerarquía de recursos se complete en todos los sistemas.
  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 la jerarquía con el administrador de Resource Manager.

Si mueves a otra carpeta los proyectos que configuraste en un perímetro y agregas esa carpeta al mismo perímetro, debes conservar las configuraciones de membresía explícita existentes del proyecto en el perímetro durante al menos 48 horas. Este período de espera permite la propagación de la jerarquía de recursos y evita problemas inesperados de aplicación del perímetro cuando quitas las configuraciones explícitas del proyecto del perímetro.

Limitaciones

  • La membresía basada en carpetas no es compatible con los puentes perimetrales. Los puentes perimetrales solo aceptan recursos de proyectos.

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

  • Debido a un problema conocido, la configuración de un proyecto de red de VPC como un recurso protegido en un perímetro de ejecución de prueba anula la aplicación 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 que heredó de sus carpetas principales.

  • La membresía de carpetas no se admite para las APIs que no son 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?