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.
Custos
Neste documento, você usará 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.
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.
Se você precisar configurar um cluster do GKE para este tutorial, consulte o Guia de início rápido do Anthos Service Mesh. Nele, você verá como configurar um cluster, instalar o Anthos Service Mesh e implantar o aplicativo de amostra do Online Boutique para o namespace
demo
.Se você tiver um cluster do GKE com o Anthos Service Mesh instalado, mas precisar da amostra, consulte Online Boutique para aprender a implantar a amostra no namespace
demo
.Verifique se o faturamento está ativado para seu projeto na nuvem. Saiba como confirmar se o faturamento está ativado para o projeto.
Acessar o Online Boutique
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
Receba uma lista dos serviços do Online Boutique:
kubectl get services -n demo
Observe que
frontend-external
é umLoadBalancer
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.Acesse o aplicativo no navegador usando o endereço IP externo do serviço
frontend-external
:http://FRONTEND_EXTERNAL_IP/
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 daistio-ingressgateway
. Consulte o IP externo doistio-ingressgateway
:kubectl get service istio-ingressgateway -n istio-system
Abra outra guia no navegador e acesse o aplicativo usando o endereço IP externo de
istio-ingressgateway
:http://INGRESS_GATEWAY_EXTERNAL_IP/
Execute o seguinte comando para
curl
, o serviçofrontend
com HTTP simples de outro pod no namespacedemo
.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
.
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, omode
éPERMISSIVE
, que configura os serviços para aceitar texto simples e mTLS.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:A atualização da página faz com que o texto simples seja enviado para o serviço
frontend
. Devido à política de autenticaçãoSTRICT
, o proxy sidecar bloqueia a solicitação para o serviço.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 oistio-ingressgateway
, a solicitação segue o seguinte caminho:Fluxo de autenticação do mTLS:
- O navegador envia ao servidor uma solicitação HTTP de texto simples.
- O contêiner de proxy
istio-ingressgateway
intercepta a solicitação. - 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. - 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. - 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).
Execute o seguinte comando para
curl
, o serviçofrontend
com HTTP simples de outro pod no namespacedemo
.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 comoSTRICT
mTLS, e o proxy secundário bloqueia a solicitação para o serviço.Saída 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.
No console do Google Cloud, acesse a página Segurança do GKE Enterprise.
Selecione o projeto do Google Cloud na lista suspensa na barra de menus.
O Resumo da política exibe o status da segurança do aplicativo, incluindo o mTLS.
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.
Encontrar e excluir políticas de autenticação
Para uma lista de todas as políticas
PeerAuthentication
na malha de serviço:kubectl get peerauthentication --all-namespaces
Exclua a política de autenticação:
kubectl delete peerauthentication -n demo namespace-policy
Resposta esperada:
peerauthentication.security.istio.io "namespace-policy" deleted
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.Execute o seguinte comando para
curl
, o serviçofrontend
com HTTP simples de outro pod no namespacedemo
.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 Google Cloud que exibe a
lista Cargas de trabalho, ela mostrará agora que o status do 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.
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íficafrontend
.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
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
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 porquefrontend service
está definido como mTLSSTRICT
e o proxy sidecar bloqueia a solicitação.Execute o seguinte comando para
curl
, o serviçofrontend
com HTTP simples de outro pod no namespacedemo
.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 Google Cloud que exibe a lista Cargas de trabalho, ela mostrará que o status mTLS do serviço
frontend
éStrict
e todos os outros serviços estão definidos comoPermissive
.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.
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
Saída esperada:
peerauthentication.security.istio.io/mesh-wide created
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.Execute o seguinte comando para
curl
, o serviçofrontend
com HTTP simples de outro pod no namespacedemo
.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
.Exclua a política
mesh-wide
:kubectl delete peerauthentication -n istio-system mesh-wide
Se você atualizar a página no console do Google Cloud, verá que os detalhes do mTLS
de todos os serviços agora exibem Permissive
.
Limpar
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
- Para obter um guia geral sobre como configurar políticas
PeerAuthentication
, consulte Como configurar a segurança de transporte.