Seguridad de Private Service Connect

En esta página se ofrece una descripción general de la seguridad de Private Service Connect.

Private Service Connect ofrece varios controles para gestionar el acceso a los recursos de Private Service Connect. Puedes controlar quién puede implementar recursos de Private Service Connect, si se pueden establecer conexiones entre consumidores y productores, y qué tráfico de red puede acceder a esas conexiones.

Estos controles se implementan mediante los siguientes elementos:

En la figura 1 se describe cómo interactúan estos controles en los lados del consumidor y del productor de una conexión de Private Service Connect.

Imagen 1. Los permisos de gestión de identidades y accesos, las políticas de la organización, las listas de aceptación y rechazo, y las reglas de cortafuegos de VPC se combinan para proteger los lados del consumidor y del productor de una conexión de Private Service Connect (haz clic para ampliar).

Gestión de identidades y accesos

Recursos: todos

Cada recurso de Private Service Connect se rige por uno o varios permisos de gestión de identidades y accesos. Estos permisos permiten a los administradores aplicar qué principales de gestión de identidades y accesos pueden implementar recursos de Private Service Connect.

IAM no rige qué principales de IAM pueden conectarse a una conexión de Private Service Connect o usarla. Para controlar qué endpoints o back-ends pueden establecer una conexión con un servicio, usa políticas de organización o listas de aceptación de consumidores. Para controlar qué clientes pueden enviar tráfico a los recursos de Private Service Connect, usa cortafuegos o políticas de cortafuegos de VPC.

Para obtener más información sobre los permisos de gestión de identidades y accesos, consulta Permisos de gestión de identidades y accesos.

Para obtener información sobre los permisos necesarios para crear un endpoint, consulta Crear un endpoint.

Para obtener información sobre los permisos necesarios para crear un archivo adjunto de servicio, consulta Publicar un servicio con aprobación explícita.

Estados de conexión

Recursos: endpoints, backends y adjuntos de servicio

Los endpoints, los backends y los adjuntos de servicio de Private Service Connect tienen un estado de conexión que describe el estado de su conexión. Los recursos de consumidor y productor que forman los dos extremos de una conexión siempre tienen el mismo estado. Puedes ver los estados de conexión cuando consultas los detalles de un punto final, describes un backend o consultas los detalles de un servicio publicado.

En la siguiente tabla se describen los posibles estados.

Estado de conexión Descripción
Aceptado Se ha establecido la conexión de Private Service Connect. Las dos redes de VPC tienen conectividad y la conexión funciona correctamente.
Pendiente

La conexión de Private Service Connect no se establece y el tráfico de red no puede desplazarse entre las dos redes. Una conexión puede tener este estado por los siguientes motivos:

Las conexiones que se bloquean por estos motivos permanecen en estado pendiente indefinidamente hasta que se resuelva el problema subyacente.

Rechazado

La conexión de Private Service Connect no se ha establecido. El tráfico de red no puede viajar entre las dos redes. Una conexión puede tener este estado por los siguientes motivos:

Requiere atención Hay un problema en el lado del productor de la conexión. Es posible que parte del tráfico pueda fluir entre las dos redes, pero algunas conexiones podrían no funcionar. Por ejemplo, es posible que la subred NAT del productor se haya agotado y no pueda asignar direcciones IP a las nuevas conexiones.
Cerrada

Se ha eliminado la vinculación de servicio y se ha cerrado la conexión de Private Service Connect. El tráfico de red no puede viajar entre las dos redes.

Una conexión cerrada es un estado terminal. Para restaurar la conexión, debes volver a crear tanto el adjunto de servicio como el endpoint o el backend.

Configuración de vinculación de servicio

Puedes controlar qué consumidores pueden conectarse a un adjunto de servicio mediante las siguientes funciones.

Preferencia de conexión

Recursos: endpoints y backends

Cada adjunto de servicio tiene una preferencia de conexión que especifica si las solicitudes de conexión se aceptan automáticamente. Hay tres opciones posibles:

  • Aceptar todas las conexiones automáticamente. El adjunto de servicio acepta automáticamente todas las solicitudes de conexión entrantes de cualquier consumidor. Una política de la organización puede anular la aceptación automática y bloquear las conexiones entrantes.
  • Aceptar conexiones de las redes seleccionadas. La vinculación de servicio solo acepta solicitudes de conexión entrantes si la red de VPC del consumidor está en la lista de consumidores aceptados de la vinculación de servicio.
  • Aceptar las conexiones de los proyectos seleccionados. El adjunto de servicio solo acepta solicitudes de conexión entrantes si el proyecto de consumidor está en la lista de consumidores aceptados del adjunto de servicio.

Te recomendamos que aceptes las conexiones de los proyectos o las redes seleccionados. Aceptar automáticamente todas las conexiones puede ser adecuado si controlas el acceso de los consumidores por otros medios y quieres habilitar el acceso permisivo a tu servicio.

Listas de aceptación y rechazo

Recursos: endpoints y backends

Las listas de aceptación de consumidores y las listas de rechazo de consumidores son una función de seguridad de los archivos adjuntos de los servicios. Las listas de aceptación y rechazo permiten a los productores de servicios especificar qué consumidores pueden establecer conexiones de Private Service Connect con sus servicios. Las listas de aceptación de consumidores especifican si se acepta una conexión, y las listas de rechazo de consumidores especifican si se rechaza una conexión. Ambas listas te permiten especificar consumidores por la red de VPC o el proyecto del recurso de conexión. Si añades un proyecto o una red a la lista de permitidos y a la de denegados, se rechazarán las solicitudes de conexión de ese proyecto o red. No se admite la especificación de consumidores por carpeta.

Las listas de aceptación y de rechazo de consumidores te permiten especificar proyectos o redes VPC, pero no ambos al mismo tiempo. Puedes cambiar una lista de un tipo a otro sin interrumpir las conexiones, pero debes hacer el cambio en una sola actualización. De lo contrario, algunas conexiones podrían cambiar temporalmente al estado pendiente.

Las listas de consumidores controlan si un punto final puede conectarse a un servicio publicado, pero no controlan quién puede enviar solicitudes a ese punto final. Por ejemplo, supongamos que un consumidor tiene una red de VPC compartida a la que tiene asociados dos proyectos de servicio. Si un servicio publicado tiene service-project1 en la lista de aceptación de consumidores y service-project2 en la lista de rechazo de consumidores, se aplican las siguientes condiciones:

  • Un consumidor de service-project1 puede crear un punto final que se conecte al servicio publicado.
  • Un consumidor de service-project2 no puede crear un punto final que se conecte al servicio publicado.
  • Un cliente de service-project2 puede enviar solicitudes al endpoint de service-project1 si no hay reglas ni políticas de cortafuegos que impidan ese tráfico.

Cuando actualiza una lista de aceptación o rechazo de consumidores, el efecto en las conexiones existentes varía en función de si la conciliación de conexiones está habilitada. Para obtener más información, consulta Reconciliación de conexiones.

Para obtener información sobre cómo crear un nuevo adjunto de servicio que tenga listas de aceptación o rechazo de consumidores, consulta Publicar un servicio con aprobación explícita del proyecto.

Para obtener información sobre cómo actualizar las listas de aceptación o rechazo de consumidores, consulta Gestionar solicitudes de acceso a un servicio publicado.

Límites de conexiones

Recursos: endpoints y backends

Las listas de aceptación de consumidores tienen límites de conexión. Estos límites definen el número total de conexiones de backend y de punto final de Private Service Connect que una vinculación de servicio puede aceptar del proyecto o la red de VPC del consumidor especificados.

Los productores pueden usar límites de conexión para evitar que los consumidores individuales agoten las direcciones IP o las cuotas de recursos en la red de VPC del productor. Cada conexión de Private Service Connect aceptada se resta del límite configurado para un proyecto o una red de VPC de consumidor. Los límites se definen al crear o actualizar listas de aceptación de consumidores. Puedes ver las conexiones de un archivo adjunto de servicio cuando describes un archivo adjunto de servicio.

Las conexiones propagadas no se tienen en cuenta para estos límites.

Por ejemplo, supongamos que un adjunto de servicio tiene una lista de aceptación de consumidores que incluye project-1 y project-2, ambos con un límite de una conexión. El proyecto project-1 solicita dos conexiones, project-2 solicita una conexión y project-3 solicita una conexión. Como project-1 tiene un límite de una conexión, la primera se acepta y la segunda se queda pendiente. Se acepta la conexión de project-2 y la de project-3 sigue pendiente. La segunda conexión de project-1 se puede aceptar aumentando el límite de project-1. Si se añade project-3 a la lista de aceptación del consumidor, esa conexión pasa de pendiente a aceptada.

Políticas de organización

Las políticas de la organización le permiten controlar de forma general qué proyectos pueden conectarse a redes de VPC u organizaciones mediante Private Service Connect.

Las políticas de la organización descritas en esta página pueden bloquear o rechazar nuevas conexiones de Private Service Connect, pero no afectan a las conexiones ya establecidas.

Una política de organización se aplica a los descendientes del recurso al que hace referencia según la evaluación de la jerarquía. Por ejemplo, una política de organización que restringe el acceso a una Google Cloud organización también se aplica a las carpetas, los proyectos y los recursos secundarios de la organización. Del mismo modo, si se incluye una organización en la lista de valores permitidos, también se podrá acceder a sus organizaciones secundarias.

Para obtener más información sobre las políticas de la organización, consulta el artículo Políticas de la organización.

Políticas de organización del lado del consumidor

Puedes usar restricciones de lista para controlar la implementación de endpoints y back-ends. Si un consumidor bloquea un endpoint o un backend mediante una política de organización, no se podrá crear el recurso.

  • Usa la restricción de lista restrictPrivateServiceConnectProducer para controlar a qué endpoints y back-ends de adjuntos de servicio se pueden conectar en función de la organización productora.
  • Usa la restricción de lista disablePrivateServiceConnectCreationForConsumers para controlar la implementación de los endpoints en función del tipo de conexión del endpoint. Puedes bloquear la implementación de los puntos finales que se conectan a las APIs de Google o a los servicios publicados.

Impedir que los endpoints o los back-ends se conecten a organizaciones de productores

Recursos: endpoints y backends

Las políticas de organización que usan la restricción de lista restrictPrivateServiceConnectProducer con valores permitidos impiden que los endpoints y los backends se conecten a los adjuntos de servicio, a menos que estos estén asociados a uno de los valores permitidos de la política. Una política de este tipo bloquea las conexiones aunque la lista de consumidores aceptados del adjunto de servicio las permita.

Por ejemplo, la siguiente política de organización se aplica a una organización llamada Org-A:

name: organizations/Org-A/policies/compute.restrictPrivateServiceConnectProducer
spec:
  rules:
    – values:
        allowedValues:
        - under:organizations/ORG_A_NUMBER
        - under:organizations/433637338589

En la figura 2 se muestra el resultado de esta política de la organización. La política tiene valores permitidos para Org-A (ORG_A_NUMBER) y Google-org (433637338589). Los endpoints y los back-ends creados en Org-A pueden comunicarse con los archivos adjuntos de servicio de Org-A, pero no con los de Org-B.

Imagen 2. Una política de organización permite que el endpoint psc-1 se conecte a la vinculación de servicio sa-1 y evita que psc-3 se conecte a vinculaciones de servicio en Org-B. Los endpoints y los backends de Org-A pueden conectarse a los adjuntos de servicio propiedad de Google (haz clic en la imagen para ampliarla).

Puede permitir que las instancias de los siguientes tipos de recursos creen endpoints con la restricción compute.restrictPrivateServiceConnectProducer:

  • Organizaciones
  • Carpetas
  • Proyectos

Para obtener información sobre cómo crear una política de la organización que utilice la restricción compute.restrictPrivateServiceConnectProducer, consulta el artículo Bloquear que los endpoints y los backends se conecten a adjuntos de servicio no autorizados.

Bloquear la creación de endpoints por tipo de conexión

Recursos afectados: endpoints

Puedes usar la restricción de disablePrivateServiceConnectCreationForConsumers lista para bloquear la creación de puntos finales en función de si se conectan a APIs de Google o a servicios publicados (adjuntos de servicio).

Para obtener información sobre cómo crear una política de organización que use la restricción disablePrivateServiceConnectCreationForConsumers, consulta el artículo Impedir que los consumidores implementen endpoints por tipo de conexión.

Políticas de organización del lado del productor

Recursos afectados: endpoints y back-ends

Puedes usar políticas de la organización con la compute.restrictPrivateServiceConnectConsumer restricción de lista para controlar qué puntos finales y back-ends pueden conectarse a los adjuntos de servicio de Private Service Connect en una organización o proyecto de productor. Si una política de una organización productora rechaza un endpoint o un backend, el recurso se creará correctamente, pero la conexión pasará al estado de rechazo.

Controlar el acceso de esta forma es similar a usar listas de aceptación y rechazo, excepto que las políticas de la organización se aplican a todos los adjuntos de servicio de un proyecto o una organización, en lugar de a un adjunto de servicio concreto.

Puedes usar políticas de la organización y listas de elementos permitidos conjuntamente. Las políticas de la organización aplican de forma general el acceso a un servicio gestionado, mientras que las listas de elementos permitidos controlan el acceso a archivos adjuntos de servicios concretos.

Las políticas de la organización que usan la restricción compute.restrictPrivateServiceConnectConsumer rechazan las conexiones de endpoints y backends, a menos que el endpoint o el backend estén asociados a uno de los valores permitidos de la política. Una política de este tipo rechaza las conexiones aunque estén permitidas en una lista de permitidos.

Por ejemplo, la siguiente política de la organización se aplica a una organización llamada Org-A:

name: organizations/Org-A/policies/compute.restrictPrivateServiceConnectConsumer
spec:
  rules:
    - values:
        allowedValues:
        - under:organizations/ORG_A_NUMBER

En la imagen 3 se muestra el resultado de esta política de organización. La política tiene un valor permitido para Org-A (ORG_A_NUMBER). Los endpoints de otras redes de VPC de Org-A pueden conectarse a los adjuntos de servicio de Org-A. Se rechazan los endpoints de Org-B que intentan conectarse.

Imagen 3. Una política de la organización permite que psc-1 se conecte a sa-1, pero impide que psc-2 se conecte (haz clic para ampliar).

Una política de organización se aplica a los descendientes del recurso al que hace referencia según la evaluación de la jerarquía. Por ejemplo, una política de organización que restringe el acceso a una Google Cloud organización también se aplica a las carpetas, los proyectos y los recursos secundarios de la organización. Del mismo modo, si se incluye una organización en la lista de valores permitidos, también se podrá acceder a sus organizaciones secundarias.

Puede permitir que las instancias de los siguientes tipos de recursos creen endpoints con la restricción restrictPrivateServiceConnectConsumer:

  • Organizaciones
  • Carpetas
  • Proyectos

Para obtener más información sobre cómo usar las políticas de organización con productores de servicios, consulta Políticas de organización de productores.

Interacción entre las listas de elementos aceptados de los consumidores y las políticas de la organización

Tanto las listas de aceptación de consumidores como las políticas de la organización controlan si se puede establecer una conexión entre dos recursos de Private Service Connect. Las conexiones se bloquean si una lista de permitidos o una política de la organización deniega la conexión.

Por ejemplo, una política con la restricción restrictPrivateServiceConnectConsumer se puede configurar para bloquear las conexiones que procedan de fuera de la organización del productor. Aunque un adjunto de servicio esté configurado para aceptar automáticamente todas las conexiones, la política de la organización sigue bloqueando las conexiones que procedan de fuera de la organización del productor. Te recomendamos que uses tanto listas de aceptación como políticas de la organización para proporcionar una seguridad por capas.

Cortafuegos

Recursos: todos

Puedes usar reglas y políticas de cortafuegos de VPC para controlar el acceso a nivel de red a los recursos de Private Service Connect.

Para obtener más información sobre las reglas de cortafuegos de VPC en general, consulta Reglas de cortafuegos de VPC.

Para obtener más información sobre cómo usar reglas de cortafuegos de VPC para limitar el acceso a endpoints o back-ends en una red de VPC de consumidor, consulta Usar reglas de cortafuegos para limitar el acceso a endpoints o back-ends.