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). Configuras tus clientes para que utilicen explícitamente Cloud SWP 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 redes de VPC
- Cargas de trabajo fuera de Google Cloud conectadas por Cloud VPN o Cloud Interconnect
Cloud SWP habilita políticas flexibles y detalladas basadas en identidades centradas en la nube y aplicaciones web.
Beneficios
A continuación, se incluyen algunos ejemplos de los beneficios que el SWP de Cloud podría proporcionar a una organización:
Migración a Google Cloud:
Cloud SWP te ayuda a migrar a Google Cloud y, al mismo tiempo, conservar tus políticas de seguridad y requisitos existentes para el tráfico web de salida. Puedes evitar el uso de soluciones de terceros que requieren otra consola de administración o la edición manual de archivos de configuración.
Acceso a servicios web externos de confianza
El SWP de Cloud te permite aplicar políticas de acceso detalladas a tu tráfico web de salida para que puedas proteger tu red. Creas e identificas identidades de cargas de trabajo o aplicaciones y, luego, aplicas políticas.
Supervisión del acceso a servicios web no confiables
Puedes usar Cloud SWP para proporcionar acceso supervisado a servicios web que no son de confianza. Cloud SWP identifica el tráfico que no cumple con 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 de políticas detallados para las 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 del bucket o del objeto con Common Expression Language (CEL).
Funciones compatibles
Cloud SWP admite las siguientes funciones:
Servicio de proxy explícito
Los clientes deben configurarse de forma explícita para usar el servidor proxy. El proxy de SWP de Cloud aísla a los clientes de Internet creando 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 de proxies 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 menor costo.
Políticas de acceso de salida modulares
Específicamente, Cloud SWP admite las siguientes políticas de salida:
- Identidad de origen basada en etiquetas seguras, cuentas de servicio o direcciones IP.
- Son destinos basados en URLs y nombres de host.
- Solicitudes basadas en métodos, encabezados o URLs (las URLs se pueden especificar con listas, comodines o patrones)
- Encriptación de extremo a extremo: Los túneles de proxy-cliente pueden transitar a través de TLS. Cloud SWP también admite HTTP/S CONNECT para conexiones TLS de extremo a extremo iniciadas por el cliente al servidor de destino.
Integración simplificada de Cloud NAT
Cloud NAT aprovisiona automáticamente direcciones IP públicas adicionales cuando aumenta el conjunto de proxies que publican el tráfico de Cloud SWP.
Las direcciones IP públicas estáticas manuales también son una opción para quienes desean tener IPs 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 el paquete de operaciones de Google Cloud registran las actividades administrativas y las solicitudes de acceso para los recursos relacionados con el SWP de Cloud. 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 de TLS, inspeccionar la solicitud encriptada y aplicar políticas de seguridad.
- Integración estrecha con Certificate Authority Service (CAS), que es un repositorio escalable y con alta disponibilidad para las AC privadas.
- La capacidad de usar tu propia raíz de confianza si es necesario También puedes usar una CA raíz existente para firmar las CA subordinadas que mantienen las CAS. Si lo prefieres, puedes generar un nuevo certificado raíz en la CAS.
- Criterios de desencriptación detallados con SessionMatcher y ApplicationMatcher en las reglas de políticas del proxy web seguro Estos criterios incluyen los hosts coincidentes presentes en las listas de URLs, las expresiones regulares, los rangos de direcciones IP y las expresiones similares. Si es necesario, los criterios se pueden combinar con expresiones booleanas.
- Cada política de Proxy web seguro se puede configurar con su propia política de inspección de TLS y su propio grupo de CA. Como alternativa, varias políticas de 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 del firewall de VPC
2. Entorno de pruebas
En este codelab, se utilizará una sola VPC. Un recurso de procesamiento en este entorno saldrá con el SWP de Cloud, como se muestra en el siguiente diagrama.
En este lab, tendremos 2 VMs de cargas de trabajo.
El cliente A se configurará para enviar todas las solicitudes HTTP/HTTPS al SWP de Cloud.
El cliente B NO se configurará para enviar solicitudes HTTP o HTTPS de forma explícita al SWP de Cloud, 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 tu 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. Crea una red de VPC, una subred y una 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 correspondientes 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 cumpla con lo siguiente:
- Se aplica a todas las instancias de VM a las que deseas acceder mediante IAP.
- Permite el tráfico de entrada desde el rango de IP 35.235.240.0/20. Este rango contiene todas las direcciones IP que IAP usa para el reenvío de TCP.
En Cloud Shell, haz lo siguiente:
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 un 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 la puerta de enlace
Crea un archivo YAML que contenga la información pertinente 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 la puerta de enlace
Crea un archivo YAML que contenga las reglas. Estas reglas se representan en Common Expression Language (CEL). En este lab, se usará una regla simple que permitirá el tráfico a los dominios .com y bloqueará todos los demás:
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 a Cloud Certificate Manager 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. Crea 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 la carga de trabajo. El clienteA de la instancia de procesamiento 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 la coincidencia de sesiones
Establece una conexión SSH a la VM de Compute "clienta" que se creó recientemente. Esta VM tiene la variable de entorno configurada para usar Cloud SWP.
En Cloud Shell, haz lo siguiente:
gcloud compute ssh clienta --zone=$zone --tunnel-through-iap
Ejecuta algunas búsquedas web para validar la funcionalidad. Necesitamos -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. Se espera que veamos un redireccionamiento 301, ya que el sitio web se redirecciona a https://www.google.com.
Si ejecutas el siguiente comando, se proporcionarán registros detallados con información sobre la conexión:
curl https://google.com --proxy-insecure -v
Se destacan 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! ...
Puedes 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, consulta el registro detallado de salida y confirma que Cloud SWP bloquea 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
También puedes probar otros dominios para verificar el comportamiento.
Sal de la sesión de SSH a "clienta" y, luego, inicia una nueva conexión de 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 en la VM 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>
Pruebas con un dominio de la organización:
curl https://wikipedia.org
Esto funciona según lo esperado, ya que clientb 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 el envío de tráfico de forma explícita a través de Cloud SWP:
curl -x https://10.10.10.50:443/ https://wikipedia.org --proxy-insecure
Vemos que este tráfico se rechaza a través de la política de SWP de Cloud:
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 a la política de seguridad configurada. Se permite el tráfico destinado a .com y se rechazan todos los demás destinos.
Sal de clientb.
14. Actualiza una regla de política de seguridad de la puerta de enlace para ApplicationMatching
Actualicemos la regla para que coincida con los detalles a nivel de la aplicación. Compilaremos una regla para observar la ruta de acceso de la solicitud y permitirla solo 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. Cómo probar la regla de ApplicationMatcher
Conéctate a la VM de Compute de clienta a través de SSH. Esta VM tiene la variable de entorno configurada para usar Cloud SWP.
En Cloud Shell, haz lo siguiente:
gcloud compute ssh clienta --zone=$zone --tunnel-through-iap
Ejecuta algunas búsquedas web para validar la funcionalidad. Necesitamos -proxy-insecure porque creamos un certificado autofirmado para este lab:
curl http://google.com --proxy-insecure
Ten en cuenta que esta consulta fallará cuando antes se haya aprobado.
Access denied
Cualquier ruta de acceso a la solicitud que no sea "index.html" debe bloquearse con un error 403. No dudes en seguir probando esta función.
Modifica la consulta para incluir 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>
Se espera que veamos un redireccionamiento 301, ya que el sitio web se redirecciona a http://www.google.com/index.html.
Observa que esta es una solicitud HTTP. A continuación, deberás habilitar SWP para que tenga capacidades de inspección de TLS.
A continuación, ejecuta la misma consulta, pero a través de 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 en función de la regla de 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 según lo siguiente:
- Mapa de encabezados de la solicitud
- Método de solicitud
- Host de la solicitud
- Ruta de la solicitud
- Consulta de solicitud
- Esquema de solicitud
- URL de la solicitud completa
- Useragent de la solicitud
Crear una cuenta de servicio.
Esta cuenta de servicio tendrá permisos para generar certificados para la inspección de TLS de SWP.
gcloud beta services identity create \
--service=networksecurity.googleapis.com \
--project=$project_id
Asegúrate de que 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 CA raíz
Es la CA que se usa para firmar el certificado.
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 el 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
Crea una 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
Actualiza el grupo de CA para que use 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 CA para generar certificados.
gcloud privateca pools add-iam-policy-binding $prefix-ca-pool \
--member=$member \
--role='roles/privateca.certificateManager' \
--location=$region
Actualiza el archivo YAML de la política 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
A continuación, especifica qué reglas deben tener la marca de inspección de TLS "enabtlsInspectionEnabled: true".
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
Conéctate a la VM de Compute de clienta a través de SSH. Esta VM tiene la variable de entorno configurada para usar Cloud SWP.
En Cloud Shell, haz lo siguiente:
gcloud compute ssh clienta --zone=$zone --tunnel-through-iap
Ejecuta la consulta web anterior para verificar si el SWP realiza la 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 para la limpieza
En Cloud Shell, quita la puerta de enlace del 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 Cloud Secure Web Proxy en Google Cloud.
Temas abordados
- Cloud SWP y sus beneficios