Use Layer 4 authorization policies - : Central de Documentação do Alibaba Cloud

O modelo de configuração de autenticação e autorização no modo Ambient Mesh difere do modo Sidecar original devido à separação entre as camadas 4 e 7. Este tópico descreve como usar políticas de autorização da camada 4 em instâncias do Service Mesh (ASM) v1.18.

Pré-requisitos

Um gateway de entrada e os aplicativos relacionados devem estar implantados, com os recursos básicos verificados. Para mais informações, consulte Pré-requisitos e Etapa 1 em Introdução.

Limites

As seguintes restrições se aplicam às políticas de autorização em ztunnels:
- O campo action não aceita o valor CUSTOM, pois os ztunnels não suportam serviços de autorização personalizados.
- Os campos requestPrincipals e remoteIpBlocks não são suportados no campo source.
- Somente o campo ports é suportado no campo operation.
Sem um waypoint proxy implantado, os ztunnels aplicam as políticas de autorização. Nesse cenário, vincule as políticas às cargas de trabalho especificadas.
Como o ztunnel é um proxy da camada 4, ao configurar uma política de autorização com regras da camada 7 nele, apenas as regras da camada 4 entrarão em vigor.

Exemplo 1: Permitir que apenas o gateway e o aplicativo sleep acessem o serviço productpage

Este exemplo verifica se os ztunnels executam corretamente a autorização com base em principals. Para mais informações, consulte Introdução.

Após concluir o teste, execute o comando a seguir para remover a política de autorização:

kubectl delete authorizationpolicy productpage-viewer

Exemplo 2: Proibir o acesso à porta 9080 do serviço productpage

Este cenário valida se os ztunnels aplicam corretamente a autorização com base nas portas de destino.

Crie um arquivo productpage-viewer.yaml com o conteúdo abaixo:

apiVersion: security.istio.io/v1beta1
kind: AuthorizationPolicy
metadata:
 name: productpage-viewer
 namespace: default
spec:
 selector:
   matchLabels:
     app: productpage
 action: DENY
 rules:
 - to:
   - operation:
       ports:
       - "9080"

Conecte-se à instância do ASM via kubectl usando as informações do arquivo kubeconfig e execute o comando a seguir para criar a política de autorização:
```
kubectl apply -f productpage-viewer.yaml
```
Verifique se a política de autorização entrou em vigor.
1. Execute o comando a seguir para testar o acesso:
```
kubectl exec deploy/sleep -- curl -s "http://$GATEWAY_HOST/productpage"
```
  Saída esperada:
```
upstream connect error or disconnect/reset before headers. reset reason: connection termination%
```
2. Execute o comando a seguir para testar o acesso:
```
kubectl exec deploy/notsleep -- curl -s "http://$GATEWAY_HOST/productpage"
```
  Saída esperada:
```
upstream connect error or disconnect/reset before headers. reset reason: connection termination%
```
3. Execute o comando a seguir para testar o acesso:
```
kubectl exec deploy/sleep -- curl -s http://productpage:9080/
```
  Saída esperada:
```
command terminated with exit code 56
```
4. Execute o comando a seguir para testar o acesso:
```
kubectl exec deploy/notsleep -- curl -s http://productpage:9080/ | grep -o "<title>.*</title>"
```
  Saída esperada:
```
command terminated with exit code 56
```
  A saída indica que nenhum pod consegue acessar a porta 9080 do serviço productpage.
  
  Nos dois primeiros testes, as respostas às solicitações de acesso ao serviço productpage pelo gateway retornaram o erro upstream connect error or disconnect/reset before headers. reset reason: connection termination%. Esse erro foi retornado pelo gateway de entrada. Quando o gateway não consegue acessar o serviço productpage (porque o serviço bloqueia o acesso do gateway à porta 9080), ocorre um erro HTTP 503.
  
  As respostas dos dois últimos testes foram command terminated with exit code 56, retornadas pelo comando curl. O comando curl tentou estabelecer uma conexão direta com o serviço productpage, mas falhou. Por isso, nenhum erro HTTP foi reportado, diferentemente do erro observado no acesso via gateway.
Execute o comando a seguir para remover a política de autorização:
```
kubectl delete authorizationpolicy productpage-viewer
```

Exemplo 3: Proibir o endereço IP do pod sleep de acessar o serviço productpage

Este caso testa a capacidade dos ztunnels de aplicar autorização com base nos endereços IP de origem.

Execute o comando a seguir para consultar o endereço IP do pod sleep:

kubectl get pod -o wide | grep sleep

Saída esperada:

notsleep-5fb85fb789-z****         1/1     Running   0          48m   10.0.67.92   cn-hangzhou.10.0.67.41   <none>           <none>
sleep-bc9998558-z****             1/1     Running   0          48m   10.0.67.91   cn-hangzhou.10.0.67.42   <none>           <none>

A saída esperada mostra que o endereço IP do pod sleep neste ambiente de teste é 10.0.67.91. O endereço IP real do pod pode variar em cada ambiente.

Crie um arquivo productpage-viewer.yaml com o conteúdo abaixo para proibir solicitações originadas do endereço IP do pod sleep de acessarem o serviço productpage:

apiVersion: security.istio.io/v1beta1
kind: AuthorizationPolicy
metadata:
 name: productpage-viewer
 namespace: default
spec:
 selector:
   matchLabels:
     app: productpage
 action: DENY
 rules:
 - from:
   - source:
       ipBlocks:
       - ${sleep Pod IP}

Conecte-se à instância do ASM via kubectl usando as informações do arquivo kubeconfig e execute o comando a seguir para criar a política de autorização:
```
kubectl apply -f productpage-viewer.yaml
```
Verifique se a política de autorização entrou em vigor.
1. Execute o comando a seguir para testar o acesso:
```
kubectl exec deploy/sleep -- curl -s "http://$GATEWAY_HOST/productpage" | grep -o "<title>.*</title>"
```
  Saída esperada:
```
<title>Simple Bookstore App</title>
```
2. Execute o comando a seguir para testar o acesso:
```
kubectl exec deploy/notsleep -- curl -s "http://$GATEWAY_HOST/productpage" | grep -o "<title>.*</title>"
```
  Saída esperada:
```
<title>Simple Bookstore App</title>
```
3. Execute o comando a seguir para testar o acesso:
```
kubectl exec deploy/sleep -- curl -s http://productpage:9080/
```
  Saída esperada:
```
command terminated with exit code 56
```
4. Execute o comando a seguir para testar o acesso:
```
kubectl exec deploy/notsleep -- curl -s http://productpage:9080/ | grep -o "<title>.*</title>"
```
  Saída esperada:
```
<title>Simple Bookstore App</title>
```
  A saída indica que, ao implantar apenas ztunnels sem um waypoint proxy, não é possível impedir que o pod sleep acesse o serviço productpage pelo gateway. Isso ocorre porque o campo remoteIpBlocks na política de autorização depende do cabeçalho X-Forwarded-For da solicitação, enquanto o ztunnel opera como um proxy da camada 4.
Execute o comando a seguir para remover a política de autorização:
```
kubectl delete authorizationpolicy productpage-viewer
```

Exemplo 4: Proibir pods no namespace istio-system de acessar o serviço productpage

Este exemplo verifica se os ztunnels aplicam corretamente a autorização baseada em namespaces de origem. O namespace de origem refere-se ao namespace onde o pod inicia a solicitação.

Crie um arquivo productpage-viewer.yaml com o conteúdo abaixo para proibir pods no namespace istio-system de acessar o serviço productpage:

apiVersion: security.istio.io/v1beta1
kind: AuthorizationPolicy
metadata:
 name: productpage-viewer
 namespace: default
spec:
 selector:
   matchLabels:
     app: productpage
 action: DENY
 rules:
 - from:
   - source:
       namespaces:
       - istio-system

Conecte-se à instância do ASM via kubectl usando as informações do arquivo kubeconfig e execute o comando a seguir para criar a política de autorização:
```
kubectl apply -f productpage-viewer.yaml
```

Verifique se a política de autorização entrou em vigor.

Execute o comando a seguir para testar o acesso:

kubectl exec deploy/sleep -- curl -s "http://$GATEWAY_HOST/productpage"

Saída esperada:

upstream connect error or disconnect/reset before headers. reset reason: connection termination%

Execute o comando a seguir para testar o acesso:

kubectl exec deploy/notsleep -- curl -s "http://$GATEWAY_HOST/productpage"

Saída esperada:

upstream connect error or disconnect/reset before headers. reset reason: connection termination%

Execute o comando a seguir para testar o acesso:

kubectl exec deploy/sleep -- curl -s http://productpage:9080/ | grep -o "<title>.*</title>"

Saída esperada:

<title>Simple Bookstore App</title>

Execute o comando a seguir para testar o acesso:
```
kubectl exec deploy/notsleep -- curl -s http://productpage:9080/ | grep -o "<title>.*</title>"
```
Saída esperada:
```
<title>Simple Bookstore App</title>
```
O gateway de entrada está implantado no namespace istio-system. A saída demonstra que, após a criação da política de autorização, os aplicativos sleep e notsleep não conseguem acessar o serviço productpage pelo gateway, mas mantêm o acesso direto ao serviço.

Execute o comando a seguir para remover a política de autorização:
```
kubectl delete authorizationpolicy productpage-viewer
```