Todos os produtos
Search

Este produto

    :Políticas de autorização de Camada 7 para proxies waypoint

    Central de documentação

    :Políticas de autorização de Camada 7 para proxies waypoint

    Última atualização: Jul 04, 2026

    No modo Ambient Mesh, os ztunnels processam o tráfego de Camada 4 em cada nó, enquanto os proxies waypoint tomam as decisões de Camada 7. Ao implantar um proxy waypoint para um serviço, o ztunnel encaminha todo o tráfego desse serviço para o waypoint e deixa de aplicar suas próprias políticas de autorização. Qualquer política de autorização de Camada 7 deve ter como alvo o proxy waypoint, e não o pod da aplicação.

    Este documento demonstra cenários comuns de autorização de Camada 7 em proxies waypoint no Service Mesh (ASM) v1.18, incluindo controle de acesso baseado em IP, namespace, host e método HTTP.

    Como a autorização funciona com proxies waypoint

    Sem um proxy waypoint, os ztunnels aplicam autorização apenas na Camada 4 (portas, endereços IP, identidades). Após implantar um proxy waypoint para um serviço:

    1. O ztunnel delega todas as decisões de autorização desse serviço ao proxy waypoint e permite que o tráfego do waypoint passe incondicionalmente.

    2. As políticas de autorização que usam selector para corresponder ao pod da aplicação (direcionadas ao ztunnel) são ignoradas.

    3. As políticas de autorização devem usar selector com o rótulo istio.io/gateway-name para direcionar ao proxy waypoint.

    O proxy waypoint pode então aplicar políticas de Camada 7 com base em atributos HTTP, como hosts, caminhos, métodos e cabeçalhos. Quando uma solicitação é negada, o waypoint retorna RBAC: access denied com status HTTP 403.

    Pré-requisitos

    Antes de começar, verifique se você tem:

    • Uma instância do ASM executando v1.18

    • Um gateway de entrada e aplicações de amostra implantadas com recursos básicos verificados. Para obter detalhes, consulte os pré-requisitos e a Etapa 1 em Primeiros passos

    Limitações

    Restrição Detalhes
    Sem autorização personalizada O campo action não pode ser definido como CUSTOM. Os proxies waypoint não são compatíveis com serviços de autorização externos.
    Sem ipBlocks na origem O campo ipBlocks não é compatível com a especificação source. Use remoteIpBlocks para corresponder a endereços IP de clientes.
    Políticas do ztunnel ignoradas Após um proxy waypoint ser implantado para um serviço, o ztunnel correspondente permite que todo o tráfego do waypoint passe. As políticas de autorização devem estar vinculadas ao proxy waypoint.

    Implantar um proxy waypoint

    Implante um proxy waypoint para o serviço productpage antes de executar os exemplos.

    1. Implante o proxy waypoint:

      istioctl x waypoint apply --service-account bookinfo-productpage

    2. Verifique se o pod do proxy waypoint está em execução:

      kubectl get pod --show-labels | grep waypoint

      Saída esperada:

      bookinfo-productpage-istio-waypoint-6c579dd48d-l****   1/1     Running   0          91s    gateway.istio.io/managed=istio.io-mesh-controller,istio.io/gateway-name=bookinfo-productpage,pod-template-hash=6c579dd48d,service.istio.io/canonical-name=bookinfo-productpage-istio-waypoint,service.istio.io/canonical-revision=latest,sidecar.istio.io/inject=false

    Exemplo 1: Políticas direcionadas ao ztunnel não têm efeito quando um proxy waypoint está implantado

    Uma configuração incorreta comum é aplicar uma política de autorização a um ztunnel quando um proxy waypoint já está implantado para o serviço. Como o ztunnel cede as decisões ao proxy waypoint, a política é completamente ignorada. Este exemplo demonstra primeiro a abordagem incorreta e depois mostra como corrigi-la.

    Direcionar ao ztunnel (incorreto)

    1. Crie um arquivo productpage-viewer.yaml com o seguinte conteúdo.

      Esta política usa selector para corresponder ao pod productpage (ztunnel) e nega o acesso à porta 9080:

      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"

    2. Aplique a política:

      kubectl apply -f productpage-viewer.yaml

    3. Teste o acesso de diferentes origens.

      Pelo gateway de sleep:

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

      Saída:

      <title>Simple Bookstore App</title>

      Pelo gateway de notsleep:

      kubectl exec deploy/notsleep -- curl -s "http://$GATEWAY_HOST/productpage" | grep -o "<title>.*</title>"

      Saída:

      <title>Simple Bookstore App</title>

      Acesso direto de sleep:

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

      Saída:

      command terminated with exit code 56

      Acesso direto de notsleep:

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

      Saída:

      <title>Simple Bookstore App</title>

      Apesar da política DENY na porta 9080, a maioria das solicitações foi bem-sucedida. Compare com a mesma política em Autenticação e autorização de Camada 4 - Exemplo 2, onde nenhum proxy waypoint está implantado e a política bloqueia o tráfego conforme esperado.

      Quando um proxy waypoint está implantado, todas as políticas de autorização direcionadas ao ztunnel são ignoradas. Direcione ao proxy waypoint.

    Direcionar ao proxy waypoint (correto)

    1. Atualize o arquivo productpage-viewer.yaml para direcionar ao proxy waypoint alterando o rótulo selector e reaplique:

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

    2. Teste o acesso novamente.

      Pelo gateway de sleep:

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

      Saída:

      RBAC: access denied%

      Pelo gateway de notsleep:

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

      Saída:

      RBAC: access denied%

      Acesso direto de sleep:

      kubectl exec deploy/sleep -- curl -s http://productpage:9080/

      Saída:

      RBAC: access denied%

      Acesso direto de notsleep:

      kubectl exec deploy/notsleep -- curl -s http://productpage:9080/

      Saída:

      RBAC: access denied%

      Todas as solicitações agora são negadas. O proxy waypoint retorna RBAC: access denied% com um código de status HTTP 403. Isso difere do erro de nível de conexão em Autenticação e autorização de Camada 4, onde os ztunnels aplicam políticas na Camada 4.

    3. Limpe os recursos:

      kubectl delete authorizationpolicy productpage-viewer

    Exemplo 2: Negar acesso de um endereço IP específico

    As políticas de autorização do proxy waypoint não são compatíveis com ipBlocks. Use remoteIpBlocks para corresponder ao endereço IP original do cliente. Configure o campo remoteIpBlocks para corresponder a solicitações que passam pelo gateway.

    1. Crie um arquivo productpage-viewer.yaml que nega o endereço IP do pod sleep:

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

      Substitua ${sleep Pod IP} pelo endereço IP real do pod sleep.

    2. Aplique a política:

      kubectl apply -f productpage-viewer.yaml

    3. Teste o acesso do pod sleep.

      Pelo gateway:

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

      Saída:

      RBAC: access denied%

      Acesso direto:

      kubectl exec deploy/sleep -- curl -s http://productpage:9080/ -I

      Saída:

      HTTP/1.1 403 Forbidden
content-length: 19
content-type: text/plain
date: Fri, 19 Jul 2024 08:17:08 GMT
server: istio-envoy

      O acesso pelo gateway e o acesso direto do pod sleep são negados.

    4. Remova as políticas:

      kubectl delete authorizationpolicy productpage-viewer

    Exemplo 3: Negar acesso de um namespace específico

    Este exemplo bloqueia todo o tráfego originado do namespace istio-system. Como o gateway de entrada é executado em istio-system, as solicitações roteadas pelo gateway são negadas, enquanto as solicitações diretas de pod para pod de outros namespaces ainda são bem-sucedidas.

    1. Crie um arquivo productpage-viewer.yaml:

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

    2. Aplique a política:

      kubectl apply -f productpage-viewer.yaml

    3. Teste o acesso.

      Pelo gateway de sleep:

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

      Saída:

      RBAC: access denied%

      Pelo gateway de notsleep:

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

      Saída:

      RBAC: access denied%

      Acesso direto de sleep:

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

      Saída:

      <title>Simple Bookstore App</title>

      Acesso direto de notsleep:

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

      Saída:

      <title>Simple Bookstore App</title>

      O tráfego roteado pelo gateway é negado porque o gateway é executado no namespace istio-system. O acesso direto de pods em outros namespaces (como default) não é afetado.

    4. Exclua a política:

      kubectl delete authorizationpolicy productpage-viewer

    Exemplo 4: Negar solicitações pelo cabeçalho host

    Este exemplo nega solicitações cujo cabeçalho host seja test.com na porta 9080. Solicitações com outros valores de host passam normalmente.

    1. Crie um arquivo productpage-viewer.yaml:

      apiVersion: security.istio.io/v1beta1
kind: AuthorizationPolicy
metadata:
  name: productpage-viewer
  namespace: default
spec:
  selector:
    matchLabels:
      istio.io/gateway-name: bookinfo-productpage
  action: DENY
  rules:
  - to:
    - operation:
        hosts: ["test.com"]
        ports: ["9080"]

    2. Aplique a política:

      kubectl apply -f productpage-viewer.yaml

    3. Teste o acesso.

      Solicitação com Host: test.com:

      kubectl exec deploy/sleep -- curl -s http://$GATEWAY_HOST/productpage -H "Host: test.com"

      Saída:

      RBAC: access denied%

      Solicitação com Host: test1.com:

      kubectl exec deploy/sleep -- curl -s http://$GATEWAY_HOST/productpage -H "Host: test1.com" -I

      Saída:

      HTTP/1.1 200 OK
content-type: text/html; charset=utf-8
content-length: 5290
server: istio-envoy
date: Tue, 15 Aug 2023 03:39:29 GMT
x-envoy-upstream-service-time: 18

      Apenas o host test.com é negado. Outros valores de host passam normalmente.

    4. Remova os recursos criados:

      kubectl delete authorizationpolicy productpage-viewer

    Exemplo 5: Negar um método HTTP específico em um caminho específico

    Este exemplo bloqueia solicitações HEAD para o caminho /productpage. Solicitações GET para o mesmo caminho e solicitações HEAD para outros caminhos são permitidas.

    1. Crie um arquivo productpage-viewer.yaml:

      apiVersion: security.istio.io/v1beta1
kind: AuthorizationPolicy
metadata:
  name: productpage-viewer
  namespace: default
spec:
  selector:
    matchLabels:
      istio.io/gateway-name: bookinfo-productpage
  action: DENY
  rules:
  - to:
    - operation:
        methods: ["HEAD"]
        paths: ["/productpage"]

    2. Aplique a política:

      kubectl apply -f productpage-viewer.yaml

    3. Teste o acesso.

      Solicitação HEAD para /productpage:

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

      Saída:

      HTTP/1.1 403 Forbidden
content-length: 19
content-type: text/plain
date: Tue, 15 Aug 2023 03:59:37 GMT
server: istio-envoy
x-envoy-upstream-service-time: 0

      Solicitação GET para /productpage:

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

      Saída:

      HTTP/1.1 200 OK
content-type: text/html; charset=utf-8
content-length: 5290
server: istio-envoy
date: Tue, 15 Aug 2023 03:39:29 GMT
x-envoy-upstream-service-time: 18

      Solicitação HEAD para /api/v1/products:

      kubectl exec deploy/sleep -- curl -s http://$GATEWAY_HOST/api/v1/products -I

      Saída:

      HTTP/1.1 200 OK
content-type: text/html; charset=utf-8
content-length: 5290
server: istio-envoy
date: Tue, 15 Aug 2023 03:39:29 GMT
x-envoy-upstream-service-time: 18

      Apenas as solicitações HEAD para /productpage são negadas. A política não afeta outros métodos ou caminhos.

    4. Exclua os recursos:

      kubectl delete authorizationpolicy productpage-viewer

    Próximas etapas