Google utiliza tecnología de IA para traducir contenido a tu idioma preferido. Las traducciones realizadas con IA pueden contener errores.

Usa los Controles del servicio de VPC

Para proteger la configuración de Network Connectivity Center (NCC), usa los Controles del servicio de VPC.

Los Controles del servicio de VPC brindan seguridad adicional para los servicios y las APIs de Google, incluida la configuración de NCC. Además de IAM, los Controles del servicio de VPC limitan los sistemas de origen que pueden realizar cambios en la configuración de NCC.

En esta página, se describen un caso de uso común y una configuración de ejemplo para permitir el acceso entre un centro de NCC y radios de VPC separados por perímetros de servicio.

Para obtener documentación completa, consulta la descripción general de los Controles del servicio de VPC.

Ejemplo: Propuestas de radios de VPC interproyectos en perímetros de servicio

Si tu configuración requiere que un hub de NCC y sus radios de VPC residan en proyectos diferentes que pertenezcan a perímetros separados de Controles del servicio de VPC, debes configurar reglas de entrada y salida en ambos perímetros. Esto permite que los administradores de radios propongan un radio de VPC que haga referencia al concentrador y que los administradores de concentradores acepten los radios propuestos.

En el ejemplo de esta página, se supone que el administrador del centro y los administradores de los radios pertenecen a organizaciones separadas.

En la siguiente tabla, se resumen las reglas necesarias para este ejemplo:

del perímetro	Regla	Objetivo
Perímetro de radio (proyecto de radio)	Regla de entrada 1	Permite que el administrador del radio inicie una propuesta de radio creando un radio en el proyecto del radio (si se administra desde fuera de `SpokePerimeter`).
Perímetro de radio (proyecto de radio)	Regla de salida 1	Permite que la propuesta de radio saliente inicie la vinculación al concentrador en el proyecto del concentrador, lo que incluye la verificación de la red de VPC de respaldo.
Perímetro del centro (proyecto central)	Regla de entrada 1	Permitir que el administrador del concentrador administre el concentrador en el proyecto del concentrador, lo que incluye aceptar o rechazar propuestas de radios (si se administra el concentrador desde fuera de `HubPerimeter`)
	Regla de entrada 2	Permitir que la propuesta de radio entrante inicie la vinculación al concentrador
	Regla de salida 1	Permite que la propuesta de radio entrante llame al proyecto de radio para completar la vinculación del radio al concentrador, lo que incluye verificar la red de VPC de respaldo.

Reglas de perímetro de radios

Para habilitar la creación y administración de radios, el administrador de radios configura las siguientes reglas de entrada y salida:

Regla Detalles

Regla de entrada 1: Creación de radios Cuando un administrador de la zona inicia una propuesta de zona emitiendo el comando de creación desde fuera del perímetro (por ejemplo, desde una estación de trabajo del administrador, Cloud Shell o la consola de Google Cloud ), los Controles del servicio de VPC evalúan la llamada como una solicitud de entrada al proyecto de la zona. SpokePerimeter debe permitir la entrada desde la identidad y el origen de red del administrador de la zona para la API de NCC.

Esta regla no es necesaria si la administración de radios se realiza exclusivamente desde una red de VPC protegida por SpokePerimeter.

Regla de salida 1: Verificación de la red y la conexión del concentrador Cuando un administrador de radios propone un radio, la solicitud inicia la conexión al concentrador en el proyecto del concentrador. Como parte de la solicitud, la API de NCC también verifica la red de VPC de respaldo con la API de Compute Engine. SpokePerimeter debe permitir la salida del administrador de la conexión radial para las APIs de NCC y de Compute Engine.

Regla	Detalles
Regla de entrada 1: Creación de radios	Cuando un administrador de la zona inicia una propuesta de zona emitiendo el comando de creación desde fuera del perímetro (por ejemplo, desde una estación de trabajo del administrador, Cloud Shell o la consola de Google Cloud ), los Controles del servicio de VPC evalúan la llamada como una solicitud de entrada al proyecto de la zona. `SpokePerimeter` debe permitir la entrada desde la identidad y el origen de red del administrador de la zona para la API de NCC. Esta regla no es necesaria si la administración de radios se realiza exclusivamente desde una red de VPC protegida por `SpokePerimeter`.
Regla de salida 1: Verificación de la red y la conexión del concentrador	Cuando un administrador de radios propone un radio, la solicitud inicia la conexión al concentrador en el proyecto del concentrador. Como parte de la solicitud, la API de NCC también verifica la red de VPC de respaldo con la API de Compute Engine. `SpokePerimeter` debe permitir la salida del administrador de la conexión radial para las APIs de NCC y de Compute Engine.

Definición del perímetro del radio

Los ejemplos de reglas de entrada y salida de las siguientes secciones se basan en la siguiente definición de perímetro.

Para obtener más información sobre los perímetros de servicio, consulta Configuración y detalles del perímetro de servicio.

# Spoke perimeter definition
name: accessPolicies/2345678901/servicePerimeters/SpokePerimeter
status:
  resources:
  - projects/222222222222
  restrictedServices:
  - networkconnectivity.googleapis.com
  - compute.googleapis.com
title: SpokePerimeter

Regla de entrada del radio

En esta sección, se proporciona un ejemplo que implementa la regla de entrada para el perímetro de la zona radial, como se describe en Reglas del perímetro de la zona radial. Esta regla solo es obligatoria si se administran radios desde fuera de SpokePerimeter.

Para obtener detalles sobre la sintaxis de las reglas, consulta la referencia de las reglas de entrada. Para aplicar reglas, consulta Configura políticas de entrada y salida.

echo """
# Rule 1: Allow the spoke administrator to initiate a spoke proposal by creating
# a spoke in the spoke project (if managing from outside SpokePerimeter)
- ingressFrom:
    identities:
    # Specify the principal identifier for the spoke administrator or deployment pipeline:
    - serviceAccount:spoke-admin-sa@spoke-project.iam.gserviceaccount.com
    # - group:spoke-admins@example.org
    # - user:spoke-admin@example.org
    sources:
    - accessLevel: accessPolicies/2345678901/accessLevels/SpokeAdminAccessLevel
    # Alternatively, specify a management project or VPC network if managing
    # from a VPC network outside the perimeter:
    # - resource: projects/MANAGEMENT_PROJECT_NUMBER
  ingressTo:
    operations:
    - serviceName: networkconnectivity.googleapis.com
      methodSelectors:
      - method: "*"
    resources:
    - projects/222222222222
""" > spoke-ingress.yaml

Como práctica recomendada, define reglas de entrada que sean lo más específicas posible:

identities: Especifica solo el identificador principal necesario para tu entorno en lugar de tipos de identidad amplios. En este ejemplo, la regla 1 especifica una cuenta de servicio para una canalización de implementación automatizada. Como alternativa, puedes especificar un grupo de Google para la administración del equipo o una cuenta de usuario individual. Para obtener más información, consulta Identidades admitidas para las reglas de entrada y salida.
sources: Restringe los orígenes a niveles de acceso conocidos. En este ejemplo, se especifica un nivel de acceso de la política de acceso que administra SpokePerimeter para autorizar fuentes externas, como estaciones de trabajo de administradores, Cloud Shell o la consola de Google Cloud . Como alternativa, puedes permitir el acceso desde una red de VPC de administración fuera del perímetro con el atributo - resource: para especificar el proyecto o la red de VPC. Para obtener más información, consulta Permite el acceso desde fuera de un perímetro y Acceso adaptado al contexto con reglas de entrada.
operations: Las restricciones para networkconnectivity.googleapis.com se aplican a nivel del servicio, lo que requiere method: "*". No hay métodos más detallados disponibles para este servicio.
resources: Especifica el número de proyecto exacto del radio en resources. Evita los comodines (*).

Regla de salida de radio

En esta sección, se proporciona un ejemplo que implementa la regla de salida para el perímetro de la subred, como se describe en Reglas del perímetro de la subred.

Para obtener detalles sobre la sintaxis de las reglas, consulta la referencia de las reglas de salida.

echo """
# Rule 1: Allow the outbound spoke proposal to initiate attachment to the hub in
# the hub project, which includes verifying the backing VPC network
- egressTo:
    operations:
    - serviceName: networkconnectivity.googleapis.com
      methodSelectors:
      - method: "*"
    - serviceName: compute.googleapis.com
      methodSelectors:
      - method: NetworksService.Get
    resources:
    - projects/111111111111
  egressFrom:
    identities:
    # Specify the principal identifier for the spoke administrator or deployment pipeline:
    - serviceAccount:spoke-admin-sa@spoke-project.iam.gserviceaccount.com
    # - group:spoke-admins@example.org
    # - user:spoke-admin@example.org
""" > spoke-egress.yaml

Como práctica recomendada, define reglas de salida que sean lo más específicas posible:

identities: Especifica solo el identificador principal necesario para tu entorno en lugar de tipos de identidad amplios. En este ejemplo, la regla 1 especifica una cuenta de servicio para una canalización de implementación automatizada. Como alternativa, puedes especificar un Grupo de Google para la administración del equipo o una cuenta de usuario individual. Para obtener más información, consulta Identidades admitidas para las reglas de entrada y salida.
operations: Las restricciones para networkconnectivity.googleapis.com se aplican a nivel del servicio, lo que requiere method: "*". Para compute.googleapis.com, especifica method: NetworksService.Get para otorgar permiso para verificar la red de VPC de respaldo cuando se inicie la vinculación al centro.
resources: Especifica el número exacto del proyecto del concentrador en resources. Evita los comodines (*).

Reglas de perímetro del centro

Para habilitar la administración del centro y permitir las propuestas de radios entrantes, el administrador del centro configura las siguientes reglas de entrada y salida:

Regla	Detalles
Regla de entrada 1: Administración de la central	Cuando un administrador del centro administra el centro desde fuera del perímetro (por ejemplo, desde una estación de trabajo del administrador, Cloud Shell o la consola de Google Cloud ), los Controles del servicio de VPC evalúan la llamada como una solicitud de entrada al proyecto del centro. Esta regla permite que el administrador del concentrador revise los radios propuestos y los acepte (lo que hace que el radio pase a `ACTIVE`) o los rechace (lo que hace que el radio pase a `REJECTED`). `HubPerimeter` debe permitir el ingreso desde la identidad y el origen de red del administrador del concentrador. No se necesita esta regla si la administración del concentrador se realiza exclusivamente desde una red de VPC protegida por `HubPerimeter`.
Regla de entrada 2: Adjunto del centro	Cuando un administrador de radios propone un radio, la solicitud inicia la conexión al concentrador en el proyecto del concentrador. `HubPerimeter` debe permitir la entrada desde la identidad y el origen de red del administrador del radio para la API de NCC en todos los perímetros de servicio.
Regla de salida 1: Vinculación de radios y verificación de red	Cuando un administrador de radio propone un radio, la solicitud realiza una devolución de llamada al proyecto del radio para completar la vinculación del radio al concentrador y poner el radio en estado `PENDING_REVIEW`. Como parte de la solicitud, la API de NCC también verifica la red de VPC de respaldo con la API de Compute Engine. `HubPerimeter` debe permitir la salida del administrador de la VPC de radio para las APIs de NCC y Compute Engine.

Definición del perímetro del centro