Você está vendo a documentação do Anthos Service Mesh 1.10. Veja uma mais recente ou selecione outra versão disponível:

Anthos Service Mesh, por exemplo: mTLS

No Anthos Service Mesh 1.5 e posterior, o TLS mútuo (mm) automático é ativado por padrão. Com o mTLS automático, um proxy sidecar do cliente detecta automaticamente se o servidor tem um sidecar. O sidecar do cliente envia o mTLS para as cargas de trabalho que têm sidecars e texto simples para as que não têm. No entanto, os serviços aceitam o tráfego de texto simples e mTLS. Ao injetar proxies de arquivo secundário nos seus pods, recomendamos que você também configure os serviços para aceitar apenas o tráfego mTLS.

Com o Anthos Service Mesh, você aplica o mTLS fora do código do aplicativo ao aplicar um único arquivo YAML. O Anthos Service Mesh oferece flexibilidade para aplicar uma política de autenticação a toda a malha de serviço, a um namespace ou a uma carga de trabalho individual.

mTLS mútuo

Custos

Neste tutorial, usamos os seguintes componentes faturáveis do Google Cloud:

Para gerar uma estimativa de custo baseada na projeção de uso deste tutorial, use a calculadora de preços. Novos usuários do Google Cloud podem estar qualificados para uma avaliação gratuita.

Ao concluir este tutorial, exclua os recursos criados para evitar custos contínuos. Para mais informações, consulte Limpeza.

Antes de começar

Neste tutorial, usamos o aplicativo de amostra do Online Boutique (em inglês) para demonstrar como configurar mTLS em um cluster do GKE com o Anthos Service Mesh instalado.

Acessar o Online Boutique

  1. Defina o contexto atual de kubectl no cluster em que você implantou o Online Boutique:

    gcloud container clusters get-credentials CLUSTER_NAME  \
        --project=PROJECT_ID \
        --zone=CLUSTER_LOCATION
    
  2. Receba uma lista dos serviços do Online Boutique:

    kubectl get services -n demo
    

    Observe que frontend-external é um LoadBalancer e tem um endereço IP externo. O aplicativo de amostra inclui um serviço que é um balanceador de carga, por isso, ele pode ser implantado no GKE sem o Anthos Service Mesh.

  3. Acesse o aplicativo no navegador usando o endereço IP externo do serviço frontend-external:

    http://FRONTEND_EXTERNAL_IP/
    
  4. O Anthos Service Mesh fornece um gateway de entrada padrão chamado istio-ingressgateway. Também é possível acessar a Online Boutique usando o endereço IP externo da istio-ingressgateway. Consulte o IP externo do istio-ingressgateway:

    kubectl get service istio-ingressgateway -n istio-system
    
  5. Abra outra guia no navegador e acesse o aplicativo usando o endereço IP externo de istio-ingressgateway:

    http://INGRESS_GATEWAY_EXTERNAL_IP/
    
  6. Execute o seguinte comando para curl, o serviço frontend com HTTP simples de outro pod no namespace demo.

    kubectl exec \
      $(kubectl get pod -l app=productcatalogservice -n demo -o jsonpath={.items..metadata.name}) \
      -c istio-proxy -n demo -- \
      curl http://frontend:80/ -o /dev/null -s -w '%{http_code}\n'
    

    Sua solicitação é bem-sucedida com o status 200 porque, por padrão, são aceitos tráfego TLS e de texto simples.

Ativar o TLS mútuo por namespace

Você impõe o mTLS aplicando uma política PeerAuthentication com kubectl.

  1. Aplique a seguinte política de autenticação para configurar todos os serviços no namespace demo, de maneira apenas mTLS seja aceito:

    kubectl apply -f - <<EOF
    apiVersion: "security.istio.io/v1beta1"
    kind: "PeerAuthentication"
    metadata:
      name: "namespace-policy"
      namespace: "demo"
    spec:
      mtls:
        mode: STRICT
    EOF
    

    Resposta esperada:

    peerauthentication.security.istio.io/namespace-policy created

    A linha mode: STRICT no YAML configura os serviços para aceitar apenas mTLS. Por padrão, o mode é PERMISSIVE, que configura os serviços para aceitar texto simples e mTLS.

  2. Vá para a guia no seu navegador que acessa o Online Boutique usando o endereço IP externo do serviço frontend-external e atualize a página. O navegador exibirá o seguinte erro:

    não é possível acessar o site

    A atualização da página faz com que o texto simples seja enviado para o serviço frontend. Devido à política de autenticação STRICT, o proxy sidecar bloqueia a solicitação para o serviço.

  3. No seu navegador, vá para a guia que dá acesso ao Online Boutique usando o endereço IP externo de istio-ingressgateway e atualize a página, que é exibida. Quando você acessa o Online Boutique usando o istio-ingressgateway, a solicitação segue o seguinte caminho:

    mTLS mútuo

    Fluxo de autenticação do mTLS:

    1. O navegador envia ao servidor uma solicitação HTTP de texto simples.
    2. O contêiner de proxy istio-ingressgateway intercepta a solicitação.
    3. O proxy istio-ingressgateway executa um handshake de TLS com o proxy do lado do servidor (neste exemplo, o serviço de front-end). Esse handshake inclui uma troca de certificados. Esses certificados são pré-carregados nos contêineres de proxy pelo Anthos Service Mesh.
    4. O proxy istio-ingressgateway executa uma verificação de nomenclatura segura no certificado do servidor, verificando se uma identidade autorizada está em execução no servidor.
    5. Os proxies istio-ingressgateway e de servidor estabelecem uma conexão TLS mútua, e o proxy do servidor encaminha a solicitação para o contêiner do aplicativo de servidor (o serviço de front-end).
  4. Execute o seguinte comando para curl, o serviço frontend com HTTP simples de outro pod no namespace demo.

    kubectl exec \
      $(kubectl get pod -l app=productcatalogservice -n demo -o jsonpath={.items..metadata.name}) \
      -c istio-proxy -n demo -- \
      curl http://frontend:80/ -o /dev/null -s -w '%{http_code}\n'
    

    Sua solicitação falha porque todos os serviços no namespace demo estão definidos como STRICT mTLS, e o proxy secundário bloqueia a solicitação para o serviço.

    Resposta esperada:

    000
    command terminated with exit code 56

Ver o status de mTLS

Você pode ver o status dos recursos de segurança do Anthos, incluindo políticas de autenticação, no Console do Google Cloud.

  1. No Console do Cloud, acesse a página Segurança do Anthos.

    Acessar a segurança do Anthos

  2. Selecione o projeto do Cloud na lista suspensa na barra de menus.

    O Resumo da política exibe o status da segurança do aplicativo, incluindo o mTLS.

  3. Clique em Auditoria de políticas para ver os status de política de carga de trabalho de cada cluster e namespace. No card de status do mTLS é fornecida uma visão geral. Na lista de Cargas de trabalho, são exibidos os status do mTLS de cada carga de trabalho.

    todos os serviços mtls rigorosos

Encontrar e excluir políticas de autenticação

  1. Para uma lista de todas as políticas PeerAuthentication na malha de serviço:

    kubectl get peerauthentication --all-namespaces
    
  2. Exclua a política de autenticação:

    kubectl delete peerauthentication -n demo namespace-policy
    

    Resposta esperada:

    peerauthentication.security.istio.io "namespace-policy" deleted
  3. Acesse o Online Boutique usando o endereço IP externo do serviço frontend-external e atualize a página. A página é exibida conforme o esperado.

  4. Execute o seguinte comando para curl, o serviço frontend com HTTP simples de outro pod no namespace demo.

    kubectl exec \
      $(kubectl get pod -l app=productcatalogservice -n demo -o jsonpath={.items..metadata.name}) \
      -c istio-proxy -n demo -- \
      curl http://frontend:80/ -o /dev/null -s -w '%{http_code}\n'
    

    Sua solicitação é bem-sucedida com o status 200 porque, por padrão, são aceitos tráfego TLS e de texto simples.

Se você atualizar a página no Console do Cloud que exibe a lista de Cargas de trabalho, ela agora mostra que o status mTLS é Permissive.

Ativar o TLS mútuo por carga de trabalho

Para definir uma política PeerAuthentication para uma carga de trabalho específica, configure a seção selector e especifique os rótulos que correspondem à carga de trabalho pretendida. No entanto, o Anthos Service Mesh não agrega políticas no nível da carga de trabalho para o tráfego mTLS de saída para um serviço. Você precisa configurar uma regra de destino para gerenciar esse comportamento.

  1. Aplique uma política de autenticação a uma carga de trabalho específica no namespace demo: Observe como a política a seguir usa rótulos e seletores para segmentar a implantação específica frontend.

    cat <<EOF | kubectl apply -n demo -f -
    apiVersion: "security.istio.io/v1beta1"
    kind: "PeerAuthentication"
    metadata:
      name: "frontend"
      namespace: "demo"
    spec:
      selector:
        matchLabels:
          app: frontend
      mtls:
        mode: STRICT
    EOF
    

    Resposta esperada:

    peerauthentication.security.istio.io/frontend created
  2. Configure uma regra de destino correspondente:

    cat <<EOF | kubectl apply -n demo -f -
    apiVersion: "networking.istio.io/v1alpha3"
    kind: "DestinationRule"
    metadata:
      name: "frontend"
    spec:
      host: "frontend.demo.svc.cluster.local"
      trafficPolicy:
        tls:
          mode: ISTIO_MUTUAL
    EOF
    

    Resposta esperada:

    destinationrule.networking.istio.io/frontend created
  3. Acesse o Online Boutique usando o endereço IP externo do serviço frontend-external e atualize a página. A página não é exibida porque frontend service está definido como mTLSSTRICT e o proxy sidecar bloqueia a solicitação.

  4. Execute o seguinte comando para curl, o serviço frontend com HTTP simples de outro pod no namespace demo.

    kubectl exec \
      $(kubectl get pod -l app=productcatalogservice -n demo -o jsonpath={.items..metadata.name}) \
      -c istio-proxy -n demo -- \
      curl http://frontend:80/ -o /dev/null -s -w '%{http_code}\n'
    

    Sua solicitação falhou com o código de status 56.

    Se você atualizar a página no Console do Cloud que exibe a lista de Cargas de trabalho, ela agora mostra que o status do mTLS para o serviço frontend é Strict e todos os outros serviços são definidos como Permissive.

    somente o serviço de front-end é um mtls rigoroso

  5. Exclua a política de autenticação e a regra de destino:

    kubectl delete peerauthentication -n demo frontend
    kubectl delete destinationrule -n demo frontend
    

Como aplicar o mTLS em toda a malha

Para impedir que todos os serviços na malha aceitem tráfego de texto simples, defina uma política PeerAuthentication para toda a malha, com o modo mTLS definido como STRICT. A política PeerAuthentication em toda a malha não pode ter um seletor e precisa ser aplicada no namespace raiz, istio-system. Quando você implanta a política, o plano de controle provisiona certificados TLS automaticamente, para que as cargas de trabalho possam ser autenticadas entre si.

  1. Aplique o mTLS em toda a malha:

    kubectl apply -f - <<EOF
    apiVersion: "security.istio.io/v1beta1"
    kind: "PeerAuthentication"
    metadata:
      name: "mesh-wide"
      namespace: "istio-system"
    spec:
      mtls:
        mode: STRICT
    EOF
    

    Resposta esperada:

    peerauthentication.security.istio.io/mesh-wide created

  2. Acesse o Online Boutique usando o endereço IP externo do serviço frontend-external e atualize a página. A página não é exibida.

  3. Execute o seguinte comando para curl, o serviço frontend com HTTP simples de outro pod no namespace demo.

    kubectl exec \
      $(kubectl get pod -l app=productcatalogservice -n demo -o jsonpath={.items..metadata.name}) \
      -c istio-proxy -n demo -- \
      curl http://frontend:80/ -o /dev/null -s -w '%{http_code}\n'
    

    Sua solicitação falhou com o código de status 56.

  4. Exclua a política mesh-wide:

    kubectl delete peerauthentication -n istio-system mesh-wide
    

Se você atualizar a página no Console do Cloud, verá que os detalhes de mTLS de todos os serviços agora exibem Permissive.

Limpeza

Para evitar cobranças na sua conta do Google Cloud pelos recursos usados no tutorial, exclua o projeto que os contém ou mantenha o projeto e exclua os recursos individuais.

  • Se quiser evitar cobranças adicionais, exclua o cluster:

    gcloud container clusters delete  CLUSTER_NAME  \
        --project=PROJECT_ID \
        --zone=CLUSTER_LOCATION
    
  • Se quiser manter o cluster e remover o aplicativo de amostra do Online Boutique:

    kubectl delete namespaces demo
    

A seguir