Cloud Service Mesh a través de ejemplos: Autorización

Nota: En esta guía, solo se admite Cloud Service Mesh con las APIs de Istio y no se admiten las APIs de Google Cloud . Para obtener más información, consulta la descripción general de Cloud Service Mesh.

En este instructivo, aprenderás qué es la autorización y cómo habilitarla con Cloud Service Mesh en una aplicación de ejemplo para aprender a habilitar políticas de autorización en tus microservicios. Crearás una AuthorizationPolicy para DENY el acceso a un microservicio y, luego, una AuthorizationPolicy para ALLOW el acceso específico a un microservicio.

¿Qué es la autorización?

La autenticación verifica una identidad: ¿este servicio es quien dice ser? La autorización verifica el permiso: ¿este servicio tiene permitido hacer eso? La identidad es fundamental para esta idea. Con Cloud Service Mesh, AuthorizationPolicies permite que se controle la comunicación entre cargas de trabajo en tu malla para mejorar la seguridad y el acceso.

En una arquitectura de microservicios, en la que las llamadas se realizan a través de los límites de la red, las reglas de firewall basadas en IP no suelen ser adecuadas para proteger el acceso entre las cargas de trabajo. Con Cloud Service Mesh, puedes establecer reglas de autorización para lo siguiente:

• Controla el acceso a las cargas de trabajo dentro de la malla, ya sea de carga de trabajo a carga de trabajo o de usuario final a carga de trabajo.
• Define políticas de forma amplia o detallada según tus necesidades.

Para ver una explicación detallada sobre la configuración de políticas y las prácticas recomendadas, consulta Autorización con Cloud Service Mesh.

Costos

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

• GKE
• Cloud Service Mesh

Cuando completes el instructivo puedes borrar los recursos que hayas creado para evitar que se te sigan cobrando. Para obtener más información, consulta Cómo realizar una limpieza.

Antes de comenzar

• Asegúrate de que la facturación esté habilitada para tu proyecto.

• Aprovisionar Cloud Service Mesh en un clúster de GKE Existen varios métodos de configuración compatibles:

  • API de Fleet y un plano de control administrado en Google Cloud

  • asmcli y un plano de control no administrado en el clúster desactivado Google Cloud

• Clone el repositorio:

  git clone https://github.com/GoogleCloudPlatform/anthos-service-mesh-samples
  cd anthos-service-mesh-samples
  

Implementa una puerta de enlace de entrada

1. Establece el contexto actual para kubectl en el clúster:

   Nota: Usa --region en lugar de --zone, si el clúster es un clúster regional.

   gcloud container clusters get-credentials CLUSTER_NAME  \
       --project=PROJECT_ID \
       --zone=CLUSTER_LOCATION 
   

2. Crea un espacio de nombres para tu puerta de enlace de entrada:

   kubectl create namespace asm-ingress
   

3. Habilita el espacio de nombres para la inserción. Los pasos dependen de la implementación del plano de control.

   Administrado (TD)

   Aplica la etiqueta de inserción predeterminada al espacio de nombres:

   kubectl label namespace asm-ingress \
       istio.io/rev- istio-injection=enabled --overwrite
   

   Administrado (Istiod)

   Precaución: Cloud Service Mesh administrado con la implementación del plano de control ISTIOD está obsoleto. Debes modernizar todas las flotas de ISTIOD administradas a la implementación del plano de control de TRAFFIC_DIRECTOR.

   Recomendado: Ejecuta el siguiente comando para aplicar la etiqueta de inserción predeterminada al espacio de nombres:

   kubectl label namespace asm-ingress \
       istio.io/rev- istio-injection=enabled --overwrite
   

   Si eres un usuario existente con el plano de control de Istiod administrado, te recomendamos que uses la inserción predeterminada, pero se admite la inserción basada en revisiones. Sigue estas instrucciones:

   1. Ejecuta el siguiente comando para ubicar los canales de versiones disponibles:

      kubectl -n istio-system get controlplanerevision
      

      El resultado es similar a lo siguiente:

      NAME                AGE
      asm-managed-rapid   6d7h
      

      Nota: Si aparecen dos revisiones del plano de control en la lista anterior, quita una. No se admite tener varios canales del plano de control en el clúster.

      En el resultado, el valor en la columna NAME es la etiqueta de revisión que corresponde al canal de versiones disponible para la versión de Cloud Service Mesh.

   2. Aplica la etiqueta de revisión al espacio de nombres:

      kubectl label namespace asm-ingress \
          istio-injection- istio.io/rev=REVISION_LABEL --overwrite
      

   En el clúster

   Precaución: Cloud Service Mesh en el clúster que usa el plano de control ISTIOD en GKE en Google Cloud está obsoleto. Cloud Service Mesh con un plano de control en el clúster en Google Distributed Cloud (solo software) sigue siendo compatible, como se describe en Plataformas compatibles.

   Recomendado: Ejecuta el siguiente comando para aplicar la etiqueta de inserción predeterminada al espacio de nombres:

   kubectl label namespace asm-ingress \
       istio.io/rev- istio-injection=enabled --overwrite
   

   Te recomendamos que uses la inserción predeterminada, pero se admite la inserción basada en revisiones: Usa las siguientes instrucciones:

   1. Usa el siguiente comando para encontrar la etiqueta de revisión en istiod:

      kubectl get deploy -n istio-system -l app=istiod -o \
          jsonpath={.items[*].metadata.labels.'istio\.io\/rev'}'{"\n"}'
      

   2. Aplica la etiqueta de revisión a los espacios de nombres. En el siguiente comando, REVISION_LABEL es el valor de la etiqueta de revisión istiod que anotaste en el paso anterior.

      kubectl label namespace asm-ingress \
          istio-injection- istio.io/rev=REVISION_LABEL --overwrite
      

4. Implementa la puerta de enlace de ejemplo en el repositorio anthos-service-mesh-samples:

   kubectl apply -n asm-ingress \
       -f docs/shared/asm-ingress-gateway
   

   Resultado esperado:

   serviceaccount/asm-ingressgateway configured
   service/asm-ingressgateway configured
   deployment.apps/asm-ingressgateway configured
   gateway.networking.istio.io/asm-ingressgateway configured
   

Implementa la aplicación de muestra de Online Boutique.

1. Si no lo hiciste, establece el contexto actual de kubectl en el clúster:

   gcloud container clusters get-credentials CLUSTER_NAME  \
     --project=PROJECT_ID \
     --zone=CLUSTER_LOCATION 
   

2. Crea el espacio de nombres para la aplicación de ejemplo:

   kubectl create namespace onlineboutique
   

3. Etiqueta el espacio de nombres onlineboutique para insertar de forma automática los proxies de Envoy:

   kubectl label namespace onlineboutique \
      istio.io/rev- istio-injection=enabled --overwrite
   

4. Implementar la app de ejemplo, el VirtualService para el frontend y las cuentas de servicio para las cargas de trabajo En este instructivo, implementarás Online Boutique, una app de demo de microservicios.

   kubectl apply \
     -n onlineboutique \
     -f docs/shared/online-boutique/virtual-service.yaml
   

   kubectl apply \
     -n onlineboutique \
     -f docs/shared/online-boutique/service-accounts
   

Consulta tus servicios

1. Visualiza los Pods en el espacio de nombres onlineboutique:

   kubectl get pods -n onlineboutique
   

   Resultado esperado:

   NAME                                     READY   STATUS    RESTARTS   AGE
   adservice-85598d856b-m84m6               2/2     Running   0          2m7s
   cartservice-c77f6b866-m67vd              2/2     Running   0          2m8s
   checkoutservice-654c47f4b6-hqtqr         2/2     Running   0          2m10s
   currencyservice-59bc889674-jhk8z         2/2     Running   0          2m8s
   emailservice-5b9fff7cb8-8nqwz            2/2     Running   0          2m10s
   frontend-77b88cc7cb-mr4rp                2/2     Running   0          2m9s
   loadgenerator-6958f5bc8b-55q7w           2/2     Running   0          2m8s
   paymentservice-68dd9755bb-2jmb7          2/2     Running   0          2m9s
   productcatalogservice-84f95c95ff-c5kl6   2/2     Running   0          114s
   recommendationservice-64dc9dfbc8-xfs2t   2/2     Running   0          2m9s
   redis-cart-5b569cd47-cc2qd               2/2     Running   0          2m7s
   shippingservice-5488d5b6cb-lfhtt         2/2     Running   0          2m7s
   

   Todos los Pods de tu aplicación deben estar en funcionamiento, con un 2/2 en la columna READY. Esto indica que los Pods tienen un proxy de sidecar de Envoy insertado de forma correcta. Si no se muestra 2/2 después de un par de minutos, consulta la guía de solución de problemas.

2. Obtén la IP externa y configúrala en una variable:

   kubectl get services -n asm-ingress
   export FRONTEND_IP=$(kubectl --namespace asm-ingress \
   get service --output jsonpath='{.items[0].status.loadBalancer.ingress[0].ip}' \
   )
   

   Verás un resultado similar al siguiente:

   NAME                   TYPE           CLUSTER-IP      EXTERNAL-IP   PORT(S)                                      AGE
   asm-ingressgateway   LoadBalancer   10.19.247.233   35.239.7.64   80:31380/TCP,443:31390/TCP,31400:31400/TCP   27m
   
   

3. Visita la dirección EXTERNAL-IP en tu navegador web. Deberías ver la tienda de Online Boutique en tu navegador.

   

Autorización DenyAll para una carga de trabajo

En esta sección, se agrega un AuthorizationPolicy para rechazar todo el tráfico entrante al servicio de moneda. AuthorizationPolicies funciona transformando AuthorizationPolicies en parámetros de configuración legibles para Envoy y aplicando los parámetros de configuración a tus proxies sidecar. Esto permite que el proxy de Envoy autorice o rechace las solicitudes entrantes a un servicio.

1. Aplica un AuthorizationPolicy al currencyservice. Observa la coincidencia en la etiqueta currencyservice en el archivo YAML.

   kubectl apply -f docs/authorization/currency-deny-all.yaml -n onlineboutique
   

   apiVersion: security.istio.io/v1beta1
   kind: AuthorizationPolicy
   metadata:
     name: currency-policy
   spec:
     selector:
       matchLabels:
         app: currencyservice

2. Intenta acceder a la EXTERNAL-IP de tu puerta de enlace para ver Online Boutique en el navegador web. Deberías ver un error de autorización (error interno del servicio 500) de currency service.

   

Observa los registros de tu proxy de sidecar

Para ver lo que ocurre en el proxy de sidecar, puedes revisar los registros en el Pod.

1. Obtén el nombre de tu Pod de currencyservice:

   CURRENCY_POD=$(kubectl get pod -n onlineboutique |grep currency|awk '{print $1}')
   

2. Configura el proxy de Envoy para permitir registros de nivel de seguimiento. De forma predeterminada, no se registran las llamadas de autorización bloqueadas:

   kubectl debug --image istio/base --target istio-proxy -it $CURRENCY_POD -n onlineboutique -- curl -X POST "http://localhost:15000/logging?level=trace"
   

   Resultado esperado: none {:.devsite-disable-click-to-copy} active loggers: admin: trace alternate_protocols_cache: trace ... tracing: trace upstream: trace udp: trace wasm: trace

3. Usa curl para enviar tráfico a tu EXTERNAL_IP y generar registros:

   for i in {0..10}; do
   curl -s -I $FRONTEND_IP ; done
   

4. Consulta los registros relacionados con el control de acceso basado en roles (RBAC) en tu istio-proxy:

   kubectl logs -n onlineboutique $CURRENCY_POD -c istio-proxy | grep -m5 rbac
   

   Resultado esperado:

   2022-07-08T14:19:20.442920Z     debug   envoy rbac      checking request: requestedServerName: outbound_.7000_._.currencyservice.onlineboutique.svc.cluster.local, sourceIP: 10.8.8.5:34080, directRemoteIP: 10.8.8.5:34080, remoteIP: 10.8.8.5:34080,localAddress: 10.8.0.6:7000, ssl: uriSanPeerCertificate: spiffe://christineskim-tf-asm.svc.id.goog/ns/onlineboutique/sa/default, dnsSanPeerCertificate: , subjectPeerCertificate: OU=istio_v1_cloud_workload,O=Google LLC,L=Mountain View,ST=California,C=US, headers: ':method', 'POST'
   2022-07-08T14:19:20.442944Z     debug   envoy rbac      enforced denied, matched policy none
   2022-07-08T14:19:20.442965Z     debug   envoy http      [C73987][S13078781800499437460] Sending local reply with details rbac_access_denied_matched_policy[none]
     ```
   

Deberías ver un mensaje enforced denied en los registros, que indica que currencyservice está configurado para bloquear las solicitudes entrantes.

Permite el acceso restringido

En lugar de una política DENYALL, puedes configurar el acceso para que se permita en ciertas cargas de trabajo. Esto será relevante en una arquitectura de microservicios en la que quieras asegurarte de que solo los servicios autorizados puedan comunicarse entre sí.

En esta sección, habilitarás los servicios frontend y checkout para que puedan comunicarse con el servicio currency.

1. En el siguiente archivo, observa que un source.principal(cliente) específico puede acceder a currencyservice:

apiVersion: security.istio.io/v1beta1
kind: AuthorizationPolicy
metadata:
  name: currency-policy
spec:
  selector:
    matchLabels:
      app: currencyservice
  rules:
  - from:
    - source:
        principals: ["cluster.local/ns/onlineboutique/sa/frontend"]
  - from:
    - source:
        principals: ["cluster.local/ns/onlineboutique/sa/checkoutservice"]

1. Aplica la política:

   kubectl apply -f docs/authorization/currency-allow-frontend-checkout.yaml -n onlineboutique
   

2. Visita la EXTERNAL-IP en tu navegador web. Ahora deberías poder acceder a Online Boutique.

Realiza una limpieza

Para evitar que se apliquen cargos a tu cuenta de Google Cloud por los recursos usados en este instructivo, borra el proyecto que contiene los recursos o conserva el proyecto y borra los recursos individuales.

Para evitar que se apliquen cargos continuos a tu cuenta de Google Cloud por los recursos que se usaron en este instructivo, puedes borrar el proyecto o borrar los recursos individuales.

Borra el proyecto

Precaución: Borrar un proyecto tiene las siguientes consecuencias:

• Se borra todo su contenido. Si utilizaste un proyecto existente para este instructivo, cuando lo borres, también borrarás cualquier otro trabajo que hayas realizado en el proyecto.
• Se pierden los ID de proyecto personalizados. Cuando creaste este proyecto, es posible que hayas creado un ID del proyecto personalizado que desees utilizar en el futuro. Para conservar las URLs que usan el ID del proyecto, como una URL de appspot.com, borra los recursos seleccionados dentro del proyecto en lugar de borrar todo el proyecto.

En Cloud Shell, borra el proyecto:

  gcloud projects delete PROJECT_ID

Borra recursos

• Si deseas conservar el clúster y quitar la muestra de Online Retail, realiza la siguiente acción:

  1. Borra los espacios de nombres de la aplicación:

     kubectl delete namespace onlineboutique
     

     Resultado esperado:

     namespace "onlineboutique" deleted
     

  2. Borra el espacio de nombres de la puerta de enlace de entrada:

     kubectl delete namespace asm-ingress
     

     Resultado esperado:

     namespace "asm-ingress" deleted
     

• Si deseas evitar cargos adicionales, borra el clúster:

  gcloud container clusters delete CLUSTER_NAME  \
    --project=PROJECT_ID \
    --zone=CLUSTER_LOCATION 
  

¿Qué sigue?

• Para obtener una guía general sobre cómo configurar las políticas de PeerAuthentication, consulta Configura la seguridad de transporte.
• Explora el panel de seguridad de tu malla con Supervisa la seguridad de la malla.
• Profundiza en las políticas de autorización con Configura las funciones avanzadas de la política de autorización.
• Familiarízate con las prácticas recomendadas de seguridad de Cloud Service Mesh.