Securizando Kubernetes en Azure con Istio.
Habilitando Mutual TLS en AKS con Istio
Objetivos
Utilizar dos de los componentes de Istio para securizar la información en tránsito y la identidad de los servicios de kubernetes en un cluster AKS.
Intro
Recientemente pude participar de despliegues Istio en tres cloud providers, AWS, Azure y GCP, para administrar un número importante de microservicios, y si bien la instalación del core de Istio junto con todos sus CRD’s, servicios etc., varía dependiendo del cloud provider (en criollo, a veces es extremadamente fácil y a veces un quilombo) una vez instalado y corriendo, le facilita la vida al admin de una manera impresionante.
Istio es una herramienta muy poderosa cuando hablamos de service mesh, y quizás la más popular en estos días (sin embargo, y lo digo personalmente, hay un par de tools para implementar mesh mucho más performantes que istio), aunque por lo general se lo relaciona casi instantáneamente con mesh, tracing y service discovery, Istio tiene componentes bastante copados cuando hablamos de seguridad de nuestro cluster de kubernetes.
En este post vamos a ver dos de esos componentes en acción, Envoy Proxy y Citadel en un cluster montado sobre Azure Kubernetes Service.
Pre-requisitos:
- Conocimiento básico Istio.
- Conocimiento básico de Kubernetes
- Cluster de Kubernetes con Istio instalado (EKS, ACK, GKE, AKS, K3s, Minikube… lo que tengan a mano)
Login y AKS Kubeconfig
En primer lugar nos logueamos a Azure con:
$ az login --username TU-USERNAME --password TU-PASS
Obtenemos el kubeconf con ayuda de AZ CLI utilizando el subcomando de AKS:
$ az aks get-credentials --name NOMBRE-AKS --resource-group NOMBRE-RG
Ya tenemos acceso a nuestro cluster con Istio previamente instalado y una serie de microservicios corriendo en un namespace de prueba:
Envoy Proxy y Citadel
Es una muy buena práctica cuando configuramos nuestro cluster, hacerlo bajo políticas ZTN o Zero Trust Network, esto no es más que configurar todos los componentes del cluster para que ningún componente del cluster “confíe” en otro (sea proceso o usuario) a menos que se cumplan una serie de reglas. En kubernetes por lo general la comunicación interna de sus servicios se hace sin ningún tipo de cifrado o autenticación, esto hace al cluster propenso a que puedan interceptar dicho tráfico o también a ataques de suplantación de identidad por ejemplo.
Istio nos provee dos componentes para ayudarnos a sentirnos más seguros en este aspecto, Envoy y Citadel, Envoy es un proxy que se encarga de mantener el registro de los svc en el cluster, y captura todas las conexiones entrantes y salientes, y es desplegado automáticamente por Istio en todos los objetos de k8s como sidecar (en realidad en todos los objetos pertenecientes a un namespace bajo el control de istio), Citadel por su parte genera un x509 certificate por cada svc registrado, de esta manera cada svc va a tener una identificación única para que por ejemplo en una comunicación entre un servicio A y otro B ambos puedan estar seguros de la identidad del otro. Este mismo certificado se usa para cifrar la información en tránsito entre ambos servicios. Y acá lo más importante, tenemos control de la identidad de nuestros servicios y cifrado en tránsito sin tener que instalar a parte una CA y configurarla nosotros mismos (lo cual si lo han hecho alguna vez saben que es un quilombo), y no solo eso, vamos a activar toda esta tremenda seguridad solo con dos líneas en nuestros manifests… yeap, DOS $#% LÍNEAS!!, grande Istio.
Activemos mTLS en nuestra instalación de Istio
Como mencionamos antes, e insisto, con mTLS en Istio no solamente ciframos la comunicación, sino que también estamos asegurando la identidad de los servicios involucrados, así nos evitamos a algún software o usuario malicioso; en este contexto vamos a poder realizar una comunicación interna segura independientemente de que la red lo sea o no, eso va para vos Carlín
Pero, lo mas copado de todo, es que solo necesitamos 2 lineas para habilitar toda esta seguridad, solo hay que modificar la destination rule que nos interesa, en la sección de trafficPolicy habilitando la opción tls en modo ISTIO_MUTUAL, o sea, agregando lo siguiente a nuestro manifest de definición de la destination rule que queremos securizar, recuerden, en el ámbito de trafficPolicy:
tls:
mode: ISTIO_MUTUAL
Para mostrarlo con un ejemplo vamos a utilizar uno de los samples oficiales de Istio (pueden descargar el sample de la página oficial) llamado bookinfo y la destination rule que vamos a modificar es la de reviews.
Tiramos un describe y vemos que no tenemos nada raro en la regla, solo la definición de las tres versiones, y el RANDOM como política.
Ahora solo hay que abrir nuestro yaml, meter esas dos líneas, tirar el apply y…
LISTO!! tenemos las conexiones internas de nuestros servicios securizada y en manos de Istio.
Por supuesto hay mucho más de lo que se puede hacer con Istio, canary deployments, hacer mirror de peticiones, inyectar voluntariamente errores etc. y con mTLS también ya que de la forma que acabamos de mostrar en este post, mTLS solo queda habilitado en modo permisivo (no estricto) pero bueno, será materia para el siguiente post de Istio.
