1. Introducción
Secure Web Proxy de Google Cloud
Cloud SWP es un servicio centrado en la nube que proporciona un proxy web seguro para ayudarte a proteger el tráfico web de salida (HTTP/S). Configura tus clientes para que usen Cloud SWP de forma explícita como proxy. Las solicitudes web pueden provenir de las siguientes fuentes:
- Instancias de máquina virtual (VM)
- Contenedores
- Un entorno sin servidores que usa un conector sin servidores
- Cargas de trabajo en el intercambio de tráfico entre VPC
- Cargas de trabajo fuera de Google Cloud conectadas por Cloud VPN o Cloud Interconnect
Cloud SWP permite políticas flexibles y detalladas basadas en identidades y aplicaciones web centradas en la nube.
Beneficios
Estos son algunos ejemplos de beneficios que Cloud SWP podría proporcionarle a una organización:
Migración a Google Cloud:
Cloud SWP te ayuda a migrar a Google Cloud y, al mismo tiempo, mantiene tus políticas de seguridad y requisitos existentes para el tráfico web de salida. Puedes evitar usar soluciones de terceros que requieran otra consola de administración o editar manualmente los archivos de configuración.
Acceso a servicios web externos de confianza
Cloud SWP te permite aplicar políticas de acceso detalladas al tráfico web de salida para que puedas proteger tu red. Identifica y crea identidades de aplicaciones o cargas de trabajo y, luego, aplica políticas.
Acceso supervisado a servicios web que no son de confianza
Puedes usar Cloud SWP para proporcionar acceso supervisado a servicios web que no sean de confianza. Cloud SWP identifica el tráfico que no se ajusta a la política y lo registra en Cloud Logging (Logging). Luego, puedes supervisar el uso de Internet, descubrir amenazas a tu red y responder a ellas.
Controles detallados de políticas para APIs de Google
Puedes usar Cloud SWP para proporcionar políticas detalladas para las APIs de Google. Por ejemplo, puedes establecer políticas a nivel de objeto o bucket con Common Expression Language (CEL).
Funciones compatibles
Cloud SWP admite las siguientes funciones:
Servicio de proxy explícito
Los clientes deben configurarse explícitamente para usar el servidor proxy. El proxy de Cloud SWP aísla a los clientes de Internet mediante la creación de nuevas conexiones TCP en nombre del cliente.
Ajuste de escala automático de proxies de Envoy de Cloud SWP
Admite el ajuste automático del tamaño del grupo del proxy de Envoy y la capacidad del grupo en una región, lo que permite un rendimiento coherente durante los períodos de alta demanda al costo más bajo.
Políticas de acceso de salida modulares
Cloud SWP admite específicamente las siguientes políticas de salida:
- Identidad de origen basada en etiquetas seguras, cuentas de servicio o direcciones IP.
- Destinos basados en URLs y nombres de host.
- Solicitudes basadas en métodos, encabezados o URLs. Las URLs se pueden especificar mediante listas, comodines o patrones.
- Encriptación de extremo a extremo: Los túneles de proxy de cliente pueden transitar por TLS. Cloud SWP también admite HTTP/S CONNECT para las conexiones TLS de extremo a extremo iniciadas por el cliente con el servidor de destino.
Integración de Cloud NAT simplificada
Cloud NAT aprovisiona automáticamente direcciones IP públicas adicionales cuando aumenta el conjunto de proxies que entregan tráfico de Cloud SWP.
Las direcciones IP públicas estáticas manuales también son una opción para aquellos que desean tener IP de salida conocidas.
Integración de los Registros de auditoría de Cloud y Google Cloud's operations suite
Los Registros de auditoría de Cloud y Google Cloud's operations suite registran las actividades administrativas y las solicitudes de acceso a los recursos relacionados con Cloud SWP. También registran métricas y registros de transacciones para las solicitudes que maneja el proxy.
Inspección de TLS
El Proxy web seguro ofrece un servicio de inspección de TLS que te permite interceptar el tráfico TLS, inspeccionar la solicitud encriptada y aplicar políticas de seguridad.
- Ofrece una estrecha integración con Certificate Authority Service (CAS), que es un repositorio escalable y con alta disponibilidad para AC privadas.
- La capacidad de usar tu propia raíz de confianza si es necesario. También puedes usar una AC raíz existente para firmar las AC subordinadas que posee CAS. Si lo prefieres, puedes generar un nuevo certificado raíz en CAS.
- Criterios de desencriptación detallados a través del uso de SessionMatcher y ApplicationMatcher en las reglas de la política del Proxy web seguro. Este criterio incluye hosts coincidentes presentes en listas de URL, expresiones regulares, rangos de direcciones IP y expresiones similares. Si es necesario, los criterios se pueden combinar con expresiones booleanas.
- Cada política del Proxy web seguro se puede configurar con su propia política de inspección de TLS y grupo de AC. Como alternativa, varias políticas del Proxy web seguro pueden compartir una sola política de inspección de TLS.
Qué aprenderás
- Cómo implementar y administrar Cloud SWP
Requisitos
- Conocimiento sobre la implementación de instancias y la configuración de componentes de redes
- Conocimiento de la configuración de firewall de VPC
2. Entorno de pruebas
En este codelab, se aprovechará una sola VPC. Un recurso de procesamiento en este entorno saldrá mediante Cloud SWP, como se ve en el siguiente diagrama.
En este lab, tendrás 2 VMs de carga de trabajo.
El Cliente A se configurará para enviar todas las solicitudes HTTP/HTTPS a Cloud SWP.
El cliente B NO estará configurado para enviar solicitudes HTTP/HTTPS de forma explícita al Cloud SWP, sino que aprovechará Cloud NAT para el tráfico vinculado a Internet.
3. Antes de comenzar
El codelab requiere un solo proyecto.
En Cloud Shell, asegúrate de que el ID del proyecto esté configurado
export project_id=`gcloud config list --format="value(core.project)"` export project_number=`gcloud projects describe $project_id --format="value(projectNumber)"` export region=us-west1 export zone=us-west1-a export prefix=codelab-swp export member="serviceAccount:service-$project_number@gcp-sa-networksecurity.iam.gserviceaccount.com"
4. Habilita las APIs
Habilita las APIs para usar los productos
gcloud services enable networksecurity.googleapis.com gcloud services enable certificatemanager.googleapis.com gcloud services enable networkservices.googleapis.com
5. Crear red de VPC, subred y subred de solo proxy
Red de VPC
Crea la VPC de codelab-swp-vpc:
gcloud compute networks create $prefix-vpc --subnet-mode=custom
Subred
Crea las subredes respectivas en la región seleccionada:
gcloud compute networks subnets create $prefix-vpc-subnet \ --range=10.10.10.0/24 --network=$prefix-vpc --region=$region
Subred de solo proxy
Crea una subred de solo proxy en la región seleccionada:
gcloud compute networks subnets create $prefix-proxy-only-subnet --purpose=REGIONAL_MANAGED_PROXY --role=ACTIVE --region=$region --network=$prefix-vpc --range=172.16.0.0/23
6. Crea reglas de firewall
Para permitir que IAP se conecte a tus instancias de VM, crea una regla de firewall que haga lo siguiente:
- Se aplica a todas las instancias de VM a las que deseas que se pueda acceder mediante IAP.
- Permite el tráfico de entrada del rango de IP 35.235.240.0/20. Este rango contiene todas las direcciones IP que IAP usa para el reenvío de TCP.
Desde cloudshell:
gcloud compute firewall-rules create $prefix-allow-iap-proxy \ --direction=INGRESS \ --priority=1000 \ --network=$prefix-vpc \ --action=ALLOW \ --rules=tcp:22 \ --source-ranges=35.235.240.0/20
7. Crea Cloud Router y Cloud NAT
Crea un Cloud Router para Cloud NAT.
gcloud compute routers create ${prefix}-cr \
--region=$region \
--network=${prefix}-vpc
Crea la puerta de enlace de Cloud NAT para el cliente B.
gcloud compute routers nats create $prefix-nat-gw-$region \ --router=$prefix-cr \ --router-region=$region \ --auto-allocate-nat-external-ips \ --nat-all-subnet-ip-ranges
8. Crea una política de seguridad de puerta de enlace
Crea un archivo YAML que contenga información relevante para la política:
cat > /tmp/policy.yaml << EOF
description: Policy to allow .com traffic, then (/index.html), and finally TLS.
name: projects/${project_id}/locations/${region}/gatewaySecurityPolicies/${prefix}-policy
EOF
Ejecuta el comando de gcloud para crear la política a partir del archivo YAML:
gcloud network-security gateway-security-policies import ${prefix}-policy --source=/tmp/policy.yaml --location=${region}
9. Crea una regla de política de seguridad de puerta de enlace
Crea un archivo yaml que contenga las reglas. Estas reglas se representan en Common Expression Language (CEL). En este lab, se utilizará una regla simple que permitirá el tráfico hacia los dominios .com y bloqueará al resto:
cat > /tmp/rule-com.yaml << EOF
name: projects/${project_id}/locations/${region}/gatewaySecurityPolicies/${prefix}-policy/rules/rule-com
enabled: true
priority: 1
description: Allow .com traffic
basicProfile: ALLOW
sessionMatcher: host().endsWith('com')
EOF
Ahora podemos vincular la regla a la política de seguridad de la puerta de enlace:
gcloud network-security gateway-security-policies rules import rule-com --source=/tmp/rule-com.yaml --location=${region} --gateway-security-policy=${prefix}-policy
10. Crea un certificado y súbelo a Cloud Certificate Manager
Crea un certificado para finalizar el tráfico de la carga de trabajo:
openssl req -x509 -newkey rsa:2048 -keyout /tmp/key.pem -out /tmp/cert.pem -days 365 -subj '/CN=www.codelab-swp.com' -nodes -addext \ "subjectAltName = DNS:www.codelab-swp.com"
Sube el certificado al Administrador de certificados de Cloud para que el SWP pueda hacer referencia a él en la política de puerta de enlace de seguridad.
gcloud certificate-manager certificates create ${prefix}-cert --location=${region} --private-key-file=/tmp/key.pem --certificate-file=/tmp/cert.pem
11. Crea la puerta de enlace de SWP
Crea el archivo yaml para que la puerta de enlace de SWP haga referencia a la información anterior, como el certificado, la política de seguridad de la puerta de enlace, la red y la subred.
cat > /tmp/gateway.yaml << EOF
name: projects/${project_id}/locations/${region}/gateways/${prefix}-gateway
type: SECURE_WEB_GATEWAY
addresses: [10.10.10.50]
ports: [443]
certificateUrls: [projects/${project_id}/locations/${region}/certificates/${prefix}-cert]
gatewaySecurityPolicy: projects/${project_id}/locations/${region}/gatewaySecurityPolicies/${prefix}-policy
network: projects/${project_id}/global/networks/${prefix}-vpc
subnetwork: projects/${project_id}/regions/${region}/subnetworks/${prefix}-vpc-subnet
EOF
Crea la puerta de enlace:
gcloud network-services gateways import ${prefix}-swp --source=/tmp/gateway.yaml --location=${region}
Confirma que se haya creado la puerta de enlace:
gcloud network-services gateways describe ${prefix}-swp --location ${region}
12. Crear instancias de procesamiento
Dado que Cloud SWP es un proxy explícito, debemos especificar de forma explícita la IP del proxy para el tráfico de las cargas de trabajo. La instancia de procesamiento clientA tendrá configurada la variable de entorno. El Cliente B no lo hará.
Crea las instancias de procesamiento ClientA y ClientB:
gcloud compute instances create clienta \ --subnet=$prefix-vpc-subnet \ --no-address \ --private-network-ip=10.10.10.10 \ --zone $zone \ --metadata startup-script='#! /bin/bash apt-get update sudo echo http_proxy=https://10.10.10.50:443/ >> /etc/environment sudo echo https_proxy=https://10.10.10.50:443/ >> /etc/environment '
gcloud compute instances create clientb \ --subnet=$prefix-vpc-subnet \ --no-address \ --private-network-ip=10.10.10.200 \ --zone $zone \ --metadata startup-script='#! /bin/bash apt-get update '
13. Prueba de coincidencias de sesiones
Establecer conexión SSH a “clienta” Compute Engine que se creó recientemente. Esta VM tiene la variable de entorno configurada para usar Cloud SWP.
Desde cloudshell:
gcloud compute ssh clienta --zone=$zone --tunnel-through-iap
Ejecuta algunas búsquedas web para validar la funcionalidad. Se requiere –proxy-insecure porque creamos un certificado autofirmado para este lab:
curl https://google.com --proxy-insecure
Resultado esperado:
davidtu@clienta:~$ curl https://google.com --proxy-insecure <HTML><HEAD><meta http-equiv="content-type" content="text/html;charset=utf-8"> <TITLE>301 Moved</TITLE></HEAD><BODY> <H1>301 Moved</H1> The document has moved <A HREF="https://www.google.com/">here</A>. </BODY></HTML>
Como puedes ver, la solicitud se realizó correctamente. Es de esperar que veamos un redireccionamiento 301, ya que el sitio web redirecciona a https://www.google.com.
Si ejecutas el siguiente comando, se proporcionarán registros detallados con detalles sobre la conexión:
curl https://google.com --proxy-insecure -v
Destaca algunos resultados para mostrar los detalles de la conexión del proxy, los certificados y el destino.
davidtu@clienta:~$ curl https://google.com --proxy-insecure -v * Uses proxy env variable https_proxy == 'https://10.10.10.50:443/' * Trying 10.10.10.50:443... * Connected to 10.10.10.50 (10.10.10.50) port 443 (#0) * ALPN, offering http/1.1 * successfully set certificate verify locations: * CAfile: /etc/ssl/certs/ca-certificates.crt * CApath: /etc/ssl/certs * TLSv1.3 (OUT), TLS handshake, Client hello (1): * TLSv1.3 (IN), TLS handshake, Server hello (2): * TLSv1.3 (IN), TLS handshake, Encrypted Extensions (8): * TLSv1.3 (IN), TLS handshake, Certificate (11): * TLSv1.3 (IN), TLS handshake, CERT verify (15): * TLSv1.3 (IN), TLS handshake, Finished (20): * TLSv1.3 (OUT), TLS change cipher, Change cipher spec (1): * TLSv1.3 (OUT), TLS handshake, Finished (20): * SSL connection using TLSv1.3 / TLS_AES_256_GCM_SHA384 * ALPN, server accepted to use http/1.1 * Proxy certificate: * subject: CN=www.codelab-swp.com * start date: Dec 12 17:16:35 2022 GMT * expire date: Dec 12 17:16:35 2023 GMT * issuer: CN=www.codelab-swp.com * SSL certificate verify result: self signed certificate (18), continuing anyway. * allocate connect buffer! * Establish HTTP proxy tunnel to google.com:443 > CONNECT google.com:443 HTTP/1.1 > Host: google.com:443 > User-Agent: curl/7.74.0 > Proxy-Connection: Keep-Alive > * TLSv1.3 (IN), TLS handshake, Newsession Ticket (4): * TLSv1.3 (IN), TLS handshake, Newsession Ticket (4): < HTTP/1.1 200 OK < date: Mon, 12 Dec 2022 19:22:04 GMT < * Proxy replied 200 to CONNECT request * CONNECT phase completed! ...
No dudes en probar otros dominios .com para verificar la funcionalidad.
Ahora probemos otros dominios que no sean .com para verificar el comportamiento de bloqueo predeterminado:
curl https://wikipedia.org --proxy-insecure
Resultado esperado:
curl: (56) Received HTTP code 403 from proxy after CONNECT
Del mismo modo, observa el registro detallado de resultados y confirma que Cloud SWP esté bloqueando este tráfico:
curl https://wikipedia.org --proxy-insecure -v
davidtu@clienta:~$ curl https://wikipedia.org --proxy-insecure -v * Uses proxy env variable https_proxy == 'https://10.10.10.50:443/' * Trying 10.10.10.50:443... * Connected to 10.10.10.50 (10.10.10.50) port 443 (#0) * ALPN, offering http/1.1 * successfully set certificate verify locations: * CAfile: /etc/ssl/certs/ca-certificates.crt * CApath: /etc/ssl/certs * TLSv1.3 (OUT), TLS handshake, Client hello (1): * TLSv1.3 (IN), TLS handshake, Server hello (2): * TLSv1.3 (IN), TLS handshake, Encrypted Extensions (8): * TLSv1.3 (IN), TLS handshake, Certificate (11): * TLSv1.3 (IN), TLS handshake, CERT verify (15): * TLSv1.3 (IN), TLS handshake, Finished (20): * TLSv1.3 (OUT), TLS change cipher, Change cipher spec (1): * TLSv1.3 (OUT), TLS handshake, Finished (20): * SSL connection using TLSv1.3 / TLS_AES_256_GCM_SHA384 * ALPN, server accepted to use http/1.1 * Proxy certificate: * subject: CN=www.codelab-swp.com * start date: Dec 12 17:16:35 2022 GMT * expire date: Dec 12 17:16:35 2023 GMT * issuer: CN=www.codelab-swp.com * SSL certificate verify result: self signed certificate (18), continuing anyway. * allocate connect buffer! * Establish HTTP proxy tunnel to wikipedia.org:443 > CONNECT wikipedia.org:443 HTTP/1.1 > Host: wikipedia.org:443 > User-Agent: curl/7.74.0 > Proxy-Connection: Keep-Alive > * TLSv1.3 (IN), TLS handshake, Newsession Ticket (4): * TLSv1.3 (IN), TLS handshake, Newsession Ticket (4): < HTTP/1.1 403 Forbidden < content-length: 13 < content-type: text/plain < date: Mon, 12 Dec 2022 19:35:09 GMT < connection: close < * Received HTTP code 403 from proxy after CONNECT * CONNECT phase completed! * Closing connection 0 curl: (56) Received HTTP code 403 from proxy after CONNECT
Puedes probar otros dominios también para verificar el comportamiento.
Sal de la sesión SSH en “clienta” e iniciar una nueva conexión SSH a “clientb”.
gcloud compute ssh clientb --zone=$zone --tunnel-through-iap
Ejecuta algunos comandos curl para verificar el comportamiento:
curl https://google.com
Esto debería funcionar como se espera de la VM de clientb:
davidtu@clientb:~$ curl https://google.com <HTML><HEAD><meta http-equiv="content-type" content="text/html;charset=utf-8"> <TITLE>301 Moved</TITLE></HEAD><BODY> <H1>301 Moved</H1> The document has moved <A HREF="https://www.google.com/">here</A>. </BODY></HTML>
Realiza pruebas en el dominio de una organización:
curl https://wikipedia.org
Esto funciona según lo esperado, ya que el clienteb no aprovecha Cloud SWP:
davidtu@clientb:~$ curl https://wikipedia.org <!DOCTYPE HTML PUBLIC "-//IETF//DTD HTML 2.0//EN"> <html><head> <title>301 Moved Permanently</title> </head><body> <h1>Moved Permanently</h1> <p>The document has moved <a href="https://www.wikipedia.org/">here</a>.</p> </body></html>
Prueba enviar tráfico de manera explícita a través de Cloud SWP:
curl -x https://10.10.10.50:443/ https://wikipedia.org --proxy-insecure
Notamos que se rechazó este tráfico a través de la política de Cloud SWP:
davidtu@clientb:~$ curl -x https://10.10.10.50:443/ https://wikipedia.org --proxy-insecure curl: (56) Received HTTP code 403 from proxy after CONNECT
Como verificaste, el tráfico que aprovecha Cloud SWP se aplica de manera forzosa a la política de seguridad configurada. Se permite el tráfico destinado a .com y se rechaza el resto de los destinos.
Sal de clientb.
14. Actualizar una regla de la política de seguridad de la puerta de enlace para ApplicationMatching
Actualicemos la regla para que coincida con los detalles del nivel de la aplicación. Crearemos una regla para observar la ruta de la solicitud y solo la permitiremos si coincide con index.html.
cat > /tmp/rule-com.yaml << EOF
name: projects/${project_id}/locations/${region}/gatewaySecurityPolicies/${prefix}-policy/rules/rule-com
enabled: true
priority: 1
description: Allow .com traffic with path index.html
basicProfile: ALLOW
sessionMatcher: host().endsWith('com')
applicationMatcher: request.path.matches('index.html')
EOF
Ahora podemos vincular la regla actualizada a la política de seguridad de la puerta de enlace:
gcloud network-security gateway-security-policies rules import rule-com --source=/tmp/rule-com.yaml --location=${region} --gateway-security-policy=${prefix}-policy
15. Prueba la regla de ApplicationMatcher
Establece una conexión SSH a la VM de procesamiento de clienta. Esta VM tiene la variable de entorno configurada para usar Cloud SWP.
Desde cloudshell:
gcloud compute ssh clienta --zone=$zone --tunnel-through-iap
Ejecuta algunas búsquedas web para validar la funcionalidad. Se requiere –proxy-insecure porque creamos un certificado autofirmado para este lab:
curl http://google.com --proxy-insecure
Ten en cuenta que esta consulta fallará cuando se haya aprobado anteriormente.
Access denied
Cualquier ruta de solicitud que no sea "index.html" deberían bloquearse con un 403. No dudes en probar esto más a fondo.
Modifica la consulta para que incluya la ruta /index.html
curl http://google.com/index.html --proxy-insecure
Esta solicitud debería completarse correctamente:
davidtu@clienta:~$ curl http://google.com/index.html --proxy-insecure <HTML><HEAD><meta http-equiv="content-type" content="text/html;charset=utf-8"> <TITLE>301 Moved</TITLE></HEAD><BODY> <H1>301 Moved</H1> The document has moved <A HREF="https://www.google.com/index.html">here</A>. </BODY></HTML>
Es de esperar que veamos un redireccionamiento 301, ya que el sitio web redirecciona a http://www.google.com/index.html
Ten en cuenta que se trata de una solicitud HTTP. A continuación, deberás habilitar SWP para tener capacidades de inspección de TLS.
A continuación, ejecuta la misma consulta, pero con TLS:
curl -k https://google.com/index.html --proxy-insecure
Resultado esperado:
curl: (56) Received HTTP code 403 from proxy after CONNECT
Esta solicitud debería fallar, ya que SWP no está configurado para inspeccionar TLS y no puede evaluar la ruta de acceso con la regla applicationMatcher.
Sal de Clenta.
16. Habilita la inspección de TLS
Sin la inspección de TLS, applicationMatcher no coincidirá con el tráfico HTTPS.
"applicationMatcher" permite filtrar los siguientes elementos:
- Mapa de encabezados de solicitud
- Método de solicitud
- Host de la solicitud
- Ruta de la solicitud
- Solicitar consulta
- Esquema de solicitudes
- URL de solicitud completa
- Solicitar usuario-agente
Crear una cuenta de servicio.
Esta cuenta de servicio tendrá permisos para generar certificados para la inspección de SWP TLS.
gcloud beta services identity create \
--service=networksecurity.googleapis.com \
--project=$project_id
Asegúrate de que el CAS esté habilitado
gcloud services enable privateca.googleapis.com
Crear grupo de CA
gcloud privateca pools create $prefix-ca-pool \
--tier=devops \
--project=$project_id \
--location=$region
Crea una AC raíz
CA utilizada para la firma de certificados.
gcloud privateca roots create $prefix-root-ca --pool=$prefix-ca-pool \ --location=$region \ --auto-enable \ --subject="CN=my-swp-ca, O=SWP LLC"
Crea un archivo de política de emisión de certificados
cat > /tmp/tls-issuance-policy.yaml << EOF
maximumLifetime: 1209600s
baselineValues:
caOptions:
isCa: false
keyUsage:
extendedKeyUsage:
serverAuth: true
EOF
Crea un archivo yaml de inspección de TLS
cat > /tmp/tls-inspection-policy.yaml << EOF caPool: projects/$project_id/locations/$region/caPools/$prefix-ca-pool name: projects/$project_id/locations/$region/tlsInspectionPolicies/$prefix-tls-inspection EOF
Crear política de inspección de TLS
gcloud network-security tls-inspection-policies import $prefix-tls-inspection \
--source=/tmp/tls-inspection-policy.yaml \
--location=$region
Actualizar el grupo de AC para usar la política de emisión de certificados
gcloud privateca pools update $prefix-ca-pool --issuance-policy=/tmp/tls-issuance-policy.yaml --location=$region
Otorgar permisos
Esto permite que tu cuenta de servicio use el grupo de AC para generar certificados.
gcloud privateca pools add-iam-policy-binding $prefix-ca-pool \
--member=$member \
--role='roles/privateca.certificateManager' \
--location=$region
Actualiza la política YAML para incluir la inspección de TLS
cat > /tmp/policy.yaml << EOF
description: some policy description
name: projects/${project_id}/locations/${region}/gatewaySecurityPolicies/${prefix}-policy
tlsInspectionPolicy: projects/${project_id}/locations/${region}/tlsInspectionPolicies/${prefix}-tls-inspection
EOF
Ejecuta el comando para aplicar la política actualizada
gcloud network-security gateway-security-policies import ${prefix}-policy --source=/tmp/policy.yaml --location=${region}
Actualiza las reglas para incluir la inspección de TLS
Luego, especifica qué reglas deben tener la inspección de TLS "enabtlsInspectionEnabled: true" marca.
cat > /tmp/rule-com.yaml << EOF
name: projects/${project_id}/locations/${region}/gatewaySecurityPolicies/${prefix}-policy/rules/rule-com
enabled: true
priority: 1
description: Allow .com traffic with path index.html
basicProfile: ALLOW
sessionMatcher: host().endsWith('com')
applicationMatcher: request.path.matches('index.html')
tlsInspectionEnabled: true
EOF
Ejecuta el comando para aplicar la regla actualizada
gcloud network-security gateway-security-policies rules import rule-com --source=/tmp/rule-com.yaml --location=${region} --gateway-security-policy=${prefix}-policy
17. Prueba la inspección de TLS
Establece una conexión SSH a la VM de procesamiento de clienta. Esta VM tiene la variable de entorno configurada para usar Cloud SWP.
Desde cloudshell:
gcloud compute ssh clienta --zone=$zone --tunnel-through-iap
Ejecuta la consulta web anterior para verificar si SWP está realizando una inspección de TLS para recuperar la ruta de acceso.
curl -k https://google.com/index.html --proxy-insecure
Esta vez, debería tener éxito, ya que SWP puede evaluar ApplicationMatcher.
Resultado esperado:
<HTML><HEAD><meta http-equiv="content-type" content="text/html;charset=utf-8"> <TITLE>301 Moved</TITLE></HEAD><BODY> <H1>301 Moved</H1> The document has moved <A HREF="https://www.google.com/index.html">here</A>. </BODY></HTML>
Configuramos correctamente Cloud SWP para inspeccionar TLS y evaluar la lógica de applicationMatcher.
Sal de clienta.
18. Pasos de limpieza
En Cloud Shell, quita la puerta de enlace de SWP, la política de seguridad, los certificados, las instancias, Cloud NAT y Cloud Router:
gcloud -q network-services gateways delete ${prefix}-swp --location=${region}
gcloud -q network-security gateway-security-policies rules delete rule-com --location=${region} --gateway-security-policy=${prefix}-policy
gcloud -q network-security gateway-security-policies delete ${prefix}-policy --location=${region}
gcloud -q certificate-manager certificates delete ${prefix}-cert --location=${region}
gcloud -q network-security tls-inspection-policies delete $prefix-tls-inspection --location=$region
gcloud -q privateca roots disable $prefix-root-ca --pool=$prefix-ca-pool --location=$region
gcloud -q privateca roots delete $prefix-root-ca --pool=$prefix-ca-pool --location=$region --ignore-active-certificates --skip-grace-period
gcloud -q privateca pools delete $prefix-ca-pool --location=$region
gcloud -q compute instances delete clienta --zone=$zone
gcloud -q compute instances delete clientb --zone=$zone
gcloud -q compute routers nats delete ${prefix}-nat-gw-${region} \
--router=$prefix-cr --router-region=$region
gcloud -q compute routers delete `gcloud compute routers list --regions=$region --format="value(NAME)" | grep -e swg-autogen -e codelab-swp` --region=$region
Quita las subredes, las reglas de FW y las VPC:
gcloud -q compute networks subnets delete $prefix-vpc-subnet \
--region $region
gcloud -q compute networks subnets delete $prefix-proxy-only-subnet \
--region=$region
gcloud -q compute firewall-rules delete $prefix-allow-iap-proxy
gcloud -q compute networks delete $prefix-vpc
19. ¡Felicitaciones!
Felicitaciones por completar el codelab. Configuraste e implementaste correctamente el Proxy web seguro de Cloud en Google Cloud.
Temas abordados
- Cloud SWP y sus beneficios