Cloud Service Mesh por exemplo: autorização

Neste tutorial, vai saber o que é a autorização e como ativá-la com a Cloud Service Mesh numa aplicação de exemplo para saber como ativar políticas de autorização para os seus microsserviços. Cria um AuthorizationPolicy para DENY aceder a um microsserviço e, em seguida, cria um AuthorizationPolicy para ALLOW aceder especificamente a um microsserviço.

O que é a autorização?

A autenticação valida uma identidade. Este serviço é quem diz ser? A autorização valida a autorização. Este serviço tem permissão para o fazer? A identidade é fundamental para esta ideia. Com a malha de serviços na nuvem, a AuthorizationPolicies permite que a comunicação de carga de trabalho para carga de trabalho na sua malha seja controlada para melhorar a segurança e o acesso.

Numa arquitetura de microsserviços, em que as chamadas são feitas através de limites de rede, as regras de firewall tradicionais baseadas em IP não são frequentemente adequadas para proteger o acesso entre cargas de trabalho. Com o Cloud Service Mesh, pode definir regras de autorização para:

  • Controlar o acesso a cargas de trabalho na sua malha, seja de carga de trabalho para carga de trabalho ou de utilizador final para carga de trabalho
  • Defina políticas de forma geral ou detalhada, consoante as suas necessidades. Para ver uma explicação detalhada sobre a configuração de políticas e práticas recomendadas, consulte o artigo Autorização com a malha de serviços na nuvem.

Implemente um gateway de entrada

  1. Defina o contexto atual de kubectl para o cluster:

    gcloud container clusters get-credentials CLUSTER_NAME  \
--project=PROJECT_ID \
--zone=CLUSTER_LOCATION

  2. Crie um espaço de nomes para o gateway de entrada:

    kubectl create namespace asm-ingress

  3. Ative o espaço de nomes para injeção. Os passos dependem do tipo de Cloud Service Mesh (gerido ou no cluster):

    Gerido

    Aplique a etiqueta de revisão asm-managed ao espaço de nomes:

    kubectl label namespace asm-ingress \
  istio-injection- istio.io/rev=asm-managed --overwrite

    Esta etiqueta corresponde ao canal de lançamento gerido atual do Cloud Service Mesh para a versão do Cloud Service Mesh.

    No cluster

    1. Use o seguinte comando para localizar a etiqueta de revisão em istiod:

      kubectl get deploy -n istio-system -l app=istiod -o \
  jsonpath={.items[*].metadata.labels.'istio\.io\/rev'}'{"\n"}'

    2. Aplique a etiqueta de revisão ao espaço de nomes. No comando seguinte, REVISION é o valor da etiqueta de revisão istiod que anotou no passo anterior.

      kubectl label namespace asm-ingress \
  istio-injection- istio.io/rev=REVISION --overwrite

  4. Implemente o gateway de exemplo no repositório anthos-service-mesh-samples:

    kubectl apply -n asm-ingress \
-f docs/shared/asm-ingress-gateway

    Resultado esperado:

    serviceaccount/asm-ingressgateway configured
service/asm-ingressgateway configured
deployment.apps/asm-ingressgateway configured
gateway.networking.istio.io/asm-ingressgateway configured

Implemente a aplicação de exemplo Online Boutique

  1. Se ainda não o fez, defina o contexto atual de kubectl para o cluster:

    gcloud container clusters get-credentials CLUSTER_NAME  \
--project=PROJECT_ID \
--zone=CLUSTER_LOCATION

  2. Crie o espaço de nomes para a aplicação de exemplo:

    kubectl create namespace onlineboutique

  3. Etiquete o espaço de nomes onlineboutique para injetar automaticamente proxies Envoy. Siga os passos para ativar a injeção automática de sidecar.

  4. Implemente a app de exemplo, o VirtualService para o front-end e as contas de serviço para as cargas de trabalho. Para este tutorial, vai implementar a Online Boutique, uma app de demonstração de microsserviços.

    kubectl apply \
-n onlineboutique \
-f docs/shared/online-boutique/virtual-service.yaml
kubectl apply \
-n onlineboutique \
-f docs/shared/online-boutique/service-accounts

Veja os seus serviços

  1. Veja os pods no espaço de nomes onlineboutique:

    kubectl get pods -n onlineboutique

    Resultado esperado:

    NAME                                     READY   STATUS    RESTARTS   AGE
adservice-85598d856b-m84m6               2/2     Running   0          2m7s
cartservice-c77f6b866-m67vd              2/2     Running   0          2m8s
checkoutservice-654c47f4b6-hqtqr         2/2     Running   0          2m10s
currencyservice-59bc889674-jhk8z         2/2     Running   0          2m8s
emailservice-5b9fff7cb8-8nqwz            2/2     Running   0          2m10s
frontend-77b88cc7cb-mr4rp                2/2     Running   0          2m9s
loadgenerator-6958f5bc8b-55q7w           2/2     Running   0          2m8s
paymentservice-68dd9755bb-2jmb7          2/2     Running   0          2m9s
productcatalogservice-84f95c95ff-c5kl6   2/2     Running   0          114s
recommendationservice-64dc9dfbc8-xfs2t   2/2     Running   0          2m9s
redis-cart-5b569cd47-cc2qd               2/2     Running   0          2m7s
shippingservice-5488d5b6cb-lfhtt         2/2     Running   0          2m7s

    Todos os pods da sua aplicação devem estar em funcionamento, com um 2/2 na coluna READY. Isto indica que os pods têm um proxy sidecar do Envoy injetado com êxito. Se não for apresentado 2/2 após alguns minutos, visite o guia de resolução de problemas.

  2. Obtenha o IP externo e defina-o para uma variável:

    kubectl get services -n asm-ingress
export FRONTEND_IP=$(kubectl --namespace asm-ingress \
get service --output jsonpath='{.items[0].status.loadBalancer.ingress[0].ip}' \
)

    Vê um resultado semelhante ao seguinte:

    NAME                   TYPE           CLUSTER-IP      EXTERNAL-IP   PORT(S)                                      AGE
asm-ingressgateway   LoadBalancer   10.19.247.233   35.239.7.64   80:31380/TCP,443:31390/TCP,31400:31400/TCP   27m

  3. Visite o endereço EXTERNAL-IP no seu navegador de Internet. Deve ver a loja Online Boutique no seu navegador.

    Interface de loja online

Autorização DenyAll para uma carga de trabalho

Esta secção adiciona um AuthorizationPolicy para recusar todo o tráfego recebido para o serviço de moeda. AuthorizationPolicies funciona transformando AuthorizationPolicies em configurações legíveis pelo Envoy e aplicando as configurações aos seus proxies sidecar. Isto permite que o proxy Envoy autorize ou recuse pedidos recebidos a um serviço.

  1. Aplique um AuthorizationPolicy ao currencyservice. Repare na correspondência na etiqueta currencyservice no ficheiro YAML.

    kubectl apply -f docs/authorization/currency-deny-all.yaml -n onlineboutique

    apiVersion: security.istio.io/v1beta1
kind: AuthorizationPolicy
metadata:
  name: currency-policy
spec:
  selector:
    matchLabels:
      app: currencyservice

  2. Experimente aceder ao EXTERNAL-IP da sua gateway para ver a Online Boutique no navegador de Internet. Deve ver um erro de autorização (500 Internal Service Error) de currency service.

    authz rbac 500 error

Observe os registos do proxy sidecar

Para ver o que está a ocorrer no proxy sidecar, pode rever os registos no pod.

  1. Obtenha o nome do seu dispositivo currencyservice:

    CURRENCY_POD=$(kubectl get pod -n onlineboutique |grep currency|awk '{print $1}')

  2. Defina o proxy Envoy para permitir registos ao nível do rastreio. Por predefinição, as chamadas de autorização bloqueadas não são registadas:

    kubectl exec -it $CURRENCY_POD -n onlineboutique -c istio-proxy -- curl -X POST "http://localhost:15000/logging?level=trace"

    Resultado esperado: active loggers: admin: trace alternate_protocols_cache: trace ... tracing: trace upstream: trace udp: trace wasm: trace

  3. Use curl para enviar tráfego para o seu EXTERNAL_IP para gerar registos:

    for i in {0..10}; do
curl -s -I $FRONTEND_IP ; done

  4. Veja os registos relacionados com o controlo de acesso baseado em funções (CABF) no seu istio-proxy:

    kubectl logs -n onlineboutique $CURRENCY_POD -c istio-proxy | grep -m5 rbac

    Resultado esperado:

    2022-07-08T14:19:20.442920Z     debug   envoy rbac      checking request: requestedServerName: outbound_.7000_._.currencyservice.onlineboutique.svc.cluster.local, sourceIP: 10.8.8.5:34080, directRemoteIP: 10.8.8.5:34080, remoteIP: 10.8.8.5:34080,localAddress: 10.8.0.6:7000, ssl: uriSanPeerCertificate: spiffe://christineskim-tf-asm./ns/onlineboutique/sa/default, dnsSanPeerCertificate: , subjectPeerCertificate: OU=istio_v1_cloud_workload,O=Google LLC,L=Mountain View,ST=California,C=US, headers: ':method', 'POST'
2022-07-08T14:19:20.442944Z     debug   envoy rbac      enforced denied, matched policy none
2022-07-08T14:19:20.442965Z     debug   envoy http      [C73987][S13078781800499437460] Sending local reply with details rbac_access_denied_matched_policy[none]
  ```

Deve ver uma mensagem enforced denied nos registos a indicar que currencyservice está definido para bloquear pedidos de entrada.

Permita o acesso restrito

Em vez de uma política DENYALL, pode definir o acesso para ser permitido para determinadas cargas de trabalho. Isto é relevante numa arquitetura de microsserviços em que quer garantir que apenas os serviços autorizados podem comunicar entre si.

Nesta secção, vai conceder ao serviço frontend e ao serviço checkout a capacidade de comunicar com o serviço currency.

  1. No ficheiro abaixo, veja que um source.principal específico(cliente) está na lista de autorizações para aceder a currencyservice:
apiVersion: security.istio.io/v1beta1
kind: AuthorizationPolicy
metadata:
  name: currency-policy
spec:
  selector:
    matchLabels:
      app: currencyservice
  rules:
  - from:
    - source:
        principals: ["cluster.local/ns/onlineboutique/sa/frontend"]
  - from:
    - source:
        principals: ["cluster.local/ns/onlineboutique/sa/checkoutservice"]

Aplique a política:

kubectl apply -f docs/authorization/currency-allow-frontend-checkout.yaml -n onlineboutique
  1. Visite EXTERNAL-IP no seu navegador de Internet. Agora, deve conseguir aceder à boutique online.