Nota perev. : A primeira parte desta série foi dedicada à introdução dos recursos do Istio e à demonstração deles em ação, o segundo ao roteamento e gerenciamento de tráfego de rede bem ajustados. Agora falaremos sobre segurança: para demonstrar as funções básicas associadas a ele, o autor usa o serviço de identidade Auth0, mas outros provedores podem ser configurados por analogia com ele.Montamos um cluster Kubernetes no qual o exemplo de aplicativo de microsserviço Istio e Sentiment Analysis foi implantado - foi assim que as capacidades do Istio foram demonstradas.
Com o Istio, conseguimos manter os serviços de tamanho pequeno, pois eles não precisam implementar "camadas" como tentativas, Retouts, Timeouts, Disjuntores, Rastreio, Monitoramento . Além disso, usamos técnicas avançadas de teste e implantação: teste A / B, espelhamento e lançamentos de canários.
No novo material, trataremos das camadas finais no caminho para o valor comercial: autenticação e autorização - e no Istio isso é um verdadeiro prazer!
Autenticação e autorização no Istio
Eu nunca teria acreditado que me inspiraria na autenticação e autorização. O que o Istio pode oferecer do ponto de vista tecnológico para tornar esses tópicos fascinantes e ainda mais, para que eles também o inspirem?
A resposta é simples: o Istio transfere a responsabilidade por esses recursos dos seus serviços para os proxies do Envoy. Quando as solicitações chegam aos serviços, elas já estão autenticadas e autorizadas, então você só precisa escrever um código útil para os negócios.
Parece bom? Vamos olhar para dentro!
Autenticação com Auth0
Usaremos o Auth0 como servidor de controle de identidade e acesso, que possui uma versão de teste, que é intuitiva de usar e eu gosto disso. No entanto, os mesmos princípios podem ser aplicados a qualquer outra
implementação do OpenID Connect : KeyCloak, IdentityServer e muitos outros.
Primeiro, vá para o
Portal Auth0 com sua conta, crie um inquilino
(inquilino - "inquilino", unidade lógica de isolamento) para obter mais detalhes, consulte a documentação - aprox. Transl.) E vá para
Aplicativos> Aplicativo padrão , escolhendo
Domínio , conforme mostrado na captura de tela abaixo :
Especifique este domínio no
resource-manifests/istio/security/auth-policy.yaml (
origem ):
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 esse recurso, o Pilot
(um dos três componentes básicos do Control Plane no Istio - aprox. Transl.) Configura os Envoys para autenticar solicitações antes de redirecioná-las para os serviços:
sa-web-app e
sa-feedback . Ao mesmo tempo, a configuração não se aplica aos Envoys do
sa-frontend , permitindo que deixemos o front-end não autenticado. Para aplicar uma 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 ela termina no status
401 Não autorizado . Agora redirecionamos os usuários front-end para autenticação com Auth0.
Solicitar autenticação com Auth0
Para autenticar solicitações de usuário final, você precisa criar uma API em Auth0 que represente serviços autenticados (revisões, detalhes e classificações). Para criar uma API, acesse
Portal Auth0> APIs> Criar API e preencha o formulário:
As informações importantes aqui são o
identificador , que usaremos mais adiante no script. Vamos escrever para nós mesmos assim:
- Público - alvo : {YOUR_AUDIENCE}
Os detalhes restantes que precisamos estão localizados no Portal Auth0 na seção
Aplicativos - selecione
Aplicativo de Teste (ele é criado automaticamente com a API).
Aqui escrevemos:
- Domínio : {YOUR_DOMAIN}
- ID do cliente : {YOUR_CLIENT_ID}
Role no
aplicativo de teste até a caixa de texto URLs de retorno de chamada permitidos (URLs permitidos para o retorno de chamada), na qual indicamos o URL para o qual a chamada deve ser enviada após a conclusão da autenticação. No nosso caso, é:
http://{EXTERNAL_IP}/callback
E para
URLs de logoff permitido (
URLs permitidos para fazer logout), adicione:
http://{EXTERNAL_IP}/logout
Vamos para o frontend.
Atualização de front-end
Alterne para o ramo
[istio-mastery] repositório
[istio-mastery] . Nesse encadeamento, o código de front-end é alterado para redirecionar os usuários para Auth0 para autenticação e usar o token JWT em solicitações para outros serviços. O último é implementado da seguinte forma (
App.js ):
analyzeSentence() { fetch('/sentiment', { method: 'POST', headers: { 'Content-Type': 'application/json', 'Authorization': `Bearer ${auth.getAccessToken()}`
Para converter o frontend em usar dados do inquilino em Auth0, abra
sa-frontend/src/services/Auth.js e substitua os valores que escrevemos acima (
Auth.js ):
const Config = { clientID: '{YOUR_CLIENT_ID}', domain:'{YOUR_DOMAIN}', audience: '{YOUR_AUDIENCE}', ingressIP: '{EXTERNAL_IP}'
O aplicativo está pronto. Indique seu ID do Docker 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 app! Você será redirecionado para o Auth0, onde precisará fazer login (ou registrar-se), após o qual será enviado de volta à página a partir da qual as solicitações já autenticadas serão feitas. Se você tentar os comandos curl mencionados nas primeiras partes do artigo, receberá um
Código de Status 401 , que indica 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 é o usuário, mas para descobrir a que ele tem acesso, é necessária autorização. O Istio também oferece ferramentas para isso.
Como exemplo, criaremos dois grupos de usuários (veja o diagrama abaixo):
- Usuários (usuários) - com acesso apenas aos serviços SA-WebApp e SA-Frontend;
- Moderadores - com acesso aos três serviços.
Conceito de autorizaçãoPara criar esses grupos, usaremos a extensão de autorização Auth0 e usaremos o Istio para fornecer a eles diferentes níveis de acesso.
Instalação e configuração da autorização Auth0
No portal Auth0, vá para
Extensões e instale a
Autorização Auth0 . Após a instalação, vá para a
Extensão de autorização e, em seguida, para a configuração do inquilino, clicando no canto superior direito e selecionando a opção de menu apropriada
(Configuração) . Ative
Grupos e clique no botão
Publicar regra .
Criação de grupo
Na extensão de autorização, vá para
grupos e crie um grupo de
moderadores . Como consideraremos todos os usuários autenticados como comuns, não há necessidade de criar um grupo adicional para eles.
Selecione o grupo
Moderadores , clique em
Adicionar membros , adicione sua conta principal. Deixe alguns usuários sem nenhum grupo para garantir que o acesso seja negado a eles. (Novos usuários podem ser criados manualmente através do
Portal Auth0> Usuários> Criar Usuário .)
Adicionar reivindicação de grupo ao token de acesso
Os usuários são adicionados aos grupos, mas essas informações devem ser refletidas nos tokens de acesso. Para estar em conformidade com o OpenID Connect e, ao mesmo tempo, retornar os grupos de que precisamos, o token precisará adicionar sua
reivindicação personalizada . É implementado através das regras de Auth0.
Para criar uma regra, acesse o Portal Auth0 para
Regras , clique em
Criar regra e selecione uma regra vazia nos modelos.
Copie o código abaixo e salve-o como a 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 (em seu espaço de nome, conforme exigido por Auth0).
Volte para a página
Regras e verifique se você tem duas regras escritas na seguinte ordem:
- auth0-autorização-extensão
- Adicionar reivindicação de grupo
A ordem é importante porque o campo do grupo recebe assincronamente a
regra auth0-autorização-extensão e é adicionada como uma declaração pela segunda regra. O resultado é um token de acesso:
{ "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 tópico da próxima seção do artigo.
Configuração de autorização do Istio
Para que a autorização funcione, você deve ativar o RBAC para Istio. Para fazer isso, use 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ções:
- 1 - habilitar o RBAC apenas para serviços e espaços de nomes listados no campo
Inclusion ; - 2 - liste a lista de nossos serviços.
Nós aplicamos a configuração com este comando:
$ kubectl apply -f resource-manifests/istio/security/enable-rbac.yaml rbacconfig.rbac.istio.io/default created
Agora todos os serviços exigem controle de acesso baseado em função. Em outras palavras, o acesso a todos os serviços é negado e resultará em uma resposta do
RBAC: access denied . Agora permita 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-Frontend e SA-WebApp. Implementado usando os seguintes recursos do Istio:
- ServiceRole - define os direitos que o usuário possui;
- ServiceRoleBinding - Determina a quem esse ServiceRole pertence.
Para usuários comuns, permita o acesso a determinados serviços (
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: ["*"]
E por meio
regular-user-binding aplique um ServiceRole a todos os visitantes da página (
regular-user-service-function-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 terão acesso ao SA WebApp? Não, a política verificará a validade do token JWT.
Aplique a configuração:
$ 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 habilitar 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 tem uma reivindicação
https://sa.io/group com o 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"
Aplique a configuração:
$ 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 em enviados, pode levar alguns minutos para que as regras de autorização entrem em vigor. Depois disso, você pode garantir que usuários e moderadores tenham níveis de acesso diferentes.
Conclusão sobre esta parte
Bem, falando sério: você já viu uma abordagem mais simples, sem esforço, escalável e segura para autenticação e autorização?
Apenas três recursos do Istio (RbacConfig, ServiceRole e ServiceRoleBinding) foram necessários para obter um controle mais preciso da autenticação e autorização do acesso do usuário final aos serviços.
Além disso, resolvemos esses problemas de nossos serviços no enviado, conseguindo:
- Reduzir a quantidade de código de amostra que pode incluir problemas e bugs de segurança;
- reduzindo o número de situações estúpidas nas quais um ponto final se tornou acessível a partir do exterior e esqueceu de denunciá-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.
Conclusão
O Istio permite que as equipes concentrem seus recursos em tarefas essenciais aos negócios sem adicionar sobrecarga aos serviços, retornando-os ao status micro.
O artigo (em três partes) forneceu conhecimentos básicos e instruções práticas prontas para iniciar o trabalho com o Istio em projetos reais.
PS do tradutor
Leia também em nosso blog: