🥇Voltar aos microsserviços com Istio. Parte 3

Observação. trad.: A primeira parte esta série foi dedicada a conhecer os recursos do Istio e demonstrá-los em ação, segundo — roteamento ajustado e gerenciamento de tráfego de rede. Agora falaremos sobre segurança: para demonstrar as funções básicas relacionadas a ela, o autor utiliza o serviço de identidade Auth0, mas outros provedores podem ser configurados de forma semelhante.

Montamos um cluster Kubernetes no qual implantamos o Istio e um exemplo de aplicativo de microsserviço, Sentiment Analysis, para demonstrar os recursos do Istio.

Com o Istio, conseguimos manter nossos serviços pequenos porque eles não precisam implementar camadas como novas tentativas, tempos limite, disjuntores, rastreamento, monitoramento. Além disso, usamos técnicas avançadas de testes e implantação: testes A/B, espelhamento e implementações canário.

No novo material, trataremos das camadas finais do caminho para o valor comercial: autenticação e autorização - e no Istio é um verdadeiro prazer!

Autenticação e autorização no Istio

Eu nunca teria acreditado que seria inspirado pela autenticação e autorização. O que o Istio pode oferecer do ponto de vista tecnológico para tornar esses tópicos divertidos e, mais ainda, inspiradores para você?

A resposta é simples: o Istio transfere a responsabilidade por esses recursos dos seus serviços para o proxy Envoy. No momento em que as solicitações chegam aos serviços, elas já foram autenticadas e autorizadas, portanto, tudo o que você precisa fazer é escrever um código útil para os negócios.

Parece bom? Vamos dar uma olhada por dentro!

Autenticação com Auth0

Como servidor para gerenciamento de identidade e acesso, usaremos o Auth0, que tem uma versão de teste, é intuitivo de usar e simplesmente gosto dele. No entanto, os mesmos princípios podem ser aplicados a qualquer outro Implementações do OpenID Connect: KeyCloak, IdentityServer e muitos outros.

Para começar, vá para Portal Autor0 com sua conta, crie um inquilino (inquilino - “inquilino”, unidade lógica de isolamento, para mais detalhes ver documentação - Aproximadamente. trad.) e vai para Aplicativos > Aplicativo padrãoescolhendo Domínio, conforme mostrado na captura de tela abaixo:

Especifique este domínio no arquivo resource-manifests/istio/security/auth-policy.yaml (código 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

Com tal recurso, Pilot (um dos três componentes básicos do plano de controle no Istio - tradução aproximada) configura o Envoy para autenticar solicitações antes de encaminhá-las aos serviços: sa-web-app и sa-feedback. Ao mesmo tempo, a configuração não se aplica aos Envoys de serviço sa-frontend, permitindo-nos deixar o frontend não autenticado. 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

Volte à página e faça uma solicitação - você verá que termina com o status 401 não autorizado. Agora vamos redirecionar os usuários frontend para autenticação com Auth0.

Autenticando solicitações com Auth0

Para autenticar solicitações de usuários finais, você precisa criar uma API em Auth0 que representará os serviços autenticados (avaliações, detalhes e classificações). Para criar uma API, vá para Portal Auth0 > APIs > Criar API e preencha o formulário:

A informação importante aqui é Identificar, que usaremos posteriormente no script. Vamos escrever assim:

Público: {SEU_PÚBLICO}

Os detalhes restantes que precisamos estão localizados no Portal Auth0 na seção Aplicações - selecione Aplicação de Teste (criado automaticamente junto com a API).

Aqui vamos escrever:

Domínio: {SEU DOMÍNIO}
ID do Cliente: {SEU_CLIENT_ID}

Role até Aplicação de Teste para o campo de texto URLs de retorno de chamada permitidos (URLs resolvidas para o retorno de chamada), em que especificamos a URL para onde a chamada deve ser enviada após a conclusão da autenticação. No nosso caso é:

http://{EXTERNAL_IP}/callback

E para URLs de logout permitidos (URLs permitidos para logout) adicione:

http://{EXTERNAL_IP}/logout

Vamos passar para o front-end.

Atualização de front-end

Mudar para filial auth0 repositório [istio-mastery]. Nesta ramificação, o código frontend é alterado para redirecionar os usuários para Auth0 para autenticação e usar o token JWT em solicitações para outros serviços. Este último é implementado da seguinte forma (Aplicativo.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 alterar o frontend para usar dados do locatário no Auth0, abra sa-frontend/src/services/Auth.js e substitua nele os valores que escrevemos acima (Autenticação.js):

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

O aplicativo está pronto. Especifique seu Docker ID nos comandos abaixo ao criar e implantar as alterações feitas:

$ 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

Experimente o aplicativo! Você será redirecionado para Auth0, onde deverá fazer login (ou registrar-se), após o qual será enviado de volta à página a partir da qual serão feitas as solicitações já autenticadas. Se você tentar os comandos mencionados nas primeiras partes do artigo com curl, obterá o código Código de Status 401, sinalizando que a solicitação não está autorizada.

Vamos dar o próximo passo: autorizar solicitações.

Autorização com Auth0

A autenticação nos permite entender quem é um usuário, mas é necessária autorização para saber a que ele tem acesso. O Istio também oferece ferramentas para isso.

Como exemplo, vamos criar dois grupos de usuários (veja o diagrama abaixo):

Membros (Comercial) — com acesso apenas aos serviços SA-WebApp e SA-Fronend;
Moderadores (moderadores) — com acesso aos três serviços.

Conceito de autorização

Para criar esses grupos, usaremos a extensão Auth0 Authorization e usaremos o Istio para fornecer-lhes diferentes níveis de acesso.

Instalação e configuração da Autorização Auth0

No portal Auth0, acesse extensões (Extensões) e instale Autorização Auth0. Após a instalação, vá para Extensão de autorização, e aí - para a configuração do locatário clicando no canto superior direito e selecionando a opção de menu apropriada (Configuração). Ativar grupos (Grupos) e clique no botão publicar regra (Regra de publicação).

Criar grupos

Em Extensão de Autorização vá para Grupos e crie um grupo Moderadores. Como trataremos todos os usuários autenticados como usuários regulares, não há necessidade de criar um grupo adicional para eles.

Escolha um grupo Moderadores, Pressione Adicionar membros, adicione sua conta principal. Deixe alguns usuários sem nenhum grupo para garantir que seu acesso seja negado. (Novos usuários podem ser criados manualmente via Portal Auth0 > Usuários > Criar usuário.)

Adicionar reivindicação de grupo ao token de acesso

Os usuários foram adicionados aos grupos, mas essas informações também devem ser refletidas nos tokens de acesso. Para cumprir o OpenID Connect e ao mesmo tempo retornar os grupos que precisamos, o token precisará adicionar o seu próprio reivindicação personalizada. Implementado por meio de regras Auth0.

Para criar uma regra, acesse o Portal Auth0 para Regras, Pressione Criar regra e selecione uma regra vazia nos modelos.

Copie o código abaixo e salve-o como uma nova regra Adicionar reivindicação de grupo (namespacedGroup.js):

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

Nota: esse código pega o primeiro grupo de usuários definido na Extensão de Autorização e o adiciona ao token de acesso como uma declaração personalizada (sob seu namespace, conforme exigido por Auth0).

Voltar para a página Regras e verifique se você tem duas regras escritas na seguinte ordem:

extensão de autorização-auth0
Adicionar reivindicação de grupo

A ordem é importante porque o campo grupo recebe a regra de forma assíncrona extensão de autorização-auth0 e depois disso é adicionado como uma reivindicação pela segunda regra. O resultado é um token de acesso como este:

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

Agora você precisa configurar o proxy Envoy para verificar o acesso do usuário, para o qual o grupo será retirado da reivindicação (https://sa.io/group) no token de acesso retornado. Este é o tema da próxima seção do artigo.

Configuração de autorização no Istio

Para que a autorização funcione, você deve ativar o RBAC para Istio. Para fazer isso, usaremos a seguinte configuração:

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"

Explicação:

1 — habilite o RBAC apenas para serviços e namespaces listados no campo Inclusion;
2 — listamos uma lista dos nossos serviços.

Vamos aplicar a configuração com o seguinte comando:

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

Todos os serviços agora exigem controle de acesso baseado em função. Ou seja, o acesso a todos os serviços é proibido e resultará numa resposta RBAC: access denied. Agora vamos permitir o acesso a usuários autorizados.

Configuração de acesso para usuários regulares

Todos os usuários devem ter acesso aos serviços SA-Fronend e SA-WebApp. Implementado usando os seguintes recursos do Istio:

Função de serviço — determina os direitos que o usuário possui;
ServiceRoleBinding — determina a quem este ServiceRole pertence.

Para usuários comuns, permitiremos o acesso a determinados serviços (função de serviço.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 através regular-user-binding aplique ServiceRole a todos os visitantes da 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"

"Todos os usuários" significa que usuários não autenticados também terão acesso ao SA WebApp? Não, a política verificará a validade do token JWT.

Vamos aplicar as configurações:

$ 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

Configuração de acesso para moderadores

Para moderadores, queremos permitir o acesso a todos os serviços (mod-service-role.yaml):

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

Mas queremos esses direitos apenas para os usuários cujo token de acesso contém reivindicação https://sa.io/group com 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"

Vamos aplicar as configurações:

$ 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

Devido ao armazenamento em cache nos enviados, pode levar alguns minutos para que as regras de autorização entrem em vigor. Você pode então garantir que usuários e moderadores tenham diferentes níveis de acesso.

Conclusão sobre esta parte

Sério, você já viu uma abordagem mais simples, fácil, escalonável e segura para autenticação e autorização?

Apenas três recursos do Istio (RbacConfig, ServiceRole e ServiceRoleBinding) foram necessários para obter controle refinado sobre autenticação e autorização de acesso do usuário final aos serviços.

Além disso, cuidamos dessas questões a partir dos nossos serviços de envio, conseguindo:

reduzindo a quantidade de código genérico que pode conter problemas e bugs de segurança;
reduzindo o número de situações estúpidas em que um endpoint se revelou acessível de fora e se esqueceu de reportá-lo;
eliminando a necessidade de atualizar todos os serviços sempre que uma nova função ou direito é adicionado;
que os novos serviços permaneçam simples, seguros e rápidos.

Jogar aviator online grátis: hack aviator funciona

O Istio permite que as equipes concentrem seus recursos em tarefas críticas para os negócios sem adicionar sobrecarga aos serviços, revertendo-os ao status micro.

O artigo (em três partes) forneceu conhecimentos básicos e instruções práticas prontas para começar a usar o Istio em projetos reais.

De volta aos microsserviços com o Istio. Parte 3