En este instructivo, aprenderás qué es la autorización y cómo habilitarla con Anthos Service Mesh en una aplicación de ejemplo para aprender a habilitar las políticas de autorización en tus microservicios.
Crearás un acceso de AuthorizationPolicy
a DENY
a un microservicio y, luego, un acceso específico de AuthorizationPolicy
a ALLOW
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 está autorizado a hacer eso?
La identidad es fundamental para esta idea. Con Anthos Service Mesh, AuthorizationPolicies
permite controlar la comunicación entre las cargas de trabajo y las cargas de trabajo en la malla para mejorar la seguridad y el acceso.
En una arquitectura de microservicios, en la que las llamadas se realizan entre los límites de la red, las reglas de firewall tradicionales basadas en IP no suelen ser adecuadas para proteger el acceso entre cargas de trabajo. Con Anthos 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 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 prácticas recomendadas, consulta Autorización con Anthos Service Mesh.
Costos
En este instructivo, se usan los siguientes componentes facturables de Google Cloud:
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 Anthos Service Mesh administrado en un clúster de GKE Se admiten varios métodos de configuración:
Clona el repo:
git clone https://github.com/GoogleCloudPlatform/anthos-service-mesh-samples cd anthos-service-mesh-samples
Implementa una puerta de enlace de entrada
Establece el contexto actual de
kubectl
en el clúster:gcloud container clusters get-credentials CLUSTER_NAME \ --project=PROJECT_ID \ --zone=CLUSTER_LOCATION
Crea un espacio de nombres para la puerta de enlace de entrada:
kubectl create namespace asm-ingress
Habilita el espacio de nombres para la inserción. Los pasos dependen del tipo de Anthos Service Mesh (administrado o en el clúster):
Administrado
Aplica la etiqueta de revisión
asm-managed
al espacio de nombres:kubectl label namespace asm-ingress \ istio-injection- istio.io/rev=asm-managed --overwrite
Esta etiqueta corresponde al canal de versiones administrado de Anthos Service Mesh correspondiente a la versión de Anthos Service Mesh.
En el clúster
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"}'
Aplica la etiqueta de revisión a los espacios de nombres. En el siguiente comando,
REVISION
es el valor de la etiqueta de revisiónistiod
que anotaste en el paso anterior.kubectl label namespace asm-ingress \ istio-injection- istio.io/rev=REVISION --overwrite
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.
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
Crea el espacio de nombres para la aplicación de muestra:
kubectl create namespace onlineboutique
Etiqueta el espacio de nombres
onlineboutique
para insertar de forma automática los proxies de Envoy. Sigue los pasos para habilitar la inserción automática de sidecar.Implementa 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
Ver tus servicios
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 columnaREADY
. Esto indica que los Pods tienen un proxy de sidecar de Envoy insertado de forma correcta. Si no aparece2/2
después de unos minutos, consulta la guía de solución de problemas.Obtén la IP externa y establécela 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
Visita la dirección
EXTERNAL-IP
en tu navegador web. Deberías ver la tienda Online Boutique en tu navegador.
Autorización DenyAll para una carga de trabajo
En esta sección, se agrega un AuthorizationPolicy
para denegar todo el tráfico entrante al servicio de monedas.
AuthorizationPolicies
transforma AuthorizationPolicies
en archivos de configuración legibles de Envoy y aplica los parámetros de configuración a los proxies de sidecar. Esto permite que el proxy de Envoy autorice o rechace las solicitudes entrantes a un servicio.
Aplica un
AuthorizationPolicy
acurrencyservice
. Observa la coincidencia en la etiquetacurrencyservice
del archivo YAML.kubectl apply -f docs/authorization/currency-deny-all.yaml -n onlineboutique
Intenta acceder al
EXTERNAL-IP
de la puerta de enlace para ver Online Boutique en el navegador web. Deberías ver un error de autorización (Error interno del servicio 500) decurrency service
.
Observa los registros del proxy de sidecar
Para ver lo que sucede en el proxy de sidecar, puedes revisar los registros del Pod.
Obtén el nombre de tu Pod
currencyservice
:CURRENCY_POD=$(kubectl get pod -n onlineboutique |grep currency|awk '{print $1}')
Configura el proxy de Envoy para permitir los registros a nivel de seguimiento. De forma predeterminada, no se registran las llamadas de autorización bloqueadas:
kubectl exec -it $CURRENCY_POD -n onlineboutique -c istio-proxy -- curl -X POST "http://localhost:15000/logging?level=trace"
Resultado esperado:
active loggers: admin: trace alternate_protocols_cache: trace ... tracing: trace upstream: trace udp: trace wasm: trace
Usa
curl
para enviar tráfico a tuEXTERNAL_IP
a fin de generar registros:for i in {0..10}; do curl -s -I $FRONTEND_IP ; done
Vea los registros relacionados con el control de acceso basado en roles (RBAC) en su 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 muestre que currencyservice
está configurado para bloquear solicitudes entrantes.
Permitir acceso restringido
En lugar de una política DENYALL
, puedes configurar que se permita el acceso para ciertas cargas de trabajo. Esto será relevante en una arquitectura de microservicios en la que debe asegurarse de que solo los servicios autorizados puedan comunicarse entre sí.
En esta sección, habilitarás la capacidad de los servicios frontend
y checkout
para comunicarse con el servicio currency
.
- En el siguiente archivo, observa que un
source.principal
(cliente) específico está en la lista de entidades permitidas para acceder acurrencyservice
:
Aplica la política:
kubectl apply -f docs/authorization/currency-allow-frontend-checkout.yaml -n onlineboutique
- Visita
EXTERNAL-IP
en tu navegador web. Ahora deberías poder acceder a Online Boutique.
Observa tus servicios en la IU de seguridad de Anthos Service Mesh
En la consola de Google Cloud, ve a la página Seguridad de GKE Enterprise.
En la página Seguridad, puedes agregar o habilitar funciones para proteger las cargas de trabajo de tu aplicación. Para obtener más información, consulta Cómo supervisar la seguridad de la malla. Selecciona la pestaña Auditoría de políticas para ver una descripción general de tus cargas de trabajo.
Ten en cuenta que, en la columna Control de acceso a servicios, solo se muestra
currencyservice
como "Habilitado". Haz clic en Habilitado para ver los detalles deAuthorizationPolicy
.
Aquí puedes ver los AuthorizationPolicy
que aplicaste. Esto es útil para tener visibilidad en todas tus aplicaciones, especialmente si tienes una gran cantidad de políticas aplicadas a tus cargas de trabajo.
Explora el entorno de la IU. Puedes ver tus servicios interactuando entre sí y es útil para visualizar el comportamiento de seguridad. Este es solo un ejemplo sencillo de los beneficios que tienen las políticas cuando protegen tus cargas de trabajo.
Limpia
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 usaste en este instructivo, puedes borrar el proyecto o borrar los recursos individuales.
Borra 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:
Borra los espacios de nombres de la aplicación:
kubectl delete namespace onlineboutique
Resultado esperado:
namespace "onlineboutique" deleted
Borra el espacio de nombres de la puerta de enlace de entrada:
kubectl delete namespace asm-ingress
Resultado esperado:
amespace "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. - Mejora la postura de seguridad de tu clúster y aplicación con este instructivo sobre cómo fortalecer la seguridad de tu app con Anthos Service Mesh y Config Management.
- Explora el panel de seguridad de tu malla con Supervisar la seguridad de la malla.
- Analiza las políticas de autorización en Configura las funciones avanzadas de las políticas de autorización.
- Familiarízate con las prácticas recomendadas sobre seguridad de Anthos Service Mesh.