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 más información sobre cómo configurar un perímetro de servicio con los Controles del servicio de VPC. Esta usa parámetros de configuración de red, como firewalls, Private Service Connect y los parámetros de configuración de DNS necesarios para usar un perímetro de Controles del servicio de VPC de manera eficaz. Luego, en este instructivo demuestra cómo se permiten o rechazan los servicios y cómo hacer que excepciones de una lista de entidades permitidas de servicios específicos.

Objetivos

Configurar un perímetro de Controles del servicio de VPC con controles de red 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 rechazar acceso a servicios fuera del perímetro desde solicitudes que dentro del perímetro.
Usa la organización Restrict Resource Service Usage política de IAM y los Controles del servicio de VPC.

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 Si aún no tienes una organización de Google Cloud, consulta 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
Asegúrate de que la facturación esté habilitada para tu proyecto de Google Cloud.
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
  
  Si quieres implementar un perímetro de Controles del servicio de VPC en una red de VPC, debes implementar controles de red que nieguen el tráfico a servicios externos. El En las siguientes secciones, se detallan las configuraciones de red que debes implementar en redes de VPC dentro de tu perímetro y una configuración perimetral de ejemplo.
  
  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 lo harás. crear recursos
    
    REGION: Es una región cercana a tu ubicación, por ejemplo, us-central1
    
    ZONE: Es 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 un de reenvío configurada para usar 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 de Cloud DNS para redireccionar las consultas a Google API de Cloud al 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 rechazar 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 entre acceder a la dirección IP que usa tu Private Service Connect extremo:
    
    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 rechazan la salida en forma amplia antes de permitir de manera selectiva la salida a el extremo de Private Service Connect. Esta configuración rechaza el tráfico de salida a los dominios predeterminados a las que normalmente se puede acceder de forma predeterminada con el Acceso privado a Google y el 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: Este este instructivo implementa un perímetro de aplicación forzosa porque no hay recursos dentro del perímetro. Si quieres agregar un perímetro a una red proyectos de producción, te recomendamos que las pruebes modo de ejecución de prueba antes de aplicar la política.
  1. En Cloud Shell, crea una política de acceso como requisito previo para crea 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 un si ya se creó la 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 la 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 servicios de Cloud Storage. En un perímetro de producción, recomendamos lo siguiente: restringes todos los servicios admitidos. 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 definas con el --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 rechaza el acceso a las solicitudes realizadas desde fuera del perímetro y cómo puede permitir de manera selectiva la entrada a servicios políticas de entrada.
  
  Para simular tráfico desde fuera de tu perímetro, puedes ejecutar comandos en Cloud Shell. Cloud Shell es un recurso ajeno al tuyo proyecto y perímetro. El perímetro permite o deniega las solicitudes a pesar de que las solicitudes tienen privilegios suficientes de Identity and Access Management para tener éxito.
  
  En este instructivo, se usan la API de Compute Engine, la API de Cloud Storage y API de Cloud Resource Manager, pero los mismos conceptos también se aplican a otros servicios.
  
  Verifica que el perímetro deniegue tráfico externo a servicios restringidos
  
  En esta sección, verificarás que el perímetro rechace tráfico externo a servicios restringidos.
  
  En el diagrama anterior, se ilustra cómo se deniega el acceso a un cliente autorizado dentro del perímetro que configuraste como restringido, pero el cliente tenga acceso a servicios que no configuraste como restringidos.
  
  En los siguientes pasos, verificarás este concepto con Cloud Shell para un intento de crear una VM en tu red de VPC, que falla 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 la 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 a la Resource Manager, que no se configura en el --restricted-services.
    
    gcloud projects describe PROJECT_ID
    
    Si la respuesta es exitosa, se mostrarán los detalles de tu proyecto. Esta respuesta demuestra que tu perímetro permite el tráfico externo al API de Cloud Resource Manager.
    
    Demostraste que el perímetro rechaza tráfico externo a servicios configurados en --restricted-services y permite tráfico a servicios que no están configurados de forma explícita en --restricted-services.
  En las siguientes secciones, se presentan patrones de excepción para alcanzar servicios dentro del perímetro.
  
  Verifica que un nivel de acceso permita una excepción al perímetro
  
  En esta sección, verificarás que un nivel de acceso permite una excepción al perímetro. Un nivel de acceso es útil cuando quieres a fin de crear una excepción para que el tráfico externo acceda a todos los servicios restringidos dentro del perímetro y no se requieren excepciones detalladas para cada servicio y 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 y hacer una solicitud exitosa al servicio de Compute Engine. Esta la solicitud de permiso, incluso si configuraste Compute Engine como restringido.
  1. En Cloud Shell, crea un archivo YAML que describa la de un nivel de acceso y aplicarla a tu perímetro. Esta crea un nivel de acceso para la identidad de usuario que estás actualmente usar 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. En Cloud Shell, vuelve a ejecutar el siguiente comando para intentar para 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 usar los servicios restringidos, pero el nivel de acceso que configuraste te permite una excepción.
    
    Nota: Después de actualizar un perímetro de servicio, es posible que el los cambios se propaguen y tengan efecto. Si recibes un resultado inesperado, espera Un minuto y vuelve a intentarlo cuando 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 general, un nivel de política de entrada 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 una solicitud cliente 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 con una política de entrada que permita que un cliente autorizado acceda solo al Compute Engine, pero no permite el acceso a otros servicios de Google Cloud.
  1. En la pestaña de 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 de Cloud Shell, crea una política de entrada que permita tu identidad de usuario para ingresar solo para el servicio de Compute Engine y aplicar 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, El perímetro de los Controles del servicio de VPC bloquea 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 de tu política de entrada al servicio de Compute Engine.
  Verifica los servicios permitidos del 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 permite la salida a servicios externos de manera selectiva a través de 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 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. Cuándo siguiendo la configuración recomendada para este instructivo, el perímetro permite o de IAM, incluso si tienen suficientes privilegios de IAM a tener éxito.
  
  En este instructivo, se usan la API de Compute Engine, la API de Cloud Storage y API de 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 servicios restringidos dentro de él
  
  En esta sección, verificarás que el perímetro permita el tráfico de la red dentro del perímetro si el servicio también está configurado en Servicios de VPC accesibles.
  
  En el diagrama anterior, se ilustra cómo un perímetro permite el tráfico de la red extremos dentro del perímetro para alcanzar servicios restringidos que también configurados 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 SSH el tráfico a tu red de VPC permitiendo la entrada desde la IP 35.235.240.0/20 de direcciones IP que usa el IAP para la redirección de TCP servicio:
    
    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, intenta cualquier comando con el servicio de Compute Engine.
    
    gcloud compute instances describe demo-vm --zone=ZONE
    
    Si la respuesta es correcta, se muestran los detalles de demo-vm. Esta respuesta demuestra que tu perímetro permite el tráfico interno al 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 la el servicio Resource Manager, que no está configurado en la VPC accesible de servicios en la lista de entidades permitidas.
    
    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 originan fuera de tu perímetro pueden solicitar ese servicio. Si quieres evitar que un servicio para evitar que se usen en tu proyecto, consulta la Política de Uso de Recursos de Servicios Restringidos.
  Verifica que el perímetro deniegue tráfico interno a servicios restringidos fuera del perímetro
  
  En esta sección, verificarás que el perímetro bloquee la comunicación de dentro del perímetro a los servicios de Google Cloud perímetro de servicio.
  
  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 mensajes internos tráfico a un servicio restringido dentro del perímetro y a un servicio 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 se configuró en restricted-services y accessible-services.
    
    gcloud storage buckets create gs://PROJECT_ID-02
    
    Si la respuesta es correcta, se 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. Esta bucket público otorga permiso de solo lectura a allUsers, pero el perímetro rechaza el tráfico desde tu perímetro hacia un servicio restringido fuera el 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 ilustra cómo el tráfico interno puede comunicarse con un recurso externo específico cuando se otorga una excepción limitada con la política de salida.
  
  En los siguientes pasos, verificarás este concepto mediante la creación de una política de salida acceder a un bucket público de Cloud Storage fuera del perímetro permitidos por la política de salida.
  1. Abre una nueva sesión de Cloud Shell haciendo clic en abre 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 de Cloud Shell, crea una política de salida que permita salida de la identidad de la cuenta de servicio conectada de demo-vm con el google.storage.objects.get a un bucket público en un bucket en un proyecto final. 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. Vuelve a la pestaña con la sesión SSH a la VM dentro de tu perímetro. donde la ventana de línea de comandos comienza con username@demo-vm.
  4. Desde la sesión SSH dentro de tu perímetro, realiza otra solicitud al de 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 cuando el perímetro se haya actualizado por completo.
  5. Desde la sesión SSH dentro de tu perímetro, también puedes probar otros que la excepción a la política de salida no permitió de forma explícita. Para ejemplo, el siguiente comando requiere el elemento google.storage.buckets.list permiso 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 rechaza tráfico interno de una lista de objetos en el bucket externo, lo que indica que la política de salida permite de forma limitada métodos especificados de manera explícita.
  Para obtener más referencias sobre patrones comunes para compartir datos fuera de tu servicio perímetro, consulta intercambio de datos seguro 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 permitir solo APIs aprobadas de forma individual para usar en tu entorno. En este caso, también puedes configurar Uso restringido de recursos de servicios Servicio de políticas de la organización. Cuando aplicas la política de la organización en un proyecto, restringes los servicios que se pueden crear en ese proyecto. Sin embargo, el La política de la organización no impide que los servicios de este proyecto comunicarse con los servicios en 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 hacer solicitudes a un bucket de Cloud Storage en en otro proyecto, por lo que el robo con el servicio de Cloud Storage sigue como sea 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 de Cloud Shell, crea un archivo YAML que describa el de políticas de la organización que solo permitirá el uso de Compute Engine servicio y rechazar todos los demás servicios. Luego, aplicarla 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 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 políticas de la organización rechaza el servicio de Cloud Storage. dentro del proyecto, sin importar la configuración del 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 cuando 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."
    
    Si la respuesta es correcta, se muestra el contenido de helloworld.txt en el bucket de almacenamiento. Esta respuesta demuestra que tu de perímetro y de salida permite que el tráfico interno llegue a un en ciertas condiciones limitadas, pero el Servicio de políticas de la organización servicio de Cloud Storage en tu proyecto, sin importar la configuración de tu perímetro de servicio. Es posible que los servicios fuera de tu proyecto se usen para la extracción si el perímetro lo permite, independientemente de la política de la organización de uso restringido de los recursos de servicio.
    
    Para denegar la comunicación con Cloud Storage o con otros servicios de Google fuera del perímetro, el Uso restringido de recursos de servicios El Servicio de políticas de la organización no es suficiente, debes configurar perímetro de los Controles del servicio de VPC. Los Controles del servicio de VPC mitigan los datos rutas de robo de datos Uso restringido de recursos de servicios es un control de cumplimiento que evita la creación de servicios no aprobados dentro de en un entorno de nube. 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 estas 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.
  Borra un proyecto de Google Cloud:
  gcloud projects delete PROJECT_ID
  Aunque el perímetro de los Controles del servicio de VPC no genera un costo adicional, se debe limpiar para evitar el desorden y los recursos sin usar 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 que quieras 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 los servicios es compatible 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 deniegue tráfico externo a 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 del tráfico dentro de tu perímetro

Verifica que el perímetro permita el tráfico interno a servicios restringidos dentro de él

Verifica que el perímetro deniegue tráfico interno a 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?