Anthos Service Mesh y Traffic Director ahora son Cloud Service Mesh. Para obtener más información, consulta la descripción general de Cloud Service Mesh.

Anthos Service Mesh con el ejemplo mTLS

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.

mTLS mutua

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. Es posible que los usuarios nuevos de Google Cloud califiquen para obtener una prueba gratuita.

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 Realiza una limpieza.

Antes de comenzar

En este instructivo, se usa la aplicación de muestra Online Boutique para demostrar la configuración de mTLS en un clúster de GKE con la Anthos Service Mesh instalada.

Si necesitas configurar un clúster de GKE para este instructivo, consulta la Guía de inicio rápido de Anthos Service Mesh, que te guía en la configuración de un clúster, la instalación de Anthos Service Mesh y la implementación de la muestra de Online Boutique en el espacio de nombres demo.
Si tienes un clúster de GKE con Anthos Service Mesh instalado, pero necesitas la muestra, consulta la sección Online Boutique, en la que encuentras los pasos para la implementación de la muestra en el espacio de nombres demo.

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

Obtén una lista de los servicios de Online Boutique:
```
kubectl get services -n demo
```
Ten en cuenta que frontend-external es un LoadBalancer 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 proporciona una puerta de enlace de entrada predeterminada llamada istio-ingressgateway. También puedes acceder a Online Boutique con la dirección IP externa de istio-ingressgateway. Obtén la IP externa de istio-ingressgateway:
```
kubectl get service istio-ingressgateway -n istio-system
```
Abre otra pestaña en tu navegador y visita la aplicación con la dirección IP externa de istio-ingressgateway:
```
http://INGRESS_GATEWAY_EXTERNAL_IP/
```
Ejecuta el siguiente comando para curl el servicio frontend con HTTP sin formato de otro Pod en el espacio de nombres demo.
```
kubectl exec \
  $(kubectl get pod -l app=productcatalogservice -n demo -o jsonpath={.items..metadata.name}) \
  -c istio-proxy -n demo -- \
  curl http://frontend: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.

Aplica la siguiente política de autenticación para configurar todos los servicios en el espacio de nombres demo a fin de que solo acepte mTLS:
```
kubectl apply -f - <<EOF
apiVersion: "security.istio.io/v1beta1"
kind: "PeerAuthentication"
metadata:
  name: "namespace-policy"
  namespace: "demo"
spec:
  mtls:
    mode: STRICT
EOF
```
Resultado esperado:
```
peerauthentication.security.istio.io/namespace-policy created
```
La línea mode: STRICT en el YAML configura los servicios para que solo se acepten mTLS. De forma predeterminada, el mode es PERMISSIVE, y configura los servicios para que acepten textos simples y mTLS.
Ve a la pestaña del navegador que accede a Online Boutique con la dirección IP externa del servicio frontend-external y 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ón STRICT, 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 con istio-ingressgateway, la solicitud toma la siguiente ruta:

Flujo de autenticación mTLS:
1. El navegador envía una solicitud HTTP de texto simple al servidor.
2. El contenedor del proxy istio-ingressgateway intercepta la solicitud.
3. El proxy istio-ingressgateway 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.
4. El proxy istio-ingressgateway realiza una verificación de nombres segura en el certificado del servidor para corroborar que una identidad autorizada esté ejecutando el servidor.
5. Los proxies istio-ingressgateway 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 servicio frontend con HTTP sin formato de otro Pod en el espacio de nombres demo.
```
kubectl exec \
  $(kubectl get pod -l app=productcatalogservice -n demo -o jsonpath={.items..metadata.name}) \
  -c istio-proxy -n demo -- \
  curl http://frontend:80/ -o /dev/null -s -w '%{http_code}\n'
```
Tu solicitud falla porque todos los servicios en el espacio de nombres demo se configuran en 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.

Ir a Seguridad de GKE Enterprise
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
```

Borra la política de autenticación:

kubectl delete peerauthentication -n demo namespace-policy

Resultado esperado:

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 servicio frontend con HTTP sin formato de otro Pod en el espacio de nombres demo.
```
kubectl exec \
  $(kubectl get pod -l app=productcatalogservice -n demo -o jsonpath={.items..metadata.name}) \
  -c istio-proxy -n demo -- \
  curl http://frontend: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 en tu espacio de nombres demo. 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 demo -f -
apiVersion: "security.istio.io/v1beta1"
kind: "PeerAuthentication"
metadata:
  name: "frontend"
  namespace: "demo"
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 demo -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 porque frontend service se configuró como STRICT mTLS y el proxy de sidecar bloquea la solicitud.
Ejecuta el siguiente comando para curl el servicio frontend con HTTP sin formato de otro Pod en el espacio de nombres demo.
```
kubectl exec \
  $(kubectl get pod -l app=productcatalogservice -n demo -o jsonpath={.items..metadata.name}) \
  -c istio-proxy -n demo -- \
  curl http://frontend: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 es Strict y todos los otros servicios están configurados como Permissive.

Borra la política de autenticación y la regla de destino:

kubectl delete peerauthentication -n demo frontend
kubectl delete destinationrule -n demo frontend

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 servicio frontend con HTTP sin formato de otro Pod en el espacio de nombres demo.

kubectl exec \
  $(kubectl get pod -l app=productcatalogservice -n demo -o jsonpath={.items..metadata.name}) \
  -c istio-proxy -n demo -- \
  curl http://frontend: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

Si actualizas la página en la consola de Google Cloud, verás que los detalles de mTLS para todos los servicios ahora muestran Permissive.

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:
```
kubectl delete namespaces demo
```

¿Qué sigue?

Para obtener una guía general sobre cómo configurar las políticas de PeerAuthentication, consulta Configura la seguridad de transporte.