En la Anthos Service Mesh 1.5 y versiones posteriores, la TLS mutua (automática mTLS) automática está habilitada de forma predeterminada. Con la mTLS automática, un proxy de sidecar de cliente detecta si el servidor tiene un sidecar de forma automática. El sidecar del cliente envía mTLS a las cargas de trabajo con sidecars y envía el texto simple a las cargas de trabajo sin sidecars. Sin embargo, ten en cuenta que los servicios aceptan el texto simple y el tráfico mTLS. A medida que inyectes proxies de sidecar a tus Pods, recomendamos que también configures tus servicios para que solo acepten tráfico mTLS.
Con Anthos Service Mesh, puedes aplicar un solo archivo YAML a fin de aplicar mTLS fuera del código de tu aplicación. Anthos Service Mesh te brinda la flexibilidad para aplicar una política de autenticación a toda la malla de servicios, a un espacio de nombres o a una carga de trabajo individual.
Costos
En este documento, usarás los siguientes componentes facturables de Google Cloud:
Para generar una estimación de costos en función del uso previsto, usa la calculadora de precios.
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 de Cloud. Descubre cómo confirmar que tienes habilitada la facturación en un proyecto.
Instalar Anthos Service Mesh en un clúster de GKE e implementar una puerta de enlace de entrada Si necesitas configurar un clúster para este instructivo, consulta la Guía de inicio rápido de Anthos Service Mesh, que te guía a través de los siguientes pasos:
- Crea un clúster de GKE.
- Instala Anthos Service Mesh con el plano de control en el clúster.
- Implementa una puerta de enlace de entrada.
- Implementar la aplicación de muestra Online Boutique desde el repositorio
anthos-service-mesh-packages
, que se modifica desde el conjunto original de manifiestos enmicroservices-demo
repositorio. De acuerdo con las prácticas recomendadas, cada servicio se implementa en un espacio de nombres distinto con una cuenta de servicio única.
Accede a Online Boutique
Configura el contexto actual de
kubectl
en el clúster en el que implementaste Online Boutique:gcloud container clusters get-credentials CLUSTER_NAME \ --project=PROJECT_ID \ --zone=CLUSTER_LOCATION
Enumera los servicios en el espacio de nombres
frontend
:kubectl get services -n frontend
Ten en cuenta que
frontend-external
es unLoadBalancer
y que tiene una dirección IP externa. La aplicación de muestra incluye un servicio que es un balanceador de cargas para que se pueda implementar en GKE sin Anthos Service Mesh.Visita la aplicación en tu navegador con la dirección IP externa del servicio
frontend-external
:http://FRONTEND_EXTERNAL_IP/
Anthos Service Mesh te permite implementar una puerta de enlace de entrada. También puedes acceder a Online Boutique mediante la dirección IP externa de la puerta de enlace de entrada. Obtenga la IP externa de la aplicación. Reemplaza los marcadores por la siguiente información:
- GATEWAY_SERVICE_NAME: El nombre del servicio de puerta de enlace de entrada. Si implementaste la puerta de enlace de muestra sin modificación o si implementaste la puerta de enlace de entrada predeterminada, el nombre será
istio-ingressgateway
. - GATEWAY_NAMESPACE: Es el espacio de nombres en el que implementaste la puerta de enlace de entrada. Si implementaste la puerta de enlace de entrada predeterminada, el espacio de nombres es
istio-system
.
kubectl get service GATEWAY_NAME -n GATEWAY_NAMESPACE
- GATEWAY_SERVICE_NAME: El nombre del servicio de puerta de enlace de entrada. Si implementaste la puerta de enlace de muestra sin modificación o si implementaste la puerta de enlace de entrada predeterminada, el nombre será
Abre otra pestaña en tu navegador y visita la aplicación con la dirección IP externa de la puerta de enlace de entrada:
http://INGRESS_GATEWAY_EXTERNAL_IP/
Ejecuta el siguiente comando para
curl
el serviciofrontend
con HTTP simple desde otro pod. Debido a que los servicios están en diferentes espacios de nombres, debes aplicar curl el nombre de DNS del serviciofrontend
.kubectl exec \ $(kubectl get pod -l app=productcatalogservice -n product-catalog -o jsonpath={.items..metadata.name}) \ -c istio-proxy -n product-catalog -- \ curl http://frontend.frontend.svc.cluster.local:80/ -o /dev/null -s -w '%{http_code}\n'
Tu solicitud se ejecuta de forma correcta con el estado
200
, porque, de forma predeterminada, se aceptan el tráfico de texto simple y el TLS.
Habilita TLS mutua por espacio de nombres
Aplica una política PeerAuthentication
con kubectl
para implementar mTLS.
Guarda la siguiente política de autenticación como
mtls-namespace.yaml
.cat <<EOF > mtls-namespace.yaml apiVersion: "security.istio.io/v1beta1" kind: "PeerAuthentication" metadata: name: "namespace-policy" spec: mtls: mode: STRICT EOF
La línea
mode: STRICT
en el YAML configura los servicios para que solo se acepten mTLS. De forma predeterminada, elmode
esPERMISSIVE
, y configura los servicios para que acepten textos simples y mTLS.Aplica la política de autenticación a fin de configurar todos los servicios de Online Boutique para que solo acepten mTLS:
for ns in ad cart checkout currency email frontend loadgenerator \ payment product-catalog recommendation shipping; do kubectl apply -n $ns -f mtls-namespace.yaml done
Resultado esperado:
peerauthentication.security.istio.io/namespace-policy created peerauthentication.security.istio.io/namespace-policy created peerauthentication.security.istio.io/namespace-policy created peerauthentication.security.istio.io/namespace-policy created peerauthentication.security.istio.io/namespace-policy created peerauthentication.security.istio.io/namespace-policy created peerauthentication.security.istio.io/namespace-policy created peerauthentication.security.istio.io/namespace-policy created peerauthentication.security.istio.io/namespace-policy created peerauthentication.security.istio.io/namespace-policy created peerauthentication.security.istio.io/namespace-policy created
Ve a la pestaña de tu navegador que accede a Online Boutique mediante la dirección IP externa del servicio
frontend-external
:http://FRONTEND_EXTERNAL_IP/
Actualiza la página. El navegador muestra el siguiente error:
La actualización de la página hace que el texto simple se envíe al servicio
frontend
. Debido a la política de autenticaciónSTRICT
, el proxy de sidecar bloquea la solicitud al servicio.Ve a la pestaña de tu navegador que accede a Online Boutique con la dirección IP externa de
istio-ingressgateway
y actualiza la página, que se muestra de forma correcta. Cuando accedes a Online Boutique mediante la puerta de enlace de entrada, la solicitud toma la siguiente ruta:Flujo de autenticación mTLS:
- El navegador envía una solicitud HTTP de texto simple al servidor.
- El contenedor del proxy de la puerta de enlace de entrada intercepta la solicitud.
- El proxy de la puerta de enlace de entrada realiza un protocolo de enlace TLS con el proxy del servidor (en este ejemplo, el servicio de frontend). Este protocolo de enlace incluye un intercambio de certificados. Estos certificados están precargados en los contenedores del proxy de Anthos Service Mesh.
- El proxy de la puerta de enlace de entrada realiza una verificación de nombres segura en el certificado del servidor para corroborar que una identidad autorizada esté ejecutando el servidor.
- Los proxies de la puerta de enlace de entrada y del servidor establecen una conexión TLS mutua y el proxy del servidor reenvía la solicitud al contenedor de la aplicación del servidor (el servicio de frontend).
Ejecuta el siguiente comando para
curl
el serviciofrontend
con HTTP simple desde otro pod.kubectl exec \ $(kubectl get pod -l app=productcatalogservice -n product-catalog -o jsonpath={.items..metadata.name}) \ -c istio-proxy -n product-catalog -- \ curl http://frontend.frontend.svc.cluster.local:80/ -o /dev/null -s -w '%{http_code}\n'
La solicitud falla porque todos los servicios de Online Boutique se configuraron como
STRICT
mTLS y el proxy de sidecar bloquea la solicitud al servicio.Resultado esperado:
000 command terminated with exit code 56
Consulta el estado de mTLS
Puedes ver el estado de las características de seguridad de Anthos, incluidas las políticas de autenticación, en la consola de Google Cloud.
En la consola de Google Cloud, ve a la página Seguridad empresarial de GKE.
Selecciona el proyecto de Google Cloud de la lista desplegable de la barra de menú.
En Resumen de políticas, se muestra el estado de seguridad de la aplicación, incluido el de mTLS.
Haz clic en Auditoría de políticas para ver los estados con respecto a las políticas de carga de trabajo de cada clúster y espacio de nombres. La tarjeta estado TLS m proporciona una descripción general. En la lista Cargas de trabajo, se muestra el estado de la mTLS de cada carga de trabajo.
Encuentra y borra políticas de autenticación
Para obtener una lista de todas las políticas de
PeerAuthentication
en la malla de servicios, haz lo siguiente:kubectl get peerauthentication --all-namespaces
El resultado es similar al siguiente:
NAMESPACE NAME MODE AGE ad namespace-policy STRICT 17m cart namespace-policy STRICT 17m checkout namespace-policy STRICT 17m currency namespace-policy STRICT 17m email namespace-policy STRICT 17m frontend namespace-policy STRICT 17m loadgenerator namespace-policy STRICT 17m payment namespace-policy STRICT 17m product-catalog namespace-policy STRICT 17m recommendation namespace-policy STRICT 17m shipping namespace-policy STRICT 17m
Borra la política de autenticación de todos los espacios de nombres de Online Boutique:
for ns in ad cart checkout currency email frontend loadgenerator payment \ product-catalog recommendation shipping; do kubectl delete peerauthentication -n $ns namespace-policy done;
Resultado esperado:
peerauthentication.security.istio.io "namespace-policy" deleted peerauthentication.security.istio.io "namespace-policy" deleted peerauthentication.security.istio.io "namespace-policy" deleted peerauthentication.security.istio.io "namespace-policy" deleted peerauthentication.security.istio.io "namespace-policy" deleted peerauthentication.security.istio.io "namespace-policy" deleted peerauthentication.security.istio.io "namespace-policy" deleted peerauthentication.security.istio.io "namespace-policy" deleted peerauthentication.security.istio.io "namespace-policy" deleted peerauthentication.security.istio.io "namespace-policy" deleted peerauthentication.security.istio.io "namespace-policy" deleted
Accede a Online Boutique con la dirección IP externa del servicio
frontend-external
y actualiza la página. La página debe mostrarse como se espera.Ejecuta el siguiente comando para
curl
el serviciofrontend
con HTTP simple desde otro pod.kubectl exec \ $(kubectl get pod -l app=productcatalogservice -n product-catalog -o jsonpath={.items..metadata.name}) \ -c istio-proxy -n product-catalog -- \ curl http://frontend.frontend.svc.cluster.local:80/ -o /dev/null -s -w '%{http_code}\n'
Tu solicitud se ejecuta de forma correcta con el estado
200
, porque, de forma predeterminada, se aceptan el tráfico de texto simple y el TLS.
Si actualizas la página en la consola de Google Cloud que muestra la lista Cargas de trabajo, ahora mostrará que el estado de mTLS es Permissive
.
Habilita TLS mutua por carga de trabajo
Si quieres configurar una política PeerAuthentication
para una carga de trabajo específica, debes configurar la sección selector
y especificar las etiquetas que coincidan con la carga de trabajo deseada.
Sin embargo, Anthos Service Mesh no puede agregar políticas a nivel de las cargas de trabajo para el tráfico mTLS saliente a un servicio. Debes configurar una regla de destino para administrar ese comportamiento.
Aplica una política de autenticación a una carga de trabajo específica. Observa cómo la siguiente política usa etiquetas y selectores para orientar la implementación específica de
frontend
.cat <<EOF | kubectl apply -n frontend -f - apiVersion: "security.istio.io/v1beta1" kind: "PeerAuthentication" metadata: name: "frontend" namespace: "frontend" spec: selector: matchLabels: app: frontend mtls: mode: STRICT EOF
Resultado esperado:
peerauthentication.security.istio.io/frontend created
Configura una regla de destino que coincida.
cat <<EOF | kubectl apply -n frontend -f - apiVersion: "networking.istio.io/v1alpha3" kind: "DestinationRule" metadata: name: "frontend" spec: host: "frontend.demo.svc.cluster.local" trafficPolicy: tls: mode: ISTIO_MUTUAL EOF
Resultado esperado:
destinationrule.networking.istio.io/frontend created
Accede a Online Boutique con la dirección IP externa del servicio
frontend-external
y actualiza la página. No se muestra la página porquefrontend service
se configuró comoSTRICT
mTLS y el proxy de sidecar bloquea la solicitud.Ejecuta el siguiente comando para
curl
el serviciofrontend
con HTTP simple desde otro pod.kubectl exec \ $(kubectl get pod -l app=productcatalogservice -n product-catalog -o jsonpath={.items..metadata.name}) \ -c istio-proxy -n product-catalog -- \ curl http://frontend.frontend.svc.cluster.local:80/ -o /dev/null -s -w '%{http_code}\n'
Tu solicitud falla con el código de estado
56
.Si actualizas la página en la consola de Google Cloud que muestra la lista Cargas de trabajo, ahora mostrará que el estado de mTLS para el servicio
frontend
esStrict
y todos los otros servicios están configurados comoPermissive
.Borra la política de autenticación:
kubectl delete peerauthentication -n frontend frontend
Resultado esperado:
peerauthentication.security.istio.io "frontend" deleted
Borra la regla de destino:
kubectl delete destinationrule -n frontend frontend
Resultado esperado:
destinationrule.networking.istio.io "frontend" deleted
Aplica la mTLS en toda la malla
Para evitar que todos tus servicios de la malla acepten tráfico de texto simple, establece una política PeerAuthentication
en toda la malla con el modo mTLS establecido en STRICT
.
La política PeerAuthentication
de toda la malla no debe tener un selector y se debe aplicar en el espacio de nombres raíz, istio-system
. Cuando implementas la política, el plano de control aprovisiona automáticamente certificados TLS para que las cargas de trabajo se puedan autenticar entre sí.
Aplica la mTLS en toda la malla:
kubectl apply -f - <<EOF apiVersion: "security.istio.io/v1beta1" kind: "PeerAuthentication" metadata: name: "mesh-wide" namespace: "istio-system" spec: mtls: mode: STRICT EOF
Resultado esperado:
peerauthentication.security.istio.io/mesh-wide created
Accede a Online Boutique con la dirección IP externa del servicio
frontend-external
y actualiza la página. No se muestra la página.Ejecuta el siguiente comando para
curl
el serviciofrontend
con HTTP simple desde otro pod.kubectl exec \ $(kubectl get pod -l app=productcatalogservice -n product-catalog -o jsonpath={.items..metadata.name}) \ -c istio-proxy -n product-catalog -- \ curl http://frontend.frontend.svc.cluster.local:80/ -o /dev/null -s -w '%{http_code}\n'
Tu solicitud falla con el código de estado
56
.Borra la política
mesh-wide
:kubectl delete peerauthentication -n istio-system mesh-wide
Resultado esperado:
peerauthentication.security.istio.io "mesh-wide" deleted
Si actualizas la página en la consola de Google Cloud, verás que los detalles de
mTLS
para todos los servicios ahora muestranPermissive
.
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.
Si deseas evitar cargos adicionales, borra el clúster:
gcloud container clusters delete CLUSTER_NAME \ --project=PROJECT_ID \ --zone=CLUSTER_LOCATION
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 -f online-boutique/kubernetes-manifests/namespaces
Resultado esperado:
namespace "ad" deleted namespace "cart" deleted namespace "checkout" deleted namespace "currency" deleted namespace "email" deleted namespace "frontend" deleted namespace "loadgenerator" deleted namespace "payment" deleted namespace "product-catalog" deleted namespace "recommendation" deleted namespace "shipping" deleted
- Borra las entradas de servicio:
kubectl delete -f online-boutique/istio-manifests/allow-egress-googleapis.yaml
Resultado esperado:
serviceentry.networking.istio.io "allow-egress-googleapis" deleted serviceentry.networking.istio.io "allow-egress-google-metadata" deleted
¿Qué sigue?
- Para obtener una guía general sobre cómo configurar las políticas de
PeerAuthentication
, consulta Configura la seguridad de transporte.