Se usó la API de Cloud Translation para traducir esta página.

Permitir el acceso a recursos protegidos desde una dirección IP interna

En esta página, se describe cómo permitir el tráfico desde direcciones IP internas en una red de VPC a perímetros de servicio mediante reglas de entrada y salida.

Descripción general

Puedes usar los Controles del servicio de VPC para especificar condiciones que permitan que rangos de direcciones IP específicos de la red de VPC accedan a las redes de VPC y a los proyectos protegidos. Esta función te permite realizar las siguientes tareas:

Admite condiciones de nivel de acceso básico para permitir rangos de direcciones IP internas de redes de VPC.
Permite el uso de estas condiciones de nivel de acceso para llamadas a 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 el acceso desde una dirección IP interna en una red de VPC.
Workflows que requieren llamadas a la API para pasar a través de varios perímetros de servicio pueden restringir el acceso para permitir solo unas pocas subredes en lugar de permitir toda la red de VPC o el proyecto.
Puedes configurar diferentes recursos del entorno local para poder acceder solo a recursos específicos de Google Cloud. Debes usar el rango de direcciones IP de la subred asociado con estos recursos locales y la red de VPC de la zona de destino como parte del nivel de acceso.

En la Figura 1, se muestra un ejemplo de configuración que permite el acceso a un servicio protegido específico 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, se aplican las siguientes limitaciones:

Puedes habilitar una dirección IP interna solo con niveles de acceso básicos y no con niveles de acceso personalizados.
Te recomendamos que no niegues los niveles de acceso con condiciones basadas en direcciones IP internas, ya que esto puede causar comportamientos inesperados.
También se aplican las limitaciones para agregar redes de VPC a los 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.
No se admiten las redes de VPC para las que SUBNET_MODE está configurado como custom, pero no tienen subredes. Para habilitar la dirección IP interna, se requiere que la red de VPC contenga al menos una subred.
Solo puedes especificar 500 redes de VPC en todos los niveles de acceso dentro de tu política de acceso.
Cuando borras una red de VPC a la que hace referencia un nivel de acceso o un perímetro de servicio y, luego, vuelves a crear otra red de VPC con el mismo nombre, los Controles del servicio de VPC no habilitan automáticamente las direcciones IP internas en la red de VPC que se volvió a crear. Para superar esta limitación, crea una red de VPC con un nombre diferente y agrégala al perímetro.
No puedes usar una dirección IP interna para permitir el acceso desde los servicios administrados 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 agregues 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 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 el campo vpcNetworkSources de la condición de nivel de acceso básico.
- Nombre de la red de VPC. Debes definir el nombre de la red de VPC 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 campo VpcSubNetwork de VpcNetworkSource debe seguir la especificación de la subred de IP de bloque de CIDR. Puedes usar cualquier rango de direcciones IP que sea un rango IPv4 válido para las subredes.
Usa este nivel de acceso con condiciones de permiso en IngressSource o EgressSource.

A través de una situación de ejemplo, en las siguientes secciones, se explica cómo realizar estos 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 VM en Project1, VM1 y VM2, usan esta red como una interfaz de red para enviar 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 al bucket de Cloud Storage en Project2 mediante una dirección IP interna. Para lograr esta configuración, debes seguir estos pasos:

Creas un perímetro de servicio sp1 alrededor de Project1 y otro perímetro de servicio sp2 alrededor de Project2.
Luego, puedes agregar reglas de entrada y salida a los perímetros de servicio para permitir que solo la subred de VM1 acceda al bucket de Cloud Storage.

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 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 una política de acceso a nivel de la organización.
Obtén el nombre de tu política de acceso.
Para establecer esta política como tu política de acceso predeterminada, ejecuta el siguiente 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 Configura 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 de Project1, 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
```
Reemplaza lo siguiente:
- PROJECT_NUMBER: 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 de Project2 que restrinja 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 del proyecto de Cloud Storage. 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.

Después de crear estos dos perímetros, ya no se puede acceder al bucket de Cloud Storage desde las dos VM.

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. En el siguiente ejemplo, solo se muestran los atributos que necesitas 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 en la que reside el 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 que se explicaron anteriormente.

Para obtener más información sobre el archivo YAML, consulta Archivo YAML basic-level-spec.
Para crear un nivel de acceso con el archivo YAML, ejecuta el siguiente 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 las condiciones de acceso del nivel de acceso. Por ejemplo, level.yaml
Para obtener más información, consulta Crea un nivel de acceso básico.

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 el perímetro sp2 a fin de permitir que el tráfico de la API de Cloud Storage ingrese al 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
```
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 la referencia de las reglas de entrada.
Para actualizar la política de entrada de un perímetro de servicio, ejecuta el siguiente 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 el proyecto de Cloud Storage. Por ejemplo, sp2
- FILE_NAME: Es el archivo YAML que define tu política de entrada. Por ejemplo, ingress.yaml.
Si deseas obtener más información, consulta Actualiza las políticas de entrada y salida para 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 de 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 establecer el campo sourceRestriction como SOURCE_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
```
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 la referencia de las 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
```
Reemplaza lo siguiente:
- PERIMETER: Es el nombre del perímetro de servicio que protege el proyecto host de red. Por ejemplo, sp1
- FILE_NAME: Es el archivo YAML que define tu política de salida. Por ejemplo, egress.yaml.
Si deseas obtener más información, consulta Actualiza las políticas de entrada y salida para un perímetro de servicio.

Después de configurar las políticas de entrada y salida, se puede acceder al bucket de Cloud Storage desde VM1, mientras que no se puede acceder al bucket de Cloud Storage desde VM2.

Recomendaciones

Cuando habilites una dirección IP interna, te recomendamos que inhabilites el reenvío de IP para tus VM. El reenvío de IP permite que una VM dentro de la misma red de VPC envíe solicitudes con una dirección IP diferente, lo que implica el riesgo de falsificación de identidad en la dirección IP.
Si deseas habilitar el reenvío de IP, te recomendamos que uses las siguientes opciones de configuración para reducir el riesgo de falsificación de identidad de direcciones IP:
- Usa la restricción de la política de la organización Restrict VM IP Forwarding (constraints/compute.vmCanIpForward) para garantizar que solo las VM autorizadas puedan habilitar el reenvío de IP.
- Usa fuentes para las reglas de firewall para restringir las direcciones IP que se pueden comunicar con las VM que tienen habilitado el reenvío de IP. Realice las siguientes tareas:
  - Configura reglas de firewall de entrada para permitir el tráfico entrante solo desde un rango de direcciones IP específico a las VM que tengan 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 específico desde las VM que tienen habilitado el reenvío de IP.