Configure funcionalidades avançadas da política de autorização

A política de autorização da Cloud Service Mesh oferece controlo de acesso ao nível da malha, do espaço de nomes e da carga de trabalho para as suas cargas de trabalho na malha. Esta página descreve detalhes sobre a configuração das funcionalidades avançadas da política de autorização da Cloud Service Mesh, incluindo o modo de teste e o registo de negação. As funcionalidades descritas nesta página pressupõem que conhece os conceitos fundamentais da política de autorização descritos na vista geral da política de autorização.

Modo de execução de ensaio

A política de autorização da Cloud Service Mesh suporta o modo de teste, que lhe permite testar uma política de autorização com tráfego de produção real sem a aplicar. O modo de teste permite-lhe compreender melhor o efeito de uma política de autorização antes de a aplicar. Isto ajuda a reduzir o risco de interrupção do tráfego de produção causado por uma política de autorização incorreta.

Use a anotação "istio.io/dry-run": "true" na política de autorização para a alterar para o modo de execução de ensaio.

Exemplo de modo de execução de ensaio

O exemplo seguinte, deny-path-headers, mostra uma política com a anotação dry-run definida como "true. A política de autorização recusa pedidos ao caminho headers e permite todos os outros pedidos.

apiVersion: security.istio.io/v1beta1
kind: AuthorizationPolicy
metadata:
  name: deny-path-headers
  annotations:
    "istio.io/dry-run": "true"
spec:
  selector:
    matchLabels:
      app: httpbin
  action: DENY
  rules:
  - to:
    - operation:
        paths: ["/headers"]

Quando aplica uma política de autorização no modo de teste, o Cloud Service Mesh regista o resultado da aplicação no Cloud Logging, mas não aplica a política. O pedido é sempre permitido e pode verificar o Explorador de registos para decidir se a política de autorização está a funcionar conforme esperado.

Detalhes do registo de execução de ensaio

Depois de aplicar uma política de autorização no modo de teste, pode ver os resultados da política no Explorador de registos.

Aceda ao Explorador de registos. No URL seguinte, substitua PROJECT_ID pelo ID do seu projeto:
```
https://console.cloud.google.com/logs/query?project=PROJECT_ID
```
No campo Criador de consultas, introduza uma consulta para encontrar a política de autorização do modo de teste de execução. Na consulta seguinte, substitua NAMESPACE pelo seu espaço de nomes:
```
logName="projects/PROJECT_ID/logs/server-accesslog-stackdriver" labels.destination_namespace="NAMESPACE" labels.dry_run_result="AuthzDenied"
```
Clique em Executar consulta.
Ajuste o intervalo de tempo conforme necessário.

A captura de ecrã seguinte mostra as etiquetas de teste de execução no registo de tráfego no Logs Explorer após a aplicação da política de exemplo deny-path-headers:

imagem

O modo de execução de ensaio suporta políticas de autorização ALLOW e DENY, além dos resultados de execução de ensaio do Istio. O Cloud Service Mesh armazena os resultados da execução de teste no Cloud Logging nas seguintes etiquetas:

dry_run_result: o resultado da execução de teste é "AuthzAllowed" ou "AuthzDenied".
dry_run_policy_name: o espaço de nomes e o nome da política de autorização correspondente que toma a decisão de execução de ensaio.
dry_run_policy_rule: o índice da regra da política de autorização correspondente que toma a decisão de execução de ensaio.

A tabela seguinte mostra os detalhes registados para uma política de autorização no modo de teste:

Política de autorização aplicada no modo de execução de ensaio	Resultado da correspondência	Resultado do teste de execução	Cloud Logging
Apenas política de `DENY`	Sem correspondência	permitido	dry_run_result: "AuthzAllowed"
Apenas política de `DENY`	Com correspondência	rejeitado	dry_run_result: "AuthzDenied" dry_run_policy_name: . dry_run_policy_rule:
Apenas política de `ALLOW`	Sem correspondência	rejeitado	dry_run_result: "AuthzDenied"
Apenas política de `ALLOW`	Com correspondência	permitido	dry_run_result: "AuthzAllowed" dry_run_policy_name: . dry_run_policy_rule:
Política `ALLOW` e `DENY`	Nenhuma correspondência	rejeitado	dry_run_result: "AuthzDenied"
	Apenas política `DENY` correspondente	rejeitado	dry_run_result: "AuthzDenied" dry_run_policy_name: . dry_run_policy_rule:
	Apenas política `ALLOW` correspondente	permitido	dry_run_result: "AuthzAllowed" dry_run_policy_name: . dry_run_policy_rule:
	Correspondeu a ambas as políticas	rejeitado	dry_run_result: "AuthzDenied" dry_run_policy_name: . dry_run_policy_rule:

Quando tiver confiança no resultado do teste de execução, pode desativar o modo de teste de execução usando uma das seguintes abordagens:

Remover completamente a anotação de teste; ou
Altere o valor da anotação de teste de execução para false.

Depois de aplicar a política com o modo de teste desativado, o Cloud Service Mesh aplica a política.

Registo de recusas

A política de autorização recusa um pedido se não for permitido pela política. Para protocolos HTTP (incluindo gRPC), o pedido é recusado com o código de estado 403. Para protocolos não HTTP, a ligação é terminada diretamente. O registo de tráfego do Cloud Logging inclui informações adicionais úteis para compreender por que motivo o tráfego está a ser recusado. Por exemplo, o registo indica quantos pedidos são recusados pela política de autorização, o que pode ajudar a determinar que regra da política causou a recusa em comparação com as recusas da aplicação de back-end.

No exemplo seguinte, a anotação dry-run está definida como "false. Quando aplica a política de autorização DENY, o Cloud Service Mesh aplica-a.

apiVersion: security.istio.io/v1beta1
kind: AuthorizationPolicy
metadata:
  name: deny-path-headers
  annotations:
    "istio.io/dry-run": "false"
spec:
  selector:
    matchLabels:
      app: httpbin
  action: DENY
  rules:
  - to:
    - operation:
        paths: ["/headers"]

Depois de aplicar uma DENYpolítica de autorização, pode ver os resultados da política no Explorador de registos.

Aceda ao Explorador de registos. No URL seguinte, substitua PROJECT_ID pelo ID do seu projeto:
```
https://console.cloud.google.com/logs/query?project=PROJECT_ID
```
No campo Criador de consultas, introduza uma consulta para encontrar a DENY política de autorização. Na consulta seguinte, substitua NAMESPACE pelo seu espaço de nomes:
```
logName="projects/PROJECT_ID/logs/server-accesslog-stackdriver" labels.destination_namespace="NAMESPACE" labels.response_details="AuthzDenied"
```
Clique em Executar consulta.
Ajuste o intervalo de tempo conforme necessário.

A captura de ecrã seguinte mostra uma entrada de registo no Logs Explorer depois de a política de exemplo deny-path-headers ter sido aplicada para aplicar a política. Pode determinar que a política de autorização foi responsável pelo erro 403 ao analisar as etiquetas:

imagem

O registo de tráfego do Logs Explorer inclui as seguintes etiquetas para a recusa de autorização:

response_details: está definido como "AuthzDenied" se a recusa for causada por uma política de autorização.
policy_name: contém o espaço de nomes e o nome da política de autorização que está a causar a recusa.DENY O valor está no formato de <Namespace>.<Name>, por exemplo, foo.deny-path-headers significa a política de autorização deny-path-headers no espaço de nomes foo.
policy_rule: contém o índice da regra na política de autorização que causa a recusa. Por exemplo, 0 significa a primeira regra na política.

O que se segue?

Para ver uma lista de todas as políticas de autorização na malha de serviços:

kubectl get authorizationpolicy --all-namespaces

Se existir uma política de autorização em vigor, pode eliminá-la com o comando kubectl delete:

kubectl delete authorizationpolicy -n NAMESPACE AUTH_POLICY_NAME

Para mais informações sobre como obter o registo de tráfego, consulte o artigo Registos de acesso.