Proteger una pasarela

En esta página se explica cómo proteger una pasarela mediante varias funciones de seguridad:

• Políticas de SSL para asegurarse de que la pasarela usa los protocolos y algoritmos seguros necesarios

• Certificados para proteger el tráfico de cliente a pasarela y de pasarela a backend con TLS

• Política de seguridad de Google Cloud Armor para proteger los servicios frente a ataques DDoS

• Identity-Aware Proxy (IAP) para proporcionar una capa de autenticación y autorización antes de permitir el acceso a un servicio

Para obtener más información sobre la seguridad de la pasarela, consulta Seguridad de la pasarela.

Antes de empezar

Antes de empezar, asegúrate de que has realizado las siguientes tareas:

• Habilita la API de Google Kubernetes Engine.
Habilitar la API de Google Kubernetes Engine
• Si quieres usar Google Cloud CLI para esta tarea, instálala y, a continuación, inicialízala. Si ya has instalado la gcloud CLI, obtén la versión más reciente ejecutando gcloud components update.

Requisitos de GKE Gateway Controller

• La API Gateway solo se admite en clústeres nativos de VPC.
• Si usas GatewayClasses internas, debes habilitar una subred de solo proxy.
• Tu clúster debe tener habilitado el complemento HttpLoadBalancing.
• Si usas Istio, debes actualizarlo a una de las siguientes versiones:
  • 1.15.2 o posterior
  • 1.14.5 o posterior
  • 1.13.9 o posterior.

• Si utilizas una VPC compartida, en el proyecto host debes asignar el rol Compute Network User a la cuenta de servicio de GKE del proyecto de servicio.

• Asegúrate de que tienes un clúster Autopilot o Standard. Si necesitas uno, crea un clúster de Autopilot.

Restricciones y limitaciones

Además de las restricciones y limitaciones del controlador de pasarela de GKE, se aplican las siguientes limitaciones específicas a la seguridad de la pasarela:

• Las configuraciones de TLS que usan un certificado SSL o Certificate Manager en las pasarelas no son compatibles con la versión 1.28.4-gke.1083000 de GKE. Usa un secreto de Kubernetes como solución alternativa para esta versión de GKE.

• No puedes usar la anotación networking.gke.io/certmap con un tls.certificateRefs en el mismo recurso Gateway. Si haces referencia a un CertificateMap en un Gateway, GKE lo tratará como un error.

• Certificate Manager admite certificados autogestionados y gestionados por Google. Los certificados gestionados por Google son compatibles con las pasarelas regionales y globales.

• Cuando uses certificados SSL gestionados por Google, debes crear los certificados SSL fuera de GKE antes de adjuntarlos a tu Gateway.

• No puedes usar el mismo servicio como backend de una pasarela regional y una global si haces referencia a una política de seguridad de backend de Google Cloud Armor en tu GCPBackendPolicy. Debes crear dos servicios y dos políticas independientes para este caso práctico.

• El controlador de Gateway no admite el recurso ManagedCertificate.

• El controlador de la pasarela no admite la anotación networking.gke.io/managed-certificates.

Para ver una lista de los campos de la API Gateway y las funciones de los recursos de GatewayClass disponibles en GKE, consulta Funciones de GatewayClass.

Proteger una pasarela con un secreto de Kubernetes

En este ejemplo, se configura una pasarela mediante un secreto de Kubernetes.

Almacenar un certificado en un secreto de Kubernetes

Puedes usar un certificado emitido y validado por tu autoridad de certificación (CA) o crear un certificado autofirmado. En los pasos siguientes se usa un certificado autofirmado.

1. Crea una clave privada:

   openssl genrsa -out PRIVATE_KEY_FILE 2048
   

   Sustituye PRIVATE_KEY_FILE por el nombre del archivo de clave privada, como private-key.pem. Para obtener más información, consulta Seleccionar o crear una clave privada.

2. Crea un archivo de configuración de OpenSSL:

   cat <<EOF >CONFIG_FILE
   [req]
   default_bits              = 2048
   req_extensions            = extension_requirements
   distinguished_name        = dn_requirements
   prompt                    = no
   
   [extension_requirements]
   basicConstraints          = CA:FALSE
   keyUsage                  = nonRepudiation, digitalSignature, keyEncipherment
   subjectAltName            = @sans_list
   
   [dn_requirements]
   0.organizationName        = example
   commonName                = store.example.com
   
   [sans_list]
   DNS.1                     = store.example.com
   EOF
   

   Sustituye CONFIG_FILE por el nombre del nuevo archivo de configuración, como config-file.cnf.

3. Crea un archivo de solicitud de firma de certificado (CSR):

   openssl req -new -key PRIVATE_KEY_FILE \
       -out CSR_FILE \
       -config CONFIG_FILE
   

   Sustituye CSR_FILE por el nombre del nuevo archivo CSR, como cert.pem. Para obtener más información, consulta el artículo Crear una CSR.

4. Firma el CSR:

   openssl x509 -req \
       -signkey PRIVATE_KEY_FILE \
       -in CSR_FILE \
       -out CERTIFICATE_FILE \
       -extfile CONFIG_FILE \
       -extensions extension_requirements \
       -days 30
   

   Sustituye CERTIFICATE_FILE por la ruta y el nombre del archivo que genera el comando, como cert-file.pem. Para obtener más información, consulta Firmar la CSR.

5. Crea un secreto TLS de Kubernetes con la clave y el archivo de certificado que has creado:

   kubectl create secret tls store-example-com \
       --cert=CERTIFICATE_FILE \
       --key=PRIVATE_KEY_FILE
   

   GKE guarda el certificado y la clave como un recurso de Kubernetes que puedes adjuntar a tu Gateway.

Crear una pasarela y una HTTPRoute

1. Guarda el siguiente archivo de manifiesto como external-gateway.yaml:

   kind: Gateway
   apiVersion: gateway.networking.k8s.io/v1beta1
   metadata:
     name: external-http
   spec:
     gatewayClassName: gke-l7-global-external-managed
     listeners:
     - name: https
       protocol: HTTPS
       port: 443
       tls:
         mode: Terminate
         certificateRefs: # Directly reference the Kubernetes Secret containing the TLS certificate and private key.
         - name: store-example-com # The name of the TLS secret.
   

   Este manifiesto describe una pasarela con las siguientes propiedades:

   • gatewayClassName: gke-l7-global-external-managed: despliega un balanceador de carga de aplicación externo global.
   • protocol: HTTPS y port: 443: son necesarios para habilitar TLS.
   • tls: hace referencia al secreto de Kubernetes creado en el paso anterior.

2. Aplica el manifiesto al clúster:

   kubectl apply -f external-gateway.yaml
   

3. Guarda el siguiente archivo de manifiesto como store-external-route.yaml:

   kind: HTTPRoute
   apiVersion: gateway.networking.k8s.io/v1beta1
   metadata:
     name: store-external
     labels:
       gateway: external-http
   spec:
     parentRefs:
     - name: external-http # Link this route to the 'external-http' Gateway.
     hostnames:
     - "store.example.com" # Match traffic for this hostname.
     rules:
     - backendRefs: # Define where to forward the traffic.
       - name: store-v1
         port: 8080
   

   Este manifiesto describe una HTTPRoute que coincide con el tráfico a store.example.com y lo envía al servicio store-v1.

4. Aplica el manifiesto al clúster:

   kubectl apply -f store-external-route.yaml
   

Verificar la pasarela

Verifica que la pasarela funciona enviando una solicitud a través de Internet.

1. Obtén la dirección IP de la pasarela:

   kubectl get gateway external-http -o=jsonpath="{.status.addresses[0].value}"
   

   El resultado debería ser similar al siguiente:

   203.0.113.12
   

   Esta salida es una dirección IP pública, lo que significa que cualquier cliente con acceso a Internet puede conectarse a ella.

2. Accede al dominio de la pasarela mediante curl:

   curl https://store.example.com --resolve store.example.com:443:GATEWAY_IP_ADDRESS --cacert CERTIFICATE_FILE -v
   

   Haz los cambios siguientes:

   • GATEWAY_IP_ADDRESS: la dirección IP del balanceador de carga de la pasarela.
   • CERTIFICATE_FILE: el archivo de certificado que has generado. Debes guardar este archivo en el equipo que utilices para conectarte a la pasarela. El certificado es necesario para autenticar la pasarela, ya que esta usa un certificado autofirmado.

   La opción --resolve resuelve el nombre de dominio en la dirección IP de la pasarela, lo que es necesario porque no se ha configurado el DNS para este dominio.

   El resultado debería ser similar al siguiente:

   ...
   * TLSv1.2 (OUT), TLS handshake, Client hello (1):
   * TLSv1.2 (IN), TLS handshake, Server hello (2):
   * TLSv1.2 (IN), TLS handshake, Certificate (11):
   * TLSv1.2 (IN), TLS handshake, Server key exchange (12):
   * TLSv1.2 (IN), TLS handshake, Server finished (14):
   * TLSv1.2 (OUT), TLS handshake, Client key exchange (16):
   * TLSv1.2 (OUT), TLS change cipher, Change cipher spec (1):
   * TLSv1.2 (OUT), TLS handshake, Finished (20):
   * TLSv1.2 (IN), TLS change cipher, Change cipher spec (1):
   * TLSv1.2 (IN), TLS handshake, Finished (20):
   * SSL connection using TLSv1.2 / ECDHE-RSA-CHACHA20-POLY1305
   * ALPN, server accepted to use h2
   # This block shows the certificate details presented by the Gateway.
   # The value of the 'common name' field matches the requested hostname.
   * Server certificate:
   *  subject: O=example; CN=store.example.com
   *  start date: Apr 19 15:54:50 2021 GMT
   *  expire date: Apr 19 15:54:50 2022 GMT
   *  common name: store.example.com (matched)
   *  issuer: O=example; CN=store.example.com
   *  SSL certificate verify ok.
   ...
   {
     "cluster_name": "gw",
     "host_header": "store.example.com",
     "metadata": "store-v1",
     "node_name": "gke-gw-default-pool-51ccbf30-yya8.c.agmsb-k8s.internal",
     "pod_name": "store-v1-84b47c7f58-tj5mn",
     "pod_name_emoji": "😍",
     "project_id": "agmsb-k8s",
     "timestamp": "2021-04-19T16:30:08"
     # Several lines of output omitted here.
   }
   

   Esta salida incluye un handshake TLS correcto seguido de una respuesta de la aplicación. La conexión TLS se termina en la pasarela y la aplicación responde al cliente de forma segura.

Proteger una pasarela con un certificado SSL

En este ejemplo, se configura una Gateway con un certificado SSL gestionado por Google.

Crear un certificado SSL

1. Crea un recurso global SslCertificate gestionado por Google:

   gcloud compute ssl-certificates create store-example-com \
       --domains=store.example.com \
       --global
   

Crear una pasarela y una HTTPRoute

1. Guarda el siguiente archivo de manifiesto como external-gateway.yaml:

   kind: Gateway
   apiVersion: gateway.networking.k8s.io/v1beta1
   metadata:
     name: external-http
   spec:
     gatewayClassName: gke-l7-global-external-managed
     listeners:
     - name: https
       protocol: HTTPS
       port: 443
       tls:
         mode: Terminate # Terminate TLS using your SSL certificate.
         options:
           networking.gke.io/pre-shared-certs: store-example-com # Specify the Google Cloud SSL certificate resource name.
   

   Este manifiesto describe una pasarela con las siguientes propiedades:

   • gatewayClassName: gke-l7-global-external-managed: despliega un balanceador de carga de aplicación externo global.
   • protocol:HTTPS y port:443: son necesarios para habilitar TLS.
   • tls.mode:Terminate: finaliza TLS mediante tu certificado SSL.

2. Aplica el manifiesto a tu clúster:

   kubectl apply -f external-gateway.yaml
   

3. Guarda el siguiente manifiesto de HTTPRoute como store-external-route.yaml:

   kind: HTTPRoute
   apiVersion: gateway.networking.k8s.io/v1beta1
   metadata:
     name: store-external
     labels:
       gateway: external-http
   spec:
     parentRefs:
     - name: external-http
     hostnames:
     - "store.example.com"
     rules:
     - backendRefs:
       - name: store-v1
         port: 8080
   

4. Despliega el objeto HTTPRoute en tu clúster:

   kubectl apply -f store-external-route.yaml
   

   GKE puede tardar varios minutos en desplegar el Gateway.

Verificar la pasarela

1. Obtén la dirección IP de la pasarela:

   kubectl get gateway external-http -o=jsonpath="{.status.addresses[0].value}"
   

   El resultado debería ser similar al siguiente:

   203.0.113.12
   

   Esta salida es una dirección IP pública, lo que significa que cualquier cliente con acceso a Internet puede conectarse a ella.

2. Actualiza un registro A o AAAA para dirigir tu dominio a la dirección IP de la pasarela.

   Este paso solo es necesario si va a configurar un certificado SSL gestionado por Google. Si vas a configurar un certificado autogestionado, puedes saltarte este paso.

   Una vez que se hayan actualizado los registros DNS, el balanceador de carga puede tardar hasta 10 minutos en empezar a usar el certificado gestionado por Google.

3. Verifica que la pasarela funciona enviando una solicitud a través de Internet con curl:

   curl https://store.example.com -v
   

   El resultado debería ser similar al siguiente:

   ...
   * TLSv1.2 (OUT), TLS handshake, Client hello (1):
   * TLSv1.2 (IN), TLS handshake, Server hello (2):
   * TLSv1.2 (IN), TLS handshake, Certificate (11):
   * TLSv1.2 (IN), TLS handshake, Server key exchange (12):
   * TLSv1.2 (IN), TLS handshake, Server finished (14):
   * TLSv1.2 (OUT), TLS handshake, Client key exchange (16):
   * TLSv1.2 (OUT), TLS change cipher, Change cipher spec (1):
   * TLSv1.2 (OUT), TLS handshake, Finished (20):
   * TLSv1.2 (IN), TLS change cipher, Change cipher spec (1):
   * TLSv1.2 (IN), TLS handshake, Finished (20):
   * SSL connection using TLSv1.2 / ECDHE-RSA-CHACHA20-POLY1305
   * ALPN, server accepted to use h2
   * Server certificate:
   *  subject: O=example; CN=store.example.com
   *  start date: Apr 19 15:54:50 2021 GMT
   *  expire date: Apr 19 15:54:50 2022 GMT
   *  common name: store.example.com (matched)
   *  issuer: O=example; CN=store.example.com
   *  SSL certificate verify ok.
   ...
   {
     "cluster_name": "gw",
     "host_header": "store.example.com",
     "metadata": "store-v1",
     "node_name": "gke-gw-default-pool-51ccbf30-yya8.c.agmsb-k8s.internal",
     "pod_name": "store-v1-84b47c7f58-tj5mn",
     "pod_name_emoji": "😍",
     "project_id": "agmsb-k8s",
     "timestamp": "2021-04-19T16:30:08",
     "zone": "us-west1-a"
   }
   

   Esta salida incluye una negociación TLS correcta y una respuesta de la aplicación. TLS se termina correctamente en la puerta de enlace y la aplicación responde al cliente de forma segura.

Proteger una pasarela con Certificate Manager

En este ejemplo, se configura una pasarela con Gestor de certificados.

Crear un Certificate

gcloud certificate-manager certificates create "CERTIFICATE_NAME" \
    --certificate-file="CERTIFICATE_FILE" \
    --private-key-file="PRIVATE_KEY_FILE" \
    --location="REGION"

Crear una pasarela y una HTTPRoute

Verificar la pasarela

1. Obtén la dirección IP de la pasarela:

   kubectl get gateway external-http -o=jsonpath="{.status.addresses[0].value}"
   

   El resultado debería ser similar al siguiente:

   203.0.113.12
   

   Esta salida es una dirección IP pública, lo que significa que cualquier cliente con acceso a Internet puede conectarse a ella.

2. Actualiza un registro A o AAAA para dirigir tu dominio a la dirección IP de la pasarela.

   Este paso solo es necesario si vas a configurar un certificado SSL gestionado por Google. Si vas a configurar un certificado autogestionado, puedes omitir este paso.

   Una vez que se hayan actualizado los registros DNS, el balanceador de carga puede tardar hasta 10 minutos en empezar a usar el certificado gestionado por Google.

3. Accede al dominio de la pasarela mediante curl:

   curl https://store.example.com --resolve store.example.com:443:GATEWAY_IP_ADDRESS --cacert CERTIFICATE_FILE -v
   

   Haz los cambios siguientes:

   • GATEWAY_IP_ADDRESS: la dirección IP del balanceador de carga de la pasarela.
   • CERTIFICATE_FILE: el archivo de certificado que has generado. Debes guardar este archivo en el equipo que utilices para conectarte a la pasarela. El certificado es necesario para autenticar la pasarela, ya que esta usa un certificado autofirmado.

   El resultado debería ser similar al siguiente:

   ...
   * TLSv1.2 (OUT), TLS handshake, Client hello (1):
   * TLSv1.2 (IN), TLS handshake, Server hello (2):
   * TLSv1.2 (IN), TLS handshake, Certificate (11):
   * TLSv1.2 (IN), TLS handshake, Server key exchange (12):
   * TLSv1.2 (IN), TLS handshake, Server finished (14):
   * TLSv1.2 (OUT), TLS handshake, Client key exchange (16):
   * TLSv1.2 (OUT), TLS change cipher, Change cipher spec (1):
   * TLSv1.2 (OUT), TLS handshake, Finished (20):
   * TLSv1.2 (IN), TLS change cipher, Change cipher spec (1):
   * TLSv1.2 (IN), TLS handshake, Finished (20):
   * SSL connection using TLSv1.2 / ECDHE-RSA-CHACHA20-POLY1305
   * ALPN, server accepted to use h2
   * Server certificate:
   *  subject: O=example; CN=store.example.com
   *  start date: Apr 19 15:54:50 2021 GMT
   *  expire date: Apr 19 15:54:50 2022 GMT
   *  common name: store.example.com (matched)
   *  issuer: O=example; CN=store.example.com
   *  SSL certificate verify ok.
   ...
   {
     "cluster_name": "gw",
     "host_header": "store.example.com",
     "metadata": "store-v1",
     "node_name": "gke-gw-default-pool-51ccbf30-yya8.c.agmsb-k8s.internal",
     "pod_name": "store-v1-84b47c7f58-tj5mn",
     "pod_name_emoji": "😍",
     "project_id": "agmsb-k8s",
     "timestamp": "2021-04-19T16:30:08",
     "zone": "us-west1-a"
   }
   

   Esta salida incluye una negociación TLS correcta y una respuesta de la aplicación. TLS se termina correctamente en la puerta de enlace y la aplicación responde al cliente de forma segura.

Proteger el tráfico del balanceador de carga a la aplicación mediante TLS

Puede cifrar el tráfico del balanceador de carga a los pods de backend mediante el campo ports[].appProtocol. Los campos admitidos para appProtocol son: HTTP, HTTPS, HTTP2 y kubernetes.io/h2c.

El siguiente manifiesto describe un servicio que especifica que el balanceador de carga debe usar tráfico HTTPS para comunicarse con los pods de backend:

apiVersion: v1
kind: Service
metadata:
  name: store-v2
spec:
  selector:
    app: store
    version: v2
  ports:
  - port: 8080
    targetPort: 8080
    appProtocol: HTTPS

El balanceador de carga no verifica el certificado que usan los pods de backend. Es tu responsabilidad asegurarte de que el certificado utilizado en los pods de backend sea válido.

Proteger el tráfico de clientes al balanceador de carga mediante políticas de SSL

Cuando tus aplicaciones se exponen a través de una pasarela externa que usa HTTPS, es importante usar los protocolos más recientes o especificar la versión mínima de SSL o TLS. Puedes proteger el tráfico del cliente al balanceador de carga mediante políticas de SSL.

Para obtener más información sobre las políticas de SSL que se pueden asociar a tu Gateway y sobre cómo crearlas, consulta Configurar políticas de SSL para proteger el tráfico del cliente al balanceador de carga.

Protege tus back-ends con Google Cloud Armor

Las políticas de seguridad de Google Cloud Armor te ayudan a proteger tus aplicaciones con balanceo de carga frente a ataques web. Una vez que hayas configurado una política de seguridad de Google Cloud Armor, puedes hacer referencia a ella en un GCPBackendPolicy aplicado a tus servicios de Kubernetes.

Para configurar políticas de Google Cloud Armor con Gateway, consulta el artículo sobre cómo configurar una política de seguridad de Google Cloud Armor para proteger tus servicios de backend.

Autenticar solicitudes a tus back-ends mediante Identity-Aware Proxy

Identity-Aware Proxy te ayuda a proteger tus back-ends del tráfico no deseado autenticando a los clientes que envían solicitudes a tus aplicaciones y aplicando la autorización de tráfico basada en roles. Después de habilitar Identity-Aware Proxy para GKE, puedes hacer referencia a tus credenciales de OAuth en un GCPBackendPolicy aplicado a tus servicios de Kubernetes.

Para configurar Identity-Aware Proxy con Gateway, consulta Configurar Identity-Aware Proxy.

Siguientes pasos

• Consulta más información sobre la seguridad de la pasarela.
• Consulta cómo configurar recursos de Gateway mediante políticas.
• Consulta cómo implementar pasarelas.
• Más información sobre la API Gateway