En esta página se describe cómo permitir el tráfico de direcciones IP internas en una red de VPC a perímetros de servicio mediante reglas de entrada y salida.
Información general
Puedes usar Controles de Servicio de VPC para especificar las condiciones que permiten que determinados intervalos de direcciones IP de la red VPC accedan a los proyectos y las redes VPC protegidos. Esta función te permite hacer lo siguiente:
Admite condiciones de nivel de acceso básico para permitir intervalos de direcciones IP internas de redes de VPC.
Permite el uso de estas condiciones de nivel de acceso para las llamadas a la API de entrada o salida dentro o fuera del límite del perímetro de servicio.
Esta función ofrece las siguientes ventajas:
Puedes especificar condiciones en las configuraciones de Controles de Servicio de VPC para permitir el acceso desde una dirección IP interna de una red VPC.
Los flujos de trabajo que requieren que las llamadas a APIs pasen por varios perímetros de servicio pueden restringir el acceso para permitir solo unas pocas subredes en lugar de permitir toda la red o el proyecto de VPC.
Puedes configurar diferentes recursos de tu entorno local para que solo puedan acceder a recursos específicos. Google Cloud Debes usar el intervalo de direcciones IP de la subred asociada a estos recursos on-premise y la red de VPC de la zona de aterrizaje como parte del nivel de acceso.
En la figura 1 se muestra un ejemplo de configuración que permite acceder a un servicio protegido específico desde una dirección IP interna autorizada.
Limitaciones al usar direcciones IP internas
Cuando usas una dirección IP interna en Controles de Servicio de VPC, se aplican las siguientes limitaciones:
Solo puedes habilitar una dirección IP interna con niveles de acceso básicos, no con niveles de acceso personalizados.
Te recomendamos que no niegues los niveles de acceso con condiciones basadas en direcciones IP internas, ya que puede provocar comportamientos inesperados.
También se aplican las limitaciones para añadir redes de VPC a perímetros de servicio.
Cuando Controles de Servicio de VPC registra un registro de auditoría de política denegada, oculta el nombre de la red de VPC como
__UNKNOWN__
en el registro de auditoría.No se admiten las redes de VPC en las que
SUBNET_MODE
está configurado comocustom
pero no tienen subredes. Para habilitar la dirección IP interna, una red de VPC debe contener al menos una subred.Solo puedes especificar 500 redes VPC en todos los niveles de acceso de tu política de acceso.
Cuando eliminas una red VPC a la que hace referencia un nivel de acceso o un perímetro de servicio y, a continuación, vuelves a crear otra red VPC con el mismo nombre, Controles de Servicio de VPC no habilita automáticamente las direcciones IP internas en la red VPC recreada. Para solucionar este problema, crea una red de VPC con otro nombre y añádela al perímetro.
No puedes usar una dirección IP interna para permitir el acceso desde servicios gestionados por Google. Por ejemplo, Cloud SQL.
Si usas un nivel de acceso que tiene condiciones basadas en direcciones IP internas con una regla de salida, te recomendamos que no añadas ninguna otra condición, como el tipo de dispositivo o la identidad del usuario, al nivel de acceso.
La dirección IP interna no coincide con los niveles de acceso que hacen referencia a regiones geográficas.
Usar direcciones IP internas en niveles de acceso
Especifica el nombre de la red de VPC y el intervalo de direcciones IP en el campo
vpcNetworkSources
de la condición del nivel de acceso básico.Nombre de la red de VPC. Debes definir el nombre de la red VPC con el siguiente formato:
//compute.googleapis.com/projects/PROJECT_ID/global/networks/NETWORK_NAME
Por ejemplo,
//compute.googleapis.com/projects/my-project/global/networks/my-vpc
.Intervalo de direcciones IP. El intervalo de direcciones IP especificado en el campo
VpcSubNetwork
deVpcNetworkSource
debe seguir la especificación de subred IP de bloque CIDR. Puedes usar cualquier intervalo de direcciones IP que sea un intervalo IPv4 válido para las subredes.
Usa este nivel de acceso con condiciones de permiso en
IngressSource
oEgressSource
.
En las siguientes secciones se explica cómo llevar a cabo estos pasos para habilitar una dirección IP interna mediante un ejemplo.
Ejemplo de uso de una dirección IP interna para configurar el acceso a la subred
En el siguiente ejemplo, tienes dos proyectos:
Proyecto del host de la red:
Project1
aloja una red de VPC:default
. Las dos VMs deProject1
,VM1
yVM2
, usan esta red como interfaz de red para enviar tráfico.Proyecto de Cloud Storage:
Project2
contiene un segmento de Cloud Storage.
Puedes usar Controles de Servicio de VPC para permitir que solo VM1
de Project1
acceda al
cubo de Cloud Storage en Project2
mediante una dirección IP interna.
Para conseguir esta configuración, debes seguir estos pasos:
Creas un perímetro de servicio
sp1
alrededor deProject1
y otro perímetro de serviciosp2
alrededor deProject2
.Después, puedes añadir reglas de entrada y salida a los perímetros de servicio para permitir que solo la subred de
VM1
acceda al segmento de Cloud Storage.
En el siguiente diagrama se muestra la configuración descrita en este ejemplo.
Configurar una política de acceso a nivel de organización
Asegúrate de que tienes una política de acceso a nivel de organización. Si no tienes una política de acceso en este nivel, ejecuta el siguiente comando de la CLI de gcloud:
gcloud access-context-manager policies create \ --organization=ORGANIZATION_ID --title=POLICY_TITLE
Haz los cambios siguientes:
ORGANIZATION_ID: el ID numérico de tu organización.
POLICY_TITLE: título legible para personas de tu política de acceso.
Para obtener más información, consulta Crear una política de acceso a nivel de organización.
Para definir esta política como tu política de acceso predeterminada, ejecuta el siguiente comando de la CLI de gcloud:
gcloud config set access_context_manager/policy POLICY_NAME
Sustituye POLICY_NAME por el nombre numérico de tu política de acceso.
Para obtener más información, consulta Definir la política de acceso predeterminada para la herramienta de línea de comandos
gcloud
.
Crea perímetros para proteger el proyecto host de la red y el proyecto de Cloud Storage
Para crear un perímetro
sp1
alrededor deProject1
, ejecuta el siguiente comando de gcloud CLI:gcloud access-context-manager perimeters create sp1 --title="sp1" --resources=PROJECT_NUMBER \ --restricted-services=storage.googleapis.com --policy=POLICY_NAME
Haz los cambios siguientes:
PROJECT_NUMBER: número de proyecto del proyecto host de la red. Por ejemplo,
projects/111
.POLICY_NAME: nombre numérico de tu política de acceso. Por ejemplo,
1234567890
.
Para crear un perímetro
sp2
alrededor deProject2
que restrinja el servicio Cloud Storage, ejecuta el siguiente comando de gcloud CLI:gcloud access-context-manager perimeters create sp2 --title="sp2" --resources=PROJECT_NUMBER \ --restricted-services=storage.googleapis.com --policy=POLICY_NAME
Haz los cambios siguientes:
PROJECT_NUMBER: el número de proyecto de Cloud Storage. Por ejemplo,
projects/222
.POLICY_NAME: nombre numérico de tu política de acceso. Por ejemplo,
1234567890
.
Para obtener más información sobre cómo crear un perímetro de servicio, consulta Crear un perímetro de servicio.
Después de crear estos dos perímetros, ya no se podrá acceder al bucket de Cloud Storage desde las dos máquinas virtuales.
Crear un nivel de acceso con una condición de acceso basada en una dirección IP interna
Crea un nivel de acceso que solo permita el tráfico procedente de la subred de VM1
.
Crea un archivo YAML que defina tus condiciones de acceso. En el siguiente ejemplo solo se muestran los atributos que necesita para habilitar una dirección IP interna:
echo """ - vpcNetworkSources: - vpcSubnetwork: network: VPC_NETWORK_NAME vpcIpSubnetworks: - IP_RANGE """ > level.yaml
Haz los cambios siguientes:
VPC_NETWORK_NAME: nombre de la red de VPC en la que reside
VM1
. Por ejemplo,//compute.googleapis.com/projects/Project1/global/networks/default
.IP_RANGE: intervalo de direcciones IP de la subred. Por ejemplo,
10.10.0.0/24
.
Usa el nombre de la red VPC y los formatos de intervalo de direcciones IP que se han explicado anteriormente.
Para obtener más información sobre el archivo YAML, consulta
basic-level-spec
Archivo YAML.Para crear un nivel de acceso con el archivo YAML, ejecuta el siguiente comando de la CLI de gcloud:
gcloud access-context-manager levels create LEVEL_NAME \ --title="TITLE" --basic-level-spec=FILE_NAME
Haz los cambios siguientes:
LEVEL_NAME: nombre único del nivel de acceso. Por ejemplo,
allowvm1
.TITLE: título breve y legible para el nivel de acceso. Por ejemplo,
allowvm1
.FILE_NAME: el archivo YAML que define las condiciones de acceso del nivel de acceso. Por ejemplo,
level.yaml
.
Para obtener más información, consulta el artículo Crear un nivel de acceso básico.
Configurar una política de entrada para permitir el tráfico de APIs entrante al segmento de Cloud Storage
Para permitir el acceso solo desde VM1
, configura una política de entrada en el perímetro sp2
para permitir que el tráfico de la API de Cloud Storage entre en el perímetro.
Crea un archivo YAML que defina tu política de entrada.
echo """ - ingressFrom: identityType: ANY_IDENTITY sources: - accessLevel: accessPolicies/POLICY_NAME/accessLevels/ACCESS_LEVEL_NAME ingressTo: operations: - methodSelectors: - method: '*' serviceName: storage.googleapis.com resources: - '*' """ > ingress.yaml
Haz los cambios siguientes:
POLICY_NAME: nombre numérico de tu política de acceso. Por ejemplo,
1234567890
.ACCESS_LEVEL_NAME: el nombre de tu nivel de acceso. Por ejemplo,
allowvm1
.
Para obtener más información sobre el archivo YAML, consulta la referencia de reglas de Ingress.
Para actualizar la política de entrada de un perímetro de servicio, ejecuta el siguiente comando de la CLI de gcloud:
gcloud access-context-manager perimeters update PERIMETER --set-ingress-policies=FILE_NAME
Haz los cambios siguientes:
PERIMETER: nombre del perímetro de servicio que protege el proyecto de Cloud Storage. Por ejemplo,
sp2
.FILE_NAME: archivo YAML que define tu política de entrada. Por ejemplo,
ingress.yaml
.
Para obtener más información, consulta Actualizar las políticas de entrada y salida de un perímetro de servicio.
Configurar una política de salida para permitir el tráfico de API saliente al segmento de Cloud Storage
Además, configura una política de salida en el perímetro sp1
para permitir que el tráfico de la API de Cloud Storage salga del perímetro.
Crea un archivo YAML que defina tu política de salida. Asegúrate de que el campo
sourceRestriction
seaSOURCE_RESTRICTION_ENABLED
en el archivo YAML.echo """ - egressFrom: identityType: ANY_IDENTITY sourceRestriction: SOURCE_RESTRICTION_ENABLED sources: - accessLevel: accessPolicies/POLICY_NAME/accessLevels/ACCESS_LEVEL_NAME egressTo: operations: - methodSelectors: - method: '*' serviceName: storage.googleapis.com resources: - '*' """ > egress.yaml
Haz los cambios siguientes:
POLICY_NAME: nombre numérico de tu política de acceso. Por ejemplo,
1234567890
.ACCESS_LEVEL_NAME: el nombre de tu nivel de acceso. Por ejemplo,
allowvm1
.
Para obtener más información sobre el archivo YAML, consulta la referencia de reglas de salida.
Para actualizar la política de salida de un perímetro de servicio, ejecuta el siguiente comando:
gcloud access-context-manager perimeters update PERIMETER --set-egress-policies=FILE_NAME
Haz los cambios siguientes:
PERIMETER: nombre del perímetro de servicio que protege el proyecto host de la red. Por ejemplo,
sp1
.FILE_NAME: el archivo YAML que define tu política de salida. Por ejemplo,
egress.yaml
.
Para obtener más información, consulta Actualizar las políticas de entrada y salida de un perímetro de servicio.
Una vez que hayas configurado las políticas de entrada y salida, se podrá acceder al segmento de Cloud Storage desde VM1
, pero no desde VM2
.
Recomendaciones
Cuando habilites una dirección IP interna, te recomendamos que inhabilites el reenvío de IP en tus VMs. El reenvío de IP permite que una VM de la misma red VPC envíe solicitudes con una dirección IP diferente, lo que supone un riesgo de suplantación de la dirección IP.
Si quieres habilitar el reenvío de IP, te recomendamos que utilices las siguientes configuraciones para reducir el riesgo de suplantación de la dirección IP:
Usa la
Restrict VM IP Forwarding
restricción de la política de organización (constraints/compute.vmCanIpForward
) para asegurarte de que solo las VMs autorizadas puedan habilitar el reenvío de IP.Usa fuentes para las reglas de cortafuegos para restringir las direcciones IP que pueden comunicarse con las VMs que tienen habilitado el reenvío de IP. Completa las siguientes tareas:
Configura reglas de cortafuegos de entrada para permitir el tráfico entrante solo desde un intervalo de direcciones IP específico a las VMs que tengan habilitado el reenvío de IP.
Configura reglas de cortafuegos de salida para permitir el tráfico saliente solo a un intervalo de direcciones IP específico desde las VMs que tengan habilitado el reenvío de IP.