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

Configura un perímetro de Controles del servicio de VPC para una red de nube privada virtual

Obtén información para configurar un perímetro de servicio con los Controles del servicio de VPC. En este instructivo, se usa la configuración de red, como firewalls, Private Service Connect y configuraciones de DNS que son necesarias para usar un perímetro de Controles del servicio de VPC de manera eficaz. Luego, en este instructivo, se muestra cómo se permiten o se rechazan los servicios y cómo hacer excepciones detalladas para una lista de entidades permitidas de servicios específicos.

Objetivos

Configura un perímetro de Controles del servicio de VPC con controles de red adicionales para mitigar las rutas de robo de datos.
Permite o niega el acceso a los servicios dentro del perímetro desde solicitudes que se originan dentro o fuera del perímetro.
Permitir o denegar el acceso a servicios fuera del perímetro desde solicitudes que se originan dentro del perímetro
Usa la política de la organización Restringir el uso de servicios del recurso y los Controles del servicio de VPC en conjunto.

Costos

En este instructivo, se usan los siguientes componentes facturables de Google Cloud:

Para generar una estimación de costos en función del uso previsto, usa la calculadora de precios.

Cuando finalices este instructivo, puedes borrar los recursos creados para evitar que se te siga facturando. Para obtener más información, consulta Cómo realizar una limpieza.

Antes de comenzar

Para este instructivo, se requiere un proyecto de tu organización. Si aún no tienes una organización de Google Cloud, consulta Cómo crear y administrar una organización.
In the Google Cloud console, on the project selector page, select or create a Google Cloud project.

Note: If you don't plan to keep the resources that you create in this procedure, create a project instead of selecting an existing project. After you finish these steps, you can delete the project, removing all resources associated with the project.

Go to project selector
Make sure that billing is enabled for your Google Cloud project.
Enable the Compute Engine, Access Context Manager, and Cloud DNS APIs.
Enable the APIs
In the Google Cloud console, activate Cloud Shell.

Activate Cloud Shell
Make sure that you have the following role or roles on the organization: Access Context Manager Admin, Organization Policy Administrator
Check for the roles
1. In the Google Cloud console, go to the IAM page.
  Go to IAM
2. Select the organization.
3. In the Principal column, find all rows that identify you or a group that you're included in. To learn which groups you're included in, contact your administrator.
4. For all rows that specify or include you, check the Role colunn to see whether the list of roles includes the required roles.
Grant the roles
1. In the Google Cloud console, go to the IAM page.
  Ir a IAM
2. Selecciona la organización.
3. Haz clic en Grant access.
4. En el campo Principales nuevas, ingresa tu identificador de usuario. Esta suele ser la dirección de correo electrónico de una Cuenta de Google.
5. En la lista Seleccionar un rol, elige un rol.
6. Para otorgar funciones adicionales, haz clic en Agregar otro rol y agrega cada rol adicional.
7. Haz clic en Guardar.
8. Make sure that you have the following role or roles on the project: Compute Admin, DNS Administrator, IAP-Secured Tunnel User, Service Account User, Service Directory Editor
  Check for the roles
  1. In the Google Cloud console, go to the IAM page.
    Go to IAM
  2. Select the project.
  3. In the Principal column, find all rows that identify you or a group that you're included in. To learn which groups you're included in, contact your administrator.
  4. For all rows that specify or include you, check the Role colunn to see whether the list of roles includes the required roles.
  Grant the roles
  1. In the Google Cloud console, go to the IAM page.
    Ir a IAM
  2. Selecciona el proyecto.
  3. Haz clic en Grant access.
  4. En el campo Principales nuevas, ingresa tu identificador de usuario. Esta suele ser la dirección de correo electrónico de una Cuenta de Google.
  5. En la lista Seleccionar un rol, elige un rol.
  6. Para otorgar funciones adicionales, haz clic en Agregar otro rol y agrega cada rol adicional.
  7. Haz clic en Guardar.
  Configura el perímetro de los Controles del servicio de VPC
  
  Para implementar un perímetro de Controles del servicio de VPC para una red de VPC, debes implementar controles de red que nieguen el tráfico a servicios externos. En las siguientes secciones, se detallan las configuraciones de red que debes implementar en las redes de VPC dentro de tu perímetro y un ejemplo de configuración de perímetro.
  
  Prepara tu red de VPC
  
  En esta sección, configurarás la conectividad privada a los servicios y las APIs de Google para tu red de VPC para mitigar una variedad de rutas de salida de red a Internet.
  1. En Cloud Shell, configura las siguientes variables:
    
    gcloud config set project PROJECT_ID gcloud config set compute/region REGION gcloud config set compute/zone ZONE
    
    Reemplaza lo siguiente:
    
    PROJECT_ID: Es el ID del proyecto en el que crearás los recursos.
    
    REGION: Una región que esté cerca de tu ubicación, por ejemplo, us-central1
    
    ZONE: Una zona que esté cerca de tu ubicación, por ejemplo, us-central1-a
  2. Crea una red de VPC y una subred con el Acceso privado a Google habilitado:
    
    gcloud compute networks create restricted-vpc --subnet-mode=custom gcloud compute networks subnets create restricted-subnet \ --range=10.0.0.0/24 \ --network=restricted-vpc \ --enable-private-ip-google-access
  3. Crea un extremo de Private Service Connect y una regla de reenvío configurada para usar el paquete vpc-sc:
    
    gcloud compute addresses create restricted-psc-endpoint \ --global \ --purpose=PRIVATE_SERVICE_CONNECT \ --addresses=10.0.1.1 \ --network=restricted-vpc gcloud compute forwarding-rules create restrictedpsc \ --global \ --network=restricted-vpc \ --address=restricted-psc-endpoint \ --target-google-apis-bundle=vpc-sc
  4. Configura la política del servidor Cloud DNS para redireccionar las consultas de las APIs de Google Cloud a tu extremo de Private Service Connect:
    
    gcloud dns managed-zones create restricted-dns-zone \ --description="Private DNS Zone to map Google API queries to the Private Service Connect endpoint for Google APIs" \ --dns-name="googleapis.com." \ --networks=restricted-vpc \ --visibility=private gcloud dns record-sets create googleapis.com \ --rrdatas=10.0.1.1 \ --type=A \ --ttl=300 \ --zone=restricted-dns-zone gcloud dns record-sets create *.googleapis.com \ --rrdatas="googleapis.com." \ --type=CNAME \ --ttl=300 \ --zone=restricted-dns-zone
  5. Configura una regla de firewall con una prioridad baja para denegar todo el tráfico de salida:
    
    gcloud compute firewall-rules create deny-all-egress \ --priority=65534 \ --direction=egress \ --network=restricted-vpc \ --action=DENY \ --rules=all \ --destination-ranges=0.0.0.0/0
  6. Configura una regla de firewall con una prioridad más alta para permitir que el tráfico llegue a la dirección IP que usa tu extremo de Private Service Connect:
    
    gcloud compute firewall-rules create allow-psc-for-google-apis \ --priority=1000 \ --direction=egress \ --network=restricted-vpc \ --action=ALLOW \ --rules=tcp:443 \ --destination-ranges=10.0.1.1
    
    Estas reglas de firewall deniegan la salida de forma amplia, antes de permitir la salida de forma selectiva al extremo de Private Service Connect. Esta configuración rechaza el tráfico de salida a los dominios predeterminados a los que normalmente se puede acceder de forma predeterminada con el Acceso privado a Google y las reglas de firewall implícitas.
  Crea un perímetro de Controles del servicio de VPC
  
  En esta sección, crearás un perímetro de Controles del servicio de VPC.
  
  Nota: En este instructivo, se implementa un perímetro aplicado porque no hay recursos de producción dentro del perímetro. Si agregas un perímetro a proyectos de producción existentes, te recomendamos que realices pruebas con el modo de prueba preliminar antes de aplicarlo.
  1. En Cloud Shell, crea una política de acceso como requisito para crear un perímetro de Controles del servicio de VPC:
    
    gcloud access-context-manager policies create \ --organization=ORGANIZATION_ID --title "Access policy at organization node"
    
    El resultado es similar a este:
    
    "Create request issued Waiting for operation [operations/accessPolicies/123456789/create/123456789] to complete...done."
    
    Solo puede haber un contenedor de políticas de acceso en el nodo de la organización. Si ya se creó una política en tu organización, el resultado es similar al siguiente:
    
    "ALREADY_EXISTS: Policy already exists with parent ContainerKey{containerId=organizations/123456789012, numericId=123456789012}"
    
    Si ves este mensaje, continúa con el siguiente paso.
  2. Crea un perímetro de Controles del servicio de VPC que restrinja los servicios de Cloud Storage y Compute Engine.
    
    export POLICY_ID=$(gcloud access-context-manager policies list \ --organization=ORGANIZATION_ID \ --format="value(name)") gcloud access-context-manager perimeters create demo_perimeter \ --title="demo_perimeter" \ --resources=projects/$(gcloud projects describe PROJECT_ID --format="value(projectNumber)") \ --restricted-services="storage.googleapis.com,compute.googleapis.com" \ --enable-vpc-accessible-services \ --policy=$POLICY_ID \ --vpc-allowed-services="RESTRICTED-SERVICES"
    
    Precaución: En este instructivo, solo restringirás los servicios de Compute Engine y Cloud Storage. En un perímetro de producción, te recomendamos que restringas todos los servicios compatibles para mitigar una variedad de rutas de robo de datos.
    El perímetro de muestra configura la marca --vpc-allowed-services con el valor de alias RESTRICTED-SERVICES para permitir el tráfico de esta VPC al mismo conjunto de servicios que defines con la marca --restricted-services.
  Verifica los servicios permitidos desde el tráfico fuera de tu perímetro
  
  En las siguientes secciones, se muestra cómo el perímetro de los Controles del servicio de VPC permite o niega el acceso a las solicitudes que se realizan desde fuera del perímetro y cómo puedes permitir de forma selectiva la entrada a los servicios configurando niveles de acceso y políticas de entrada.
  
  Para simular el tráfico desde fuera de tu perímetro, puedes ejecutar comandos en Cloud Shell. Cloud Shell es un recurso fuera de tu proyecto y perímetro. El perímetro permite o rechaza las solicitudes, aunque estas tengan suficientes privilegios de Identity and Access Management para que se realicen correctamente.
  
  En este instructivo, se usan la API de Compute Engine, Cloud Storage y Cloud Resource Manager, pero los mismos conceptos también se aplican a otros servicios.
  
  Verifica que el perímetro niegue el tráfico externo a los servicios restringidos
  
  En esta sección, verificarás que el perímetro niegue el tráfico externo a los servicios restringidos.
  
  En el diagrama anterior, se muestra cómo se le niega el acceso a un cliente autorizado a los servicios dentro del perímetro que configuraste como restringido, pero se le permite el acceso a los servicios que no configuraste como restringidos.
  
  En los siguientes pasos, verificarás este concepto con Cloud Shell para intentar crear una VM dentro de tu red de VPC, que fallará debido a la configuración del perímetro de los Controles del servicio de VPC.
  1. En Cloud Shell, ejecuta el siguiente comando para crear una VM dentro de tu red de VPC.
    
    gcloud compute instances create demo-vm \ --machine-type=e2-micro \ --subnet=restricted-subnet \ --scopes=https://www.googleapis.com/auth/cloud-platform \ --no-address
    
    El resultado es similar a este:
    
    "ERROR: (gcloud.compute.instances.create) Could not fetch resource: - Request is prohibited by organization's policy."
    
    La solicitud falla porque Cloud Shell está fuera de tu perímetro y Compute Engine está configurado con la marca --restricted-services.
  2. En Cloud Shell, ejecuta el siguiente comando para acceder al servicio de Resource Manager, que no está configurado en la marca --restricted-services.
    
    gcloud projects describe PROJECT_ID
    
    Una respuesta correcta muestra los detalles de tu proyecto. Esta respuesta demuestra que tu perímetro permite el tráfico externo a la API de Cloud Resource Manager.
    
    Demostraste que el perímetro niega el tráfico externo a los servicios configurados en --restricted-services y permite el tráfico externo a los servicios que no se configuraron de forma explícita en --restricted-services.
  En las siguientes secciones, se presentan patrones de excepción para llegar a servicios restringidos dentro del perímetro.
  
  Verifica que un nivel de acceso permita una excepción al perímetro
  
  En esta sección, debes verificar que un nivel de acceso permita una excepción al perímetro. Un nivel de acceso es útil cuando deseas crear una excepción para que el tráfico externo acceda a todos los servicios restringidos dentro del perímetro y no necesitas excepciones detalladas para cada servicio o para otros atributos.
  
  En el diagrama anterior, se ilustra cómo un nivel de acceso permite que un cliente autorizado acceda a todos los servicios restringidos dentro del perímetro.
  
  En los siguientes pasos, verificarás este concepto creando un nivel de acceso y, luego, realizando una solicitud correcta al servicio de Compute Engine. Esta solicitud se permite incluso si configuraste Compute Engine como restringido.
  1. En Cloud Shell, crea un archivo YAML que describa la configuración de un nivel de acceso y aplícalo a tu perímetro. En este ejemplo, se crea un nivel de acceso para la identidad de usuario que estás usando para ejecutar el instructivo.
    
    export USERNAME=$(gcloud config list account --format "value(core.account)") cat <<EOF > user_spec.yaml - members: - user:$USERNAME EOF
    
    gcloud access-context-manager levels create single_user_level \ --title="single-user access level" \ --basic-level-spec=user_spec.yaml \ --policy=$POLICY_ID gcloud access-context-manager perimeters update demo_perimeter \ --add-access-levels=single_user_level \ --policy=$POLICY_ID
  2. Desde Cloud Shell, vuelve a ejecutar el siguiente comando para intentar crear una VM:
    
    gcloud compute instances create demo-vm \ --machine-type=e2-micro \ --subnet=restricted-subnet \ --scopes=https://www.googleapis.com/auth/cloud-platform \ --no-address
    
    Esta vez, la solicitud funciona. Tu perímetro evita que el tráfico externo use los servicios restringidos, pero el nivel de acceso que configuraste permite una excepción.
    
    Nota: Después de actualizar un perímetro de servicio, los cambios pueden tardar un tiempo en propagarse y surtir efecto. Si recibes un resultado inesperado, espera un minuto y vuelve a intentarlo después de que el perímetro se haya actualizado por completo.
  Verifica que una política de entrada permita una excepción detallada al perímetro
  
  En esta sección, verificarás que una política de entrada permita una excepción detallada al perímetro. En comparación con el nivel de acceso detallado, una política de entrada detallada puede configurar atributos adicionales sobre la fuente de tráfico y permitir el acceso a servicios o métodos individuales.
  
  En el diagrama anterior, se ilustra cómo una política de entrada permite que un cliente autorizado acceda solo a un servicio especificado dentro del perímetro, sin permitir el acceso a otros servicios restringidos.
  
  En los siguientes pasos, verificarás este concepto reemplazando el nivel de acceso por una política de entrada que le permita a un cliente autorizado acceder solo al servicio de Compute Engine, pero no a otros servicios restringidos.
  1. En la pestaña Cloud Shell, ejecuta el siguiente comando para quitar el nivel de acceso.
    
    gcloud access-context-manager perimeters update demo_perimeter \ --policy=$POLICY_ID \ --clear-access-levels
  2. En la pestaña Cloud Shell, crea una política de entrada que permita que la identidad de tu usuario ingrese solo al servicio de Compute Engine y aplica la política a tu perímetro.
    
    cat <<EOF > ingress_spec.yaml - ingressFrom: identities: - user:$USERNAME sources: - accessLevel: '*' ingressTo: operations: - methodSelectors: - method: '*' serviceName: compute.googleapis.com resources: - '*' EOF
    
    gcloud access-context-manager perimeters update demo_perimeter \ --set-ingress-policies=ingress_spec.yaml \ --policy=$POLICY_ID
  3. En la pestaña Cloud Shell, ejecuta el siguiente comando para crear un bucket de Cloud Storage dentro del perímetro.
    
    gcloud storage buckets create gs://PROJECT_ID-01
    
    El resultado es similar a este:
    
    "ERROR: (gcloud.storage.buckets.create) HTTPError 403: Request is prohibited by organization's policy."
    
    Cloud Shell es un cliente fuera del perímetro, por lo que el perímetro de los Controles del servicio de VPC bloquea que Cloud Shell se comunique con servicios restringidos dentro del perímetro.
  4. En la pestaña Cloud Shell, ejecuta el siguiente comando para realizar una solicitud al servicio de Compute Engine dentro del perímetro.
    
    gcloud compute instances describe demo-vm --zone=ZONE
    
    Una respuesta correcta muestra los detalles de demo-vm. Esta respuesta demuestra que tu perímetro permite el tráfico externo que cumple con las condiciones de tu política de entrada al servicio de Compute Engine.
  Verifica los servicios permitidos desde el tráfico dentro de tu perímetro
  
  En las siguientes secciones, se muestra cómo el perímetro de los Controles del servicio de VPC permite o rechaza solicitudes a servicios desde el interior del perímetro y cómo puedes permitir de forma selectiva la salida a servicios externos mediante políticas de salida.
  
  Para demostrar la diferencia entre el tráfico dentro y fuera del perímetro, en las siguientes secciones, se usa Cloud Shell fuera del perímetro y una instancia de Compute Engine que creas dentro del perímetro. Los comandos que ejecutas desde la sesión de SSH en la instancia de Compute Engine dentro del perímetro usan la identidad de la cuenta de servicio adjunta, mientras que los comandos que se ejecutan desde Cloud Shell fuera del perímetro usan tu propia identidad. Cuando sigues la configuración recomendada para el instructivo, el perímetro permite o rechaza solicitudes, a pesar de que estas tengan privilegios de IAM suficientes para tener éxito.
  
  En este instructivo, se usan la API de Compute Engine, Cloud Storage y Cloud Resource Manager, pero los mismos conceptos también se aplican a otros servicios.
  
  Verifica que el perímetro permita el tráfico interno a los servicios restringidos dentro del perímetro
  
  En esta sección, verificas que el perímetro permita el tráfico de extremos de red dentro de tu perímetro si el servicio también está configurado en servicios accesibles de VPC.
  
  En el diagrama anterior, se muestra cómo un perímetro permite que el tráfico de los extremos de red dentro del perímetro llegue a los servicios restringidos que también configuraste como servicios accesibles de VPC. No se puede acceder a los servicios que no configuraste como servicios accesibles de VPC desde los extremos de red dentro del perímetro.
  
  En los siguientes pasos, verificarás este concepto estableciendo una conexión SSH a la instancia de Compute Engine dentro del perímetro y, luego, realizando solicitudes a los servicios.
  1. En Cloud Shell, crea una regla de firewall que permita el tráfico de SSH a tu red de VPC. Para ello, permite la entrada desde el rango de direcciones IP 35.235.240.0/20 que usa el servicio IAP para el reenvío de TCP:
    
    gcloud compute firewall-rules create demo-allow-ssh \ --direction=INGRESS \ --priority=1000 \ --network=restricted-vpc \ --action=ALLOW \ --rules=tcp:22 \ --source-ranges=35.235.240.0/20
  2. Inicia una sesión SSH para esta instancia:
    
    gcloud compute ssh demo-vm --zone=ZONE
    
    Verifica que te hayas conectado correctamente a la instancia demo-vm mediante la confirmación de que la línea de comandos cambió para mostrar el nombre de host de tu instancia:
    
    username@demo-vm:~$
    
    Si el comando anterior falla, es posible que veas un mensaje de error similar al siguiente:
    
    "[/usr/bin/ssh] exited with return code [255]"
    
    En este caso, es posible que la instancia de Compute Engine no haya completado el arranque. Espera un minuto y vuelve a intentarlo.
  3. Desde la sesión SSH dentro de tu perímetro, verifica los servicios que permite tu perímetro de forma interna con un servicio de Google Cloud que esté configurado en la lista de entidades permitidas de servicios accesibles de VPC. Por ejemplo, prueba cualquier comando con el servicio de Compute Engine.
    
    gcloud compute instances describe demo-vm --zone=ZONE
    
    Una respuesta correcta muestra los detalles de demo-vm. Esta respuesta demuestra que tu perímetro permite el tráfico interno a la API de Compute Engine.
  4. Desde la sesión SSH dentro de tu perímetro, verifica que los servicios que no se incluyen en la lista de entidades permitidas de servicios accesibles de VPC no se permitan desde tu VM. Por ejemplo, el siguiente comando usa el servicio de Resource Manager, que no está configurado en la lista de entidades permitidas de servicios accesibles de VPC.
    
    gcloud projects describe PROJECT_ID
    
    El resultado es similar a este:
    
    "ERROR: (gcloud.projects.list) PERMISSION_DENIED: Request is prohibited by organization's policy."
    
    Tu instancia de Compute Engine y otros extremos de red solo pueden solicitar servicios que estén configurados en la lista de entidades permitidas de servicios accesibles de VPC. Sin embargo, los recursos sin servidores o el tráfico de servicio que se origine fuera de tu perímetro pueden solicitar ese servicio. Si quieres evitar que se use un servicio en tu proyecto, consulta la política de Uso de recursos de servicios restringidos.
  Verifica que el perímetro niegue el tráfico interno a los servicios restringidos fuera del perímetro
  
  En esta sección, verificarás que el perímetro bloquee la comunicación de los servicios dentro del perímetro a los servicios de Google Cloud fuera del perímetro.
  
  En el diagrama anterior, se ilustra cómo el tráfico interno no puede comunicarse con los servicios restringidos fuera del perímetro.
  
  En los siguientes pasos, verificarás este concepto intentando enviar tráfico interno a un servicio restringido dentro del perímetro y a un servicio restringido fuera del perímetro.
  1. Desde la sesión de SSH dentro de tu perímetro, ejecuta el siguiente comando para crear un bucket de almacenamiento dentro de tu perímetro. Este comando funciona porque el servicio de Cloud Storage está configurado en restricted-services y accessible-services.
    
    gcloud storage buckets create gs://PROJECT_ID-02
    
    Una respuesta correcta crea el bucket de almacenamiento. Esta respuesta demuestra que tu perímetro permite el tráfico interno al servicio de Cloud Storage.
  2. Desde la sesión de SSH dentro de tu perímetro, ejecuta el siguiente comando para leer desde un bucket que está fuera de tu perímetro. Este bucket público permite el permiso de solo lectura a allUsers, pero el perímetro niega el tráfico desde el interior del perímetro a un servicio restringido fuera del perímetro.
    
    gcloud storage cat gs://solutions-public-assets/vpcsc-tutorial/helloworld.txt
    
    El resultado es similar a este:
    
    "ERROR: (gcloud.storage.objects.describe) HTTPError 403: Request is prohibited by organization's policy."
    
    Esta respuesta demuestra que puedes usar servicios restringidos dentro del perímetro, pero un recurso dentro del perímetro no puede comunicarse con servicios restringidos fuera del perímetro.
  Verifica que una política de salida permita una excepción al perímetro
  
  En esta sección, verificarás que una política de salida permita una excepción al perímetro.
  
  En el diagrama anterior, se muestra cómo el tráfico interno puede comunicarse con un recurso externo específico cuando otorgas una excepción limitada con la política de salida.
  
  En los siguientes pasos, verificarás este concepto creando una política de salida y, luego, accediendo a un bucket público de Cloud Storage fuera del perímetro permitido por la política de salida.
  1. Para abrir una sesión nueva de Cloud Shell, haz clic en Abrir una pestaña nueva en Cloud Shell. En los pasos posteriores, alternarás entre la primera pestaña con la sesión SSH dentro de tu perímetro y la segunda pestaña en Cloud Shell fuera de tu perímetro, donde el mensaje de la línea de comandos comienza con username@cloudshell.
  2. En la pestaña Cloud Shell, crea una política de salida que permita la salida de la identidad de la cuenta de servicio adjunta de demo-vm con el método google.storage.objects.get a un bucket público en un proyecto externo. Actualiza el perímetro con la política de salida.
    
    export POLICY_ID=$(gcloud access-context-manager policies list \ --organization=ORGANIZATION_ID \ --format="value(name)") export SERVICE_ACCOUNT_EMAIL=$(gcloud compute instances describe demo-vm \ --zone=ZONE) \ --format="value(serviceAccounts.email)"
    
    cat <<EOF > egress_spec.yaml - egressFrom: identities: - serviceAccount:$SERVICE_ACCOUNT_EMAIL egressTo: operations: - methodSelectors: - method: 'google.storage.objects.get' serviceName: storage.googleapis.com resources: - projects/950403849117 EOF
    
    gcloud access-context-manager perimeters update demo_perimeter \ --set-egress-policies=egress_spec.yaml \ --policy=$POLICY_ID
  3. Regresa a la pestaña con la sesión de SSH a la VM dentro de tu perímetro, donde el mensaje de la línea de comandos comienza con username@demo-vm.
  4. Desde la sesión de SSH dentro de tu perímetro, realiza otra solicitud al bucket de Cloud Storage y verifica que funcione.
    
    gcloud storage cat gs://solutions-public-assets/vpcsc-tutorial/helloworld.txt
    
    El resultado es similar a este:
    
    "Hello world! This is a sample file in Cloud Storage that is viewable to allUsers."
    
    Esta respuesta demuestra que tu política de perímetro y salida permite el tráfico interno de una identidad específica a un bucket de Cloud Storage específico.
    
    Nota: Después de actualizar un perímetro de servicio, los cambios pueden tardar un tiempo en propagarse y surtir efecto. Si recibes un resultado inesperado, espera un minuto y vuelve a intentarlo después de que el perímetro se haya actualizado por completo.
  5. Desde la sesión de SSH dentro de tu perímetro, también puedes probar otros métodos que la excepción de la política de salida no permitía de forma explícita. Por ejemplo, el siguiente comando requiere el permiso google.storage.buckets.list, que tu perímetro rechaza.
    
    gcloud storage ls gs://solutions-public-assets/vpcsc-tutorial/*
    
    El resultado es similar a este:
    
    "ERROR: (gcloud.storage.cp) Request is prohibited by organization's policy."
    
    Esta respuesta demuestra que tu perímetro niega el tráfico interno de la lista de objetos en el bucket externo, lo que indica que la política de salida permite de forma limitada los métodos especificados de forma explícita.
  Para obtener más referencias sobre patrones comunes para compartir datos fuera del perímetro de tu servicio, consulta Intercambio seguro de datos con reglas de entrada y salida.
  
  Configura la política de uso de recursos de servicios restringidos (opcional)
  
  También es posible que tengas requisitos internos o de cumplimiento para permitir que solo se usen APIs aprobadas de forma individual en tu entorno. En este caso, también puedes configurar el servicio de la política de la organización Uso de recursos de servicios restringidos. Cuando aplicas la política de la organización en un proyecto, restringes los servicios que se pueden crear en ese proyecto. Sin embargo, la política de la organización no evita que los servicios de este proyecto se comuniquen con los servicios de otros proyectos. En comparación, los Controles del servicio de VPC te permiten definir un perímetro para evitar la comunicación con servicios fuera del perímetro.
  
  Por ejemplo, si defines una política de la organización para permitir Compute Engine y rechazar Cloud Storage en tu proyecto, una VM de este proyecto no podría crear un bucket de Cloud Storage en tu proyecto. Sin embargo, la VM puede realizar solicitudes a un bucket de Cloud Storage en otro proyecto, por lo que el robo con el servicio de Cloud Storage aún es posible. En los siguientes pasos, se muestra cómo implementar y probar esta situación:
  1. Cambia a la pestaña de Cloud Shell, donde el mensaje de la línea de comandos comienza con username@cloudshell.
  2. En la pestaña Cloud Shell, crea un archivo YAML que describa el servicio de políticas de la organización que solo permitirá el uso del servicio de Compute Engine y rechazará todos los demás servicios, y, luego, aplícalo a tu proyecto.
    
    cat <<EOF > allowed_services_policy.yaml constraint: constraints/gcp.restrictServiceUsage listPolicy: allowedValues: - compute.googleapis.com inheritFromParent: true EOF
    
    gcloud resource-manager org-policies set-policy allowed_services_policy.yaml \ --project=PROJECT_ID
  3. Regresa a la pestaña con la sesión de SSH a la VM dentro de tu perímetro, donde el mensaje de la línea de comandos comienza con username@demo-vm.
  4. Desde la sesión de SSH dentro de tu perímetro, ejecuta el siguiente comando para ver el mismo bucket de almacenamiento que creaste anteriormente en este proyecto.
    
    gcloud storage buckets describe gs://PROJECT_ID
    
    El resultado es similar a este:
    
    "ERROR: (gcloud.storage.buckets.create) HTTPError 403: Request is disallowed by organization's constraints/gcp.restrictServiceUsage constraint for 'projects/123456789' attempting to use service 'storage.googleapis.com'."
    
    Esta respuesta demuestra que el servicio de la política de la organización niega el servicio de Cloud Storage dentro de tu proyecto, independientemente de la configuración de tu perímetro.
    
    Nota: Después de actualizar un servicio de políticas de la organización, los cambios pueden tardar un tiempo en propagarse y surtir efecto. Si recibes un resultado inesperado, espera un minuto y vuelve a intentarlo después de que el perímetro se haya actualizado por completo.
  5. Desde la sesión de SSH dentro de tu perímetro, ejecuta el siguiente comando para ver un bucket de almacenamiento fuera del perímetro que permita tu política de salida.
    
    gcloud storage cat gs://solutions-public-assets/vpcsc-tutorial/helloworld.txt
    
    El resultado es similar a este:
    
    "Hello world! This is a sample file in Cloud Storage that is viewable to allUsers."
    
    Una respuesta correcta muestra el contenido de helloworld.txt en el bucket de almacenamiento externo. Esta respuesta demuestra que tu perímetro y política de salida permiten que el tráfico interno llegue a un bucket de almacenamiento externo en determinadas condiciones limitadas, pero el servicio de políticas de la organización rechaza el servicio de Cloud Storage en tu proyecto, independientemente de la configuración de tu perímetro. Es posible que los servicios fuera de tu proyecto se sigan usando para la extracción si el perímetro lo permite, independientemente de la política de la organización de uso restringido de los servicios de recursos.
    
    Para denegar la comunicación con Cloud Storage o con otros servicios de Google fuera del perímetro, no es suficiente con la política de la organización Uso restringido de recursos de servicio. Debes configurar un perímetro de Controles del servicio de VPC. Los Controles del servicio de VPC mitigan las rutas de robo de datos, y el Uso restringido de recursos de servicio es un control de cumplimiento para evitar la creación de servicios no aprobados dentro de tu entorno. Usa estos controles juntos para bloquear una variedad de rutas de robo de datos y permitir de forma selectiva servicios aprobados para uso interno en tu entorno.
  Limpia
  Precaución: Borrar un proyecto tiene las siguientes consecuencias:
  
  Se borra todo en el proyecto. Si usaste un proyecto existente para las tareas de este documento, cuando lo borres, también se borrará cualquier otro trabajo que hayas realizado en el proyecto.
  
  Se pierden los ID personalizados de proyectos. Cuando creaste este proyecto, es posible que hayas creado un ID del proyecto personalizado que desees utilizar en el futuro. Para conservar las URL que utilizan el ID del proyecto, como una URL appspot.com, borra los recursos seleccionados dentro del proyecto en lugar de borrar todo el proyecto.
  
  Si planeas explorar varias infraestructuras, instructivos y guías de inicio rápido la reutilización de proyectos puede ayudarte a evitar exceder los límites de las cuotas del proyecto.
  Delete a Google Cloud project:
  gcloud projects delete PROJECT_ID
  Aunque el perímetro de Controles del servicio de VPC no genera ningún costo adicional, debe limpiarse para evitar el desorden y los recursos sin uso en tu organización.
  1. En el selector de proyectos en la parte superior de la consola de Google Cloud, selecciona la organización que usaste durante este instructivo.
  2. En la consola de Google Cloud, ve a la página Controles del servicio de VPC.
    
    Ir a los Controles del servicio de VPC
  3. En la lista de perímetros, selecciona el perímetro que deseas borrar y haz clic en Borrar.
  4. En el cuadro de diálogo, haz clic en Borrar nuevamente para confirmar la eliminación.
  ¿Qué sigue?
  - Obtén información sobre las prácticas recomendadas para habilitar los Controles del servicio de VPC.
  - Obtén más información sobre qué servicios son compatibles con los Controles del servicio de VPC.
  - Obtén más información para habilitar los servicios accesibles de VPC.
  - Lee sobre la configuración de Private Service Connect para acceder a las API de Google.
  - Para obtener más información sobre las arquitecturas de referencia, los diagramas, los instructivos y las prácticas recomendadas, explora el Cloud Architecture Center.

Configura un perímetro de Controles del servicio de VPC para una red de nube privada virtual

Objetivos

Costos

Antes de comenzar

Check for the roles

Grant the roles

Check for the roles

Grant the roles

Configura el perímetro de los Controles del servicio de VPC

Prepara tu red de VPC

Crea un perímetro de Controles del servicio de VPC

Verifica los servicios permitidos desde el tráfico fuera de tu perímetro

Verifica que el perímetro niegue el tráfico externo a los servicios restringidos

Verifica que un nivel de acceso permita una excepción al perímetro

Verifica que una política de entrada permita una excepción detallada al perímetro

Verifica los servicios permitidos desde el tráfico dentro de tu perímetro

Verifica que el perímetro permita el tráfico interno a los servicios restringidos dentro del perímetro

Verifica que el perímetro niegue el tráfico interno a los servicios restringidos fuera del perímetro

Verifica que una política de salida permita una excepción al perímetro

Configura la política de uso de recursos de servicios restringidos (opcional)

Limpia

¿Qué sigue?