Volver a los microservicios con Istio. Parte 3



Nota perev. : La primera parte de esta serie se dedic贸 a presentar las capacidades de Istio y demostrarlas en acci贸n, la segunda al enrutamiento finamente ajustado y la gesti贸n del tr谩fico de red. Ahora hablaremos de seguridad: para demostrar las funciones b谩sicas asociadas con 茅l, el autor utiliza el servicio de identidad Auth0, pero otros proveedores se pueden configurar por analog铆a.

Establecimos un cl煤ster de Kubernetes en el que se implementaron Istio y el ejemplo de la aplicaci贸n de microservicio de An谩lisis de sentimientos: as铆 se demostraron las capacidades de Istio.

Al usar Istio, pudimos mantener los servicios de tama帽o peque帽o, ya que no necesitan implementar "capas" como reintentos, retiros, tiempos de espera, interruptores de circuito, rastreo, monitoreo . Adem谩s, utilizamos t茅cnicas avanzadas de prueba e implementaci贸n: pruebas A / B, duplicaci贸n y despliegues canarios.



En el nuevo material, trataremos las capas finales en el camino hacia el valor comercial: autenticaci贸n y autorizaci贸n, 隆y en Istio esto es un verdadero placer!

Autenticaci贸n y autorizaci贸n en Istio


Nunca hubiera cre铆do que me inspirar铆a la autenticaci贸n y la autorizaci贸n. 驴Qu茅 tecnolog铆a puede ofrecer Istio para hacer que estos temas sean emocionantes y a煤n m谩s para inspirarte?

La respuesta es simple: Istio transfiere la responsabilidad de estas funciones de sus servicios a los servidores proxy de Envoy. Cuando las solicitudes llegan a los servicios, ya est谩n autenticadas y autorizadas, por lo que solo tiene que escribir un c贸digo 煤til para las empresas.

Suena bien? 隆Miremos adentro!

Autenticaci贸n con Auth0


Utilizaremos Auth0 como servidor para la gesti贸n de identidad y acceso, que tiene una versi贸n de prueba, que es intuitiva de usar y me gusta. Sin embargo, los mismos principios se pueden aplicar a cualquier otra implementaci贸n de OpenID Connect : KeyCloak, IdentityServer y muchos otros.

Primero, vaya al portal Auth0 con su cuenta, cree un inquilino (inquilino - "inquilino", unidad de aislamiento l贸gico, para m谩s detalles vea la documentaci贸n - Transl. Aprox.) Y vaya a Aplicaciones> Aplicaci贸n predeterminada , eligiendo Dominio , como se muestra en la captura de pantalla siguiente :



Especifique este dominio en el resource-manifests/istio/security/auth-policy.yaml ( fuente ):

 apiVersion: authentication.istio.io/v1alpha1 kind: Policy metadata: name: auth-policy spec: targets: - name: sa-web-app - name: sa-feedback origins: - jwt: issuer: "https://{YOUR_DOMAIN}/" jwksUri: "https://{YOUR_DOMAIN}/.well-known/jwks.json" principalBinding: USE_ORIGIN 

Al tener dicho recurso, Pilot (uno de los tres componentes b谩sicos de Control Plane en Istio - aprox. Transl.) Configura los Enviados para autenticar las solicitudes antes de redirigirlas a los servicios: sa-web-app y sa-feedback . Al mismo tiempo, la configuraci贸n no se aplica a los Enviados del sa-frontend , lo que nos permite dejar la interfaz sin autenticar. Para aplicar una pol铆tica, ejecute el comando:

 $ kubectl apply -f resource-manifests/istio/security/auth-policy.yaml policy.authentication.istio.io 鈥渁uth-policy鈥 created 

Regrese a la p谩gina y haga una solicitud; ver谩 que termina en 401 Estado no autorizado . Ahora redirigimos a los usuarios front-end a la autenticaci贸n con Auth0.

Solicitar autenticaci贸n con Auth0


Para autenticar las solicitudes de los usuarios finales, debe crear una API en Auth0 que represente los servicios autenticados (revisiones, detalles y calificaciones). Para crear una API, vaya a Auth0 Portal> API> Crear API y complete el formulario:



La informaci贸n importante aqu铆 es Identificador , que usaremos m谩s adelante en el script. Escrib谩moslo as铆:

  • P煤blico : {YOUR_AUDIENCE}

Los detalles restantes que necesitamos se encuentran en el Portal Auth0 en la secci贸n Aplicaciones : seleccione Aplicaci贸n de prueba (se crea autom谩ticamente con la API).

Aqu铆 escribimos:

  • Dominio : {YOUR_DOMAIN}
  • ID del cliente : {YOUR_CLIENT_ID}

Despl谩cese en la aplicaci贸n de prueba hasta el cuadro de texto URL de devoluci贸n de llamada permitida (URL permitidas para la devoluci贸n de llamada), en el que indicamos la URL a la que debe enviarse la llamada despu茅s de que se complete la autenticaci贸n. En nuestro caso, es:

 http://{EXTERNAL_IP}/callback 

Y para las URL de cierre de sesi贸n permitidas ( URL permitidas para cerrar sesi贸n), agregue:

 http://{EXTERNAL_IP}/logout 

Pasemos a la interfaz.

Actualizaci贸n Frontend


Cambie a la rama [istio-mastery] repositorio [istio-mastery] . En este hilo, el c贸digo front-end se cambia para redirigir a los usuarios a Auth0 para la autenticaci贸n y usar el token JWT en las solicitudes de otros servicios. Este 煤ltimo se implementa de la siguiente manera ( App.js ):

 analyzeSentence() { fetch('/sentiment', { method: 'POST', headers: { 'Content-Type': 'application/json', 'Authorization': `Bearer ${auth.getAccessToken()}` // Access Token }, body: JSON.stringify({ sentence: this.textField.getValue() }) }) .then(response => response.json()) .then(data => this.setState(data)); } 

Para convertir la interfaz para usar los datos del inquilino en Auth0, abra sa-frontend/src/services/Auth.js y reemplace los valores que escribimos anteriormente ( Auth.js ) en ella:

 const Config = { clientID: '{YOUR_CLIENT_ID}', domain:'{YOUR_DOMAIN}', audience: '{YOUR_AUDIENCE}', ingressIP: '{EXTERNAL_IP}' //      } 

La aplicaci贸n est谩 lista. Indique su ID de Docker en los siguientes comandos cuando cree y despliegue los cambios realizados:

 $ docker build -f sa-frontend/Dockerfile \ -t $DOCKER_USER_ID/sentiment-analysis-frontend:istio-auth0 \ sa-frontend $ docker push $DOCKER_USER_ID/sentiment-analysis-frontend:istio-auth0 $ kubectl set image deployment/sa-frontend \ sa-frontend=$DOCKER_USER_ID/sentiment-analysis-frontend:istio-auth0 

Prueba la aplicaci贸n! Ser谩 redirigido a Auth0, donde debe iniciar sesi贸n (o registrarse), despu茅s de lo cual ser谩 enviado de regreso a la p谩gina desde la cual se realizar谩n las solicitudes ya autenticadas. Si prueba los comandos curl mencionados en las primeras partes del art铆culo, recibir谩 un C贸digo de estado 401 , que indica que la solicitud no est谩 autorizada.

Pasemos al siguiente paso: autorizar solicitudes.

Autorizaci贸n con Auth0


La autenticaci贸n nos permite comprender qui茅n es el usuario, pero para saber a qu茅 tiene acceso, se requiere autorizaci贸n. Istio ofrece herramientas para esto tambi茅n.

Como ejemplo, crearemos dos grupos de usuarios (ver el diagrama a continuaci贸n):

  • Usuarios (usuarios) : con acceso solo a los servicios SA-WebApp y SA-Frontend;
  • Moderadores : con acceso a los tres servicios.


Concepto de autorizaci贸n

Para crear estos grupos, utilizaremos la extensi贸n de Autorizaci贸n Auth0 y Istio para proporcionarles diferentes niveles de acceso.

Instalaci贸n y configuraci贸n de Autorizaci贸n Auth0


En el portal Auth0, vaya a Extensiones e instale la Autorizaci贸n Auth0 . Despu茅s de la instalaci贸n, vaya a la Extensi贸n de autorizaci贸n y all铆, a la configuraci贸n del inquilino haciendo clic en la esquina superior derecha y seleccionando la opci贸n de men煤 adecuada (Configuraci贸n) . Active Grupos y haga clic en el bot贸n Publicar regla .



Creaci贸n grupal


En la Extensi贸n de autorizaci贸n, vaya a Grupos y cree un grupo de Moderadores . Como consideraremos a todos los usuarios autenticados como ordinarios, no es necesario crear un grupo adicional para ellos.

Seleccione el grupo Moderadores , haga clic en Agregar miembros , agregue su cuenta principal. Deje a algunos usuarios sin ning煤n grupo para asegurarse de que se les niegue el acceso. (Los nuevos usuarios se pueden crear manualmente a trav茅s de Auth0 Portal> Usuarios> Crear usuario ).

Agregar reclamo grupal al token de acceso


Los usuarios se agregan a los grupos, pero esta informaci贸n debe reflejarse en tokens de acceso. Para cumplir con OpenID Connect y al mismo tiempo devolver los grupos que necesitamos, el token deber谩 agregar su reclamo personalizado . Se implementa a trav茅s de las reglas de Auth0.

Para crear una regla, vaya al portal de reglas Auth0, haga clic en Crear regla y seleccione una regla vac铆a de las plantillas.



Copie el c贸digo a continuaci贸n y gu谩rdelo como la nueva regla Agregar reclamo de grupo ( namespacedGroup.js ):

 function (user, context, callback) { context.accessToken['https://sa.io/group'] = user.groups[0]; return callback(null, user, context); } 

Nota : este c贸digo toma el primer grupo de usuarios definido en la Extensi贸n de autorizaci贸n y lo agrega al token de acceso como un reclamo personalizado (bajo su espacio de nombres, como lo requiere Auth0).

Regrese a la p谩gina Reglas y verifique que tiene dos reglas escritas en el siguiente orden:

  • extensi贸n-autorizaci贸n-auth0
  • Agregar reclamo grupal

El orden es importante porque el campo de grupo recibe asincr贸nicamente la regla de extensi贸n de autorizaci贸n auth0 y luego se agrega como un reclamo por la segunda regla. El resultado es un token de acceso:

 { "https://sa.io/group": "Moderators", "iss": "https://sentiment-analysis.eu.auth0.com/", "sub": "google-oauth2|196405271625531691872" // [  ] } 

Ahora debe configurar el proxy Envoy para verificar el acceso del usuario, para lo cual el grupo ser谩 retirado del reclamo ( https://sa.io/group ) en el token de acceso devuelto. Este es el tema para la siguiente secci贸n del art铆culo.

Configuraci贸n de autorizaci贸n de Istio


Para que la autorizaci贸n funcione, debe habilitar RBAC para Istio. Para hacer esto, use la siguiente configuraci贸n:

 apiVersion: "rbac.istio.io/v1alpha1" kind: RbacConfig metadata: name: default spec: mode: 'ON_WITH_INCLUSION' # 1 inclusion: services: # 2 - "sa-frontend.default.svc.cluster.local" - "sa-web-app.default.svc.cluster.local" - "sa-feedback.default.svc.cluster.local" 

Explicaciones:
  • 1: habilite RBAC solo para los servicios y espacios de nombres enumerados en el campo Inclusion ;
  • 2 - enumere la lista de nuestros servicios.


Aplicamos la configuraci贸n con este comando:

 $ kubectl apply -f resource-manifests/istio/security/enable-rbac.yaml rbacconfig.rbac.istio.io/default created 

Ahora todos los servicios requieren control de acceso basado en roles. En otras palabras, se deniega el acceso a todos los servicios y dar谩 como resultado una respuesta RBAC: access denied . Ahora permita el acceso a usuarios autorizados.

Configuraci贸n de acceso para usuarios habituales.


Todos los usuarios deben tener acceso a los servicios SA-Frontend y SA-WebApp. Implementado usando los siguientes recursos de Istio:

  • ServiceRole : define los derechos que tiene el usuario;
  • ServiceRoleBinding : determina a qui茅n pertenece este ServiceRole.

Para usuarios comunes, permita el acceso a ciertos servicios ( servicerole.yaml ):

 apiVersion: "rbac.istio.io/v1alpha1" kind: ServiceRole metadata: name: regular-user namespace: default spec: rules: - services: - "sa-frontend.default.svc.cluster.local" - "sa-web-app.default.svc.cluster.local" paths: ["*"] methods: ["*"] 

Y a trav茅s regular-user-binding aplique un ServiceRole a todos los visitantes de la p谩gina ( regular-user-service-role-binding.yaml ):

 apiVersion: "rbac.istio.io/v1alpha1" kind: ServiceRoleBinding metadata: name: regular-user-binding namespace: default spec: subjects: - user: "*" roleRef: kind: ServiceRole name: "regular-user" 

驴Significa "todos los usuarios" que los usuarios no autenticados tendr谩n acceso a SA WebApp? No, la pol铆tica verificar谩 la validez del token JWT.

Aplicar configuraci贸n:

 $ kubectl apply -f resource-manifests/istio/security/user-role.yaml servicerole.rbac.istio.io/regular-user created servicerolebinding.rbac.istio.io/regular-user-binding created 

Configuraci贸n de acceso para moderadores


Para los moderadores, queremos habilitar el acceso a todos los servicios ( mod-service-role.yaml ):

 apiVersion: "rbac.istio.io/v1alpha1" kind: ServiceRole metadata: name: mod-user namespace: default spec: rules: - services: ["*"] paths: ["*"] methods: ["*"] 

Pero queremos tales derechos solo para aquellos usuarios cuyo token de acceso tiene un reclamo https://sa.io/group con el valor Moderators ( mod-service-role-binding.yaml ):

 apiVersion: "rbac.istio.io/v1alpha1" kind: ServiceRoleBinding metadata: name: mod-user-binding namespace: default spec: subjects: - properties: request.auth.claims[https://sa.io/group]: "Moderators" roleRef: kind: ServiceRole name: "mod-user" 

Aplicar configuraci贸n:

 $ kubectl apply -f resource-manifests/istio/security/mod-role.yaml servicerole.rbac.istio.io/mod-user created servicerolebinding.rbac.istio.io/mod-user-binding created 

Debido al almacenamiento en cach茅 de los enviados, las reglas de autorizaci贸n pueden tardar un par de minutos en surtir efecto. Despu茅s de eso, puede asegurarse de que los usuarios y moderadores tengan diferentes niveles de acceso.

Conclusi贸n sobre esta parte


Bueno, en serio: 驴alguna vez has visto un enfoque de autenticaci贸n y autorizaci贸n m谩s simple, sin esfuerzo, escalable y seguro?

Solo se necesitaron tres recursos Istio (RbacConfig, ServiceRole y ServiceRoleBinding) para lograr un control m谩s preciso sobre la autenticaci贸n y la autorizaci贸n del acceso del usuario final a los servicios.

Adem谩s, nos ocupamos de estos problemas de nuestros servicios enviados, logrando:

  • Reducir la cantidad de c贸digo de muestra que puede incluir problemas de seguridad y errores;
  • reduciendo el n煤mero de situaciones est煤pidas en las que un punto final result贸 ser accesible desde el exterior y olvid贸 informarlo;
  • eliminando la necesidad de actualizar todos los servicios cada vez que se agrega un nuevo rol o derecho;
  • que los nuevos servicios siguen siendo simples, seguros y r谩pidos.

Conclusi贸n


Istio permite a los equipos enfocar sus recursos en tareas cr铆ticas del negocio sin agregar gastos generales a los servicios, devolvi茅ndoles el estado micro.

El art铆culo (en tres partes) proporcion贸 conocimientos b谩sicos e instrucciones pr谩cticas listas para comenzar a trabajar con Istio en proyectos reales.

PD del traductor


Lea tambi茅n en nuestro blog:

Source: https://habr.com/ru/post/443668/


All Articles