ProHoster > Blog > Administración > Volve aos microservizos con Istio. Parte 3

Volve aos microservizos con Istio. Parte 3

Volve aos microservizos con Istio. Parte 3

Nota. transl.: Primeira parte esta serie dedicouse a coñecer as capacidades de Istio e a demostralas en acción, segundo — Enrutamento fino e xestión do tráfico de rede. Agora falaremos de seguridade: para demostrar as funcións básicas relacionadas con ela, o autor utiliza o servizo de identidade Auth0, pero outros provedores pódense configurar de xeito similar.

Configuramos un clúster de Kubernetes no que despregamos Istio e unha aplicación de microservizo de exemplo, Sentiment Analysis, para demostrar as capacidades de Istio.

Con Istio, puidemos manter pequenos os nosos servizos porque non precisan implementar capas como Reintentos, Tempos de espera, Interruptores, Rastrexo, Monitorización. . Ademais, utilizamos técnicas avanzadas de proba e despregamento: probas A/B, duplicación e lanzamentos canario.

Volve aos microservizos con Istio. Parte 3

No novo material, trataremos as capas finais do camiño cara ao valor empresarial: autenticación e autorización, e en Istio é un verdadeiro pracer.

Autenticación e autorización en Istio

Nunca tería credo que me inspirase a autenticación e a autorización. Que pode ofrecer Istio desde o punto de vista tecnolóxico para que estes temas sexan divertidos e, aínda máis, inspiradores para ti?

A resposta é sinxela: Istio traslada a responsabilidade destas capacidades dos teus servizos ao proxy de Envoy. Cando as solicitudes chegan aos servizos, xa están autenticadas e autorizadas, polo que só tes que escribir un código útil para a empresa.

Soa ben? Botámoslle unha ollada dentro!

Autenticación con Auth0

Como servidor para a xestión de identidades e accesos, utilizaremos Auth0, que ten unha versión de proba, é intuitivo de usar e simplemente gústame. Non obstante, os mesmos principios pódense aplicar a calquera outro Implementacións de OpenID Connect: KeyCloak, IdentityServer e moitos outros.

Para comezar, vai a Auth0 Portal coa túa conta, crea un inquilino (inquilino - "inquilino", unidade lóxica de illamento, para máis detalles consulte documentación - aprox. transl.) e vai a Aplicacións > Aplicación predeterminadaescollendo Dominio, como se mostra na seguinte captura de pantalla:

Volve aos microservizos con Istio. Parte 3

Especifique este dominio no ficheiro resource-manifests/istio/security/auth-policy.yaml (fonte):

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

Con tal recurso, Piloto (un dos tres compoñentes básicos do plano de control en Istio - trad. aprox.) configura Envoys para autenticar as solicitudes antes de reenvialas aos servizos: sa-web-app и sa-feedback. Ao mesmo tempo, a configuración non se aplica aos Envoys de servizo sa-frontend, o que nos permite deixar o frontend sen autenticar. Para aplicar a política, execute o comando:

$ kubectl apply -f resource-manifests/istio/security/auth-policy.yaml
policy.authentication.istio.io “auth-policy” created

Volve á páxina e fai unha solicitude; verás que remata co estado 401 non autorizado. Agora imos redirixir aos usuarios de frontend para que se autentiquen con Auth0.

Autenticación de solicitudes con Auth0

Para autenticar as solicitudes dos usuarios finais, cómpre crear unha API en Auth0 que represente os servizos autenticados (recensións, detalles e valoracións). Para crear unha API, vai a Auth0 Portal > APIs > Crear API e enche o formulario:

Volve aos microservizos con Istio. Parte 3

A información importante aquí é identificar, que usaremos máis adiante no guión. Escribamos así:

  • Público: {YOUR_AUDIENCE}

O resto de detalles que necesitamos están localizados no Portal Auth0 na sección aplicacións - seleccionar Aplicación de proba (creado automaticamente xunto coa API).

Aquí escribiremos:

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

Desprázate ata Aplicación de proba ao campo de texto URL de devolución de chamada permitidos (URL resoltos para a devolución de chamada), nos que especificamos o URL onde se debe enviar a chamada despois de completar a autenticación. No noso caso é:

http://{EXTERNAL_IP}/callback

E para URL de saída permitidos (URL permitidos para pechar sesión) engade:

http://{EXTERNAL_IP}/logout

Imos pasar ao frontend.

Actualización de frontend

Cambiar á sucursal auth0 repositorio [istio-mastery]. Nesta rama, cámbiase o código frontend para redirixir os usuarios a Auth0 para a súa autenticación e utilizar o token JWT nas solicitudes a outros servizos. Este último realízase do seguinte xeito (aplicación.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 cambiar o frontend para usar os datos do inquilino en Auth0, abra sa-frontend/src/services/Auth.js e substitúe nel os valores que escribimos anteriormente (Auth.js):

const Config = {
    clientID: '{YOUR_CLIENT_ID}',
    domain:'{YOUR_DOMAIN}',
    audience: '{YOUR_AUDIENCE}',
    ingressIP: '{EXTERNAL_IP}' // Используется для редиректа после аутентификации
}

A aplicación está lista. Especifique o seu ID de Docker nos comandos seguintes ao crear e implementar os 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

Proba a aplicación! Serás redirixido a Auth0, onde tes que iniciar sesión (ou rexistrarte), despois de que será enviado de novo á páxina desde a que se realizarán as solicitudes xa autenticadas. Se probas os comandos mencionados nas primeiras partes do artigo con curl, obterás o código 401 Código de estado, sinalando que a solicitude non está autorizada.

Imos dar o seguinte paso: autorizar solicitudes.

Autorización con Auth0

A autenticación permítenos comprender quen é un usuario, pero é necesaria a autorización para saber a que ten acceso. Istio tamén ofrece ferramentas para iso.

Como exemplo, creemos dous grupos de usuarios (consulte o diagrama a continuación):

  • Membros (usuarios) — con acceso só aos servizos SA-WebApp e SA-Frontend;
  • Moderadores (moderadores) — con acceso aos tres servizos.

Volve aos microservizos con Istio. Parte 3
Concepto de autorización

Para crear estes grupos, utilizaremos a extensión Auth0 Authorization e Istio para proporcionarlles diferentes niveis de acceso.

Instalación e configuración da Autorización Auth0

No portal Auth0, vai a extensións (Extensións) e instalar Auth0 Autorización. Despois da instalación, vaia a Extensión de autorización, e alí - á configuración do inquilino facendo clic na parte superior dereita e seleccionando a opción de menú adecuada (Configuración). Activar grupos (Grupos) e fai clic no botón publicar regra (Regra de publicación).

Volve aos microservizos con Istio. Parte 3

Creación de grupos

En Extensión de autorización vai a grupos e crear un grupo Moderadores. Dado que trataremos a todos os usuarios autenticados como usuarios habituais, non é necesario crear un grupo adicional para eles.

Escolle un grupo Moderadores, Preme Engadir membros, engade a túa conta principal. Deixe algúns usuarios sen ningún grupo para asegurarse de que se lles nega o acceso. (Os novos usuarios pódense crear manualmente mediante Auth0 Portal > Usuarios > Crear usuario.)

Engade a reclamación de grupo ao token de acceso

Engadíronse usuarios aos grupos, pero esta información tamén se debe reflectir nos tokens de acceso. Para cumprir con OpenID Connect e ao mesmo tempo devolver os grupos que necesitamos, o token terá que engadir o seu propio reclamación personalizada. Implementado mediante regras Auth0.

Para crear unha regra, vaia ao Portal Auth0 para Regras, Preme Crear regra e seleccione unha regra baleira dos modelos.

Volve aos microservizos con Istio. Parte 3

Copia o código a continuación e gárdao como unha nova regra Engadir reclamación 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 o primeiro grupo de usuarios definido na Extensión de autorización e engádeo ao token de acceso como unha reclamación personalizada (no seu espazo de nomes, como require Auth0).

Volver á páxina Regras e comproba que tes dúas regras escritas na seguinte orde:

  • auth0-autorización-extensión
  • Engadir reclamación de grupo

A orde é importante porque o campo do grupo recibe a regra de forma asíncrona auth0-autorización-extensión e despois engádese como reclamación pola regra segunda. O resultado é un token de acceso como este:

{
 "https://sa.io/group": "Moderators",
 "iss": "https://sentiment-analysis.eu.auth0.com/",
 "sub": "google-oauth2|196405271625531691872"
 // [сокращено для наглядности]
}

Agora cómpre configurar o proxy Envoy para comprobar o acceso dos usuarios, para o que o grupo será retirado da reclamación (https://sa.io/group) no token de acceso devolto. Este é o tema para a seguinte sección do artigo.

Configuración de autorización en Istio

Para que a autorización funcione, debes habilitar RBAC para Istio. Para iso, utilizaremos a seguinte 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"

Explicacións:

  • 1: habilite RBAC só para os servizos e espazos de nomes indicados no campo Inclusion;
  • 2: enumeramos unha lista dos nosos servizos.

Apliquemos a configuración co seguinte comando:

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

Agora todos os servizos requiren un control de acceso baseado en funcións. Noutras palabras, o acceso a todos os servizos está prohibido e dará lugar a unha resposta RBAC: access denied. Agora permitimos o acceso aos usuarios autorizados.

Configuración de acceso para usuarios habituais

Todos os usuarios deben ter acceso aos servizos SA-Frontend e SA-WebApp. Implementado mediante os seguintes recursos de Istio:

  • Rol de servizo — determina os dereitos que ten o usuario;
  • ServiceRoleBinding — determina a quen pertence este ServiceRole.

Para os usuarios comúns permitiremos o acceso a determinados servizos (rol de servizo.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: ["*"]

E a través regular-user-binding aplicar ServiceRole a todos os visitantes da páxina (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"

"Todos os usuarios" significa que os usuarios non autenticados tamén terán acceso á aplicación web SA? Non, a política comprobará a validez do token JWT.

Apliquemos as configuracións:

$ 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 os moderadores, queremos habilitar o acceso a todos os servizos (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 dereitos só para aqueles usuarios cuxo token de acceso conteña reclamación https://sa.io/group con 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"

Apliquemos as configuracións:

$ 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 ao almacenamento na caché dos enviados, as regras de autorización poden tardar un par de minutos en entrar en vigor. Despois podes asegurarte de que os usuarios e moderadores teñan diferentes niveis de acceso.

Conclusión desta parte

En serio, xa viu un enfoque máis sinxelo, sen esforzo, escalable e seguro para a autenticación e autorización?

Só se requirían tres recursos Istio (RbacConfig, ServiceRole e ServiceRoleBinding) para conseguir un control detallado sobre a autenticación e autorización do acceso dos usuarios finais aos servizos.

Ademais, encargámonos destas cuestións desde os nosos servizos enviados, conseguindo:

  • reducindo a cantidade de código xenérico que pode conter problemas de seguridade e erros;
  • reducindo o número de situacións estúpidas nas que un punto final resultou accesible desde o exterior e esqueceu informalo;
  • eliminando a necesidade de actualizar todos os servizos cada vez que se engade un novo rol ou dereito;
  • que os novos servizos sigan sendo sinxelos, seguros e rápidos.

Saída

Istio permite aos equipos centrar os seus recursos en tarefas críticas para a empresa sen engadir gastos xerais aos servizos, converténdoos ao estado micro.

O artigo (en tres partes) ofrecía coñecementos básicos e instrucións prácticas preparadas para comezar a utilizar Istio en proxectos reais.

PS do tradutor

Lea tamén no noso blog:

Fonte: www.habr.com

Engadir un comentario