En esta página, se describe cómo permitir el tráfico desde direcciones IP internas en una De la red de VPC a los perímetros de servicio con reglas de entrada y salida.
Descripción general
Puedes usar los Controles del servicio de VPC para definir condiciones los rangos de direcciones IP de la red de VPC para acceder a proyectos y redes de VPC. Esta función te permite hacer lo siguiente: tareas:
Admitir acceso básico las condiciones de nivel permiten rangos de direcciones IP internas de las redes de VPC.
Permitir el uso de estas condiciones de nivel de acceso para la API de entrada o salida dentro o fuera del límite del perímetro de servicio.
Esta función proporciona los siguientes beneficios:
Puedes especificar condiciones en la configuración de los Controles del servicio de VPC para permitir acceso desde una dirección IP interna en una red de VPC.
Workflows que requieren llamadas a la API para pasar por varios perímetros de servicio pueden restringir el acceso para permitir solo unas pocas subredes, en lugar de permitir de toda la red de VPC o del proyecto.
Puedes configurar diferentes recursos del entorno local acceder solo a recursos específicos de Google Cloud. Debes usar la IP de la subred rango de direcciones asociado con estos recursos locales y la zona de destino red de VPC como parte del nivel de acceso.
En la figura 1, se muestra un ejemplo de configuración que permite el acceso a un recurso protegido de Google Cloud desde una dirección IP interna autorizada.
Limitaciones del uso de direcciones IP internas
Cuando usas una dirección IP interna en los Controles del servicio de VPC, ocurre lo siguiente: se aplican limitaciones:
Puedes habilitar una dirección IP interna solo con niveles de acceso básicos, no con niveles de acceso personalizados.
Te recomendamos que no niegues los niveles de acceso con direcciones IP internas debido a que pueden provocar comportamientos inesperados.
Las limitaciones para agregar redes de VPC a perímetros de servicio.
Cuando los Controles del servicio de VPC registran un registro de auditoría de política denegada, se oculta el nombre de la red de VPC como
__UNKNOWN__
en el registro de auditoría.Redes de VPC para las que
SUBNET_MODE
se establece comocustom
pero no tienen subredes, no son compatibles. Habilita la dirección IP interna requiere que la red de VPC contenga al menos una subred.Solo puedes especificar 500 VPC redes en todas niveles de acceso en tu política de acceso.
Cuando borras una red de VPC a la que hace referencia un acceso o un perímetro de servicio, y vuelve a crear otra VPC con el mismo nombre, los Controles del servicio de VPC no habilitan direcciones IP internas en la red de VPC recreada. Para esta limitación, crea una red de VPC con una un nombre diferente y agregarlo al perímetro.
No puedes usar una dirección IP interna para permitir el acceso de Google Cloud. 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 agregues ninguna otra condición como el tipo de dispositivo y la identidad del usuario en el nivel de acceso.
La dirección IP interna no coincide con los niveles de acceso que hacen referencia a ubicaciones geográficas regiones.
Usar la dirección IP interna en los niveles de acceso
Especifica el nombre de la red de VPC y el rango de direcciones IP en la Campo
vpcNetworkSources
de nivel de acceso básico estado.Nombre de la red de VPC. Debes definir la VPC el nombre de la red en 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
.Rango de direcciones IP. El rango de direcciones IP especificado en el archivo
VpcSubNetwork
campo deVpcNetworkSource
debe seguir la especificación de subred de IP de bloque de CIDR. Puedes usar cualquier dirección IP que sea un rango IPv4 válido para las subredes.
Usa este nivel de acceso con condiciones de permiso en la
IngressSource
oEgressSource
A través de una situación de ejemplo, en las siguientes secciones se explica cómo realizar estas pasos para habilitar una dirección IP interna.
Ejemplo de cómo usar una dirección IP interna para configurar el acceso a la subred
En el siguiente ejemplo, tienes dos proyectos:
Proyecto host de la red:
Project1
aloja una red de VPC:default
Las dos VMs enProject1
,VM1
yVM2
usan esta red como un de red de destino para enviar el tráfico.Proyecto de Cloud Storage:
Project2
contiene un bucket de Cloud Storage.
Puedes usar los Controles del servicio de VPC para permitir que solo VM1
de Project1
acceda a la
Bucket de Cloud Storage en Project2
con una dirección IP interna.
Para lograr esta configuración, debes seguir estos pasos:
Creas un perímetro de servicio
sp1
alrededor deProject1
y otro servicio perímetrosp2
alrededor deProject2
.Luego, puedes agregar reglas de entrada y salida a los perímetros de servicio para Permitir el acceso de la subred de
VM1
al bucket de Cloud Storage únicamente
En el siguiente diagrama, se muestra la configuración descrita en este ejemplo.
Configura una política de acceso a nivel de la organización
Asegúrate de tener una política de acceso a nivel de la organización. Si no tienes una política de acceso en este nivel, ejecuta el siguiente comando Comando de gcloud CLI:
gcloud access-context-manager policies create \ --organization=ORGANIZATION_ID --title=POLICY_TITLE
Reemplaza lo siguiente:
ORGANIZATION_ID: Es el ID numérico de la organización.
POLICY_TITLE: Es un título legible para tu política de acceso.
Para obtener más información, consulta Crea un acceso a nivel de la organización política.
Para establecer esta política como tu política de acceso predeterminada, ejecuta el siguiente comando: Comando de gcloud CLI:
gcloud config set access_context_manager/policy POLICY_NAME
Reemplaza POLICY_NAME por el nombre numérico de la política de acceso.
Para obtener más información, consulta Establece la política de acceso predeterminada para La herramienta de línea de comandos de
gcloud
.
Crea perímetros para proteger el proyecto host de red y el proyecto de Cloud Storage
Para crear un perímetro
sp1
alrededor deProject1
, ejecuta el siguiente comando: Comando de gcloud CLI:gcloud access-context-manager perimeters create sp1 --title="sp1" --resources=PROJECT_NUMBER \ --restricted-services=storage.googleapis.com --policy=POLICY_NAME
Reemplaza lo siguiente:
PROJECT_NUMBER: Es el número de proyecto del proyecto host de red. Por ejemplo,
projects/111
POLICY_NAME: Es el nombre numérico de la política de acceso. Por ejemplo,
1234567890
.
Para crear un perímetro
sp2
alrededor deProject2
que restrinja En el servicio de 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
Reemplaza lo siguiente:
PROJECT_NUMBER: Es el número de proyecto de la unidad de almacenamiento de Cloud Storage. en un proyecto final. Por ejemplo,
projects/222
POLICY_NAME: Es el nombre numérico de la política de acceso. Por ejemplo,
1234567890
.
Si quieres obtener más información para crear un perímetro de servicio, consulta Crea un perímetro de servicio. perímetro de servicio.
Después de crear estos dos perímetros, el bucket de Cloud Storage al que se puede acceder desde ambas VMs.
Crea un nivel de acceso con una condición de acceso basada en la dirección IP interna
Crea un nivel de acceso que solo permita el tráfico proveniente de la subred de VM1
.
Crea un archivo YAML que defina tus condiciones de acceso. El siguiente ejemplo muestra solo los atributos necesarios para habilitar una dirección IP interna:
echo """ - vpcNetworkSources: - vpcSubnetwork: network: VPC_NETWORK_NAME vpcIpSubnetworks: - IP_RANGE """ > level.yaml
Reemplaza lo siguiente:
VPC_NETWORK_NAME: Es el nombre de la red de VPC. donde reside
VM1
. Por ejemplo,//compute.googleapis.com/projects/Project1/global/networks/default
.IP_RANGE: El rango de direcciones IP de la subred. Por ejemplo,
10.10.0.0/24
Usa el nombre de la red de VPC y los formatos de rango de direcciones IP se explicó anteriormente.
Para obtener más información sobre el archivo YAML, consulta
basic-level-spec
YAML archivo.Para crear un nivel de acceso con el archivo YAML, ejecuta el siguiente comando: Comando de gcloud CLI:
gcloud access-context-manager levels create LEVEL_NAME \ --title="TITLE" --basic-level-spec=FILE_NAME
Reemplaza lo siguiente:
LEVEL_NAME: Es un nombre único para el nivel de acceso. Por ejemplo,
allowvm1
TITLE: Es un título corto y legible por humanos para el nivel de acceso. Por ejemplo,
allowvm1
FILE_NAME: Es el archivo YAML que define tus condiciones de acceso. para el nivel de acceso. Por ejemplo,
level.yaml
Para obtener más información, consulta Crea un acceso básico nivel de almacenamiento.
Configura una política de entrada para permitir el tráfico de API entrante al bucket de Cloud Storage
Para permitir el acceso solo desde VM1
, configura una política de entrada en sp2
para permitir que el tráfico de la API de Cloud Storage ingrese a él.
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
Reemplaza lo siguiente:
POLICY_NAME: Es el nombre numérico de la política de acceso. Por ejemplo,
1234567890
ACCESS_LEVEL_NAME: Es el nombre de tu nivel de acceso. Por ejemplo,
allowvm1
.
Para obtener más información sobre el archivo YAML, consulta Reglas de entrada. referencia.
Para actualizar la política de entrada de un perímetro de servicio, ejecuta el siguiente comando: Comando de gcloud CLI:
gcloud access-context-manager perimeters update PERIMETER --set-ingress-policies=FILE_NAME
Reemplaza lo siguiente:
PERIMETER: Es el nombre del perímetro de servicio que protege al Proyecto de Cloud Storage. Por ejemplo,
sp2
FILE_NAME: Es el archivo YAML que define tu política de entrada. Por ejemplo,
ingress.yaml
.
Para obtener más información, consulta Actualiza 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 bucket de Cloud Storage
Además, configura una política de salida en el perímetro sp1
para permitir
el tráfico de la API de Cloud Storage para salir del perímetro.
Crea un archivo YAML que defina tu política de salida. Asegúrate de establecer el campo
sourceRestriction
comoSOURCE_RESTRICTION_ENABLED
en el archivo .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
Reemplaza lo siguiente:
POLICY_NAME: Es el nombre numérico de la política de acceso. Por ejemplo,
1234567890
ACCESS_LEVEL_NAME: Es el nombre de tu nivel de acceso. Por ejemplo,
allowvm1
.
Para obtener más información sobre el archivo YAML, consulta Reglas de salida referencia.
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
Reemplaza lo siguiente:
PERIMETER: Es el nombre del perímetro de servicio que protege al proyecto host de la red. Por ejemplo,
sp1
FILE_NAME: Es el archivo YAML que define tu política de salida. Por ejemplo,
egress.yaml
.
Para obtener más información, consulta Actualiza las políticas de entrada y salida de un perímetro de servicio.
Después de configurar las políticas de entrada y salida, el bucket de Cloud Storage
se puede acceder desde VM1
, mientras que el bucket de Cloud Storage no
al que se puede acceder desde VM2
.
Recomendaciones
Cuando habilites una dirección IP interna, te recomendamos que inhabilites la dirección IP reenvío para tus VMs. Reenvío de IP permite que una VM dentro de la misma red de VPC envíe solicitudes con otra dirección IP, lo que implica un riesgo de falsificación de identidad.
Si deseas habilitar el reenvío de IP, te recomendamos que uses la a fin de reducir el riesgo de falsificación de identidad de direcciones IP:
Usa la política de la organización
Restrict VM IP Forwarding
restricción (constraints/compute.vmCanIpForward
) para garantizar que solo las VMs autorizadas puedan habilitar el reenvío de IP.Usa fuentes para las reglas de firewall. restringir las direcciones IP que pueden comunicarse con las VMs que tienen IP reenvío habilitado. Realice las siguientes tareas:
Configura reglas de firewall de entrada para permitir el tráfico entrante solo de un Rango de direcciones IP para las VMs que tienen habilitado el reenvío de IP.
Configura reglas de firewall de salida para permitir el tráfico saliente solo a un Rango de direcciones IP de las VMs que tienen habilitado el reenvío de IP.