O Anthos Service Mesh e o Traffic Director agora são Cloud Service Mesh. Para mais informações, consulte a Visão geral do Cloud Service Mesh.

Esta página foi traduzida pela API Cloud Translation.

Configurar recursos avançados da política de autorização

A política de autorização do Cloud Service Mesh oferece malha, namespace e controle de acesso no nível da carga de trabalho para suas cargas de trabalho na malha. Nesta página, descrevemos detalhes sobre como configurar recursos avançados da política de autorização do Cloud Service Mesh, incluindo o modo de simulação e a geração de registros de negação. Os recursos descritos nesta página pressupõem que você esteja familiarizado com os conceitos fundamentais da política de autorização descritos na Visão geral da política de autorização.

Modo de teste

A política de autorização do Cloud Service Mesh oferece suporte ao modo de teste, que permite testar uma política de autorização com tráfego de produção real sem aplicá-la. O modo de simulação permite entender melhor o efeito de uma política de autorização antes de aplicá-la. Isso ajuda a reduzir o risco de corromper o 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 alterá-la para o modo de simulação.

Exemplo de modo de simulação

O exemplo a seguir, deny-path-headers, mostra uma política com a anotação dry-run definida como "true. A política de autorização nega as solicitações ao caminho headers e permite todas as outras solicitações.

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 você aplica uma política de autorização no modo de simulação, o Cloud Service Mesh registra o resultado de aplicação no Cloud Logging, mas não aplica a política. A solicitação é sempre permitida e é possível verificar o Explorador de registros para decidir se a política de autorização está funcionando como esperado.

Detalhes da geração de registros de simulação

Depois de aplicar uma política de autorização no modo de simulação, será possível ver os resultados da política no Explorador de registros.

Acessar o Explorador de registros. No seguinte URL, substitua PROJECT_ID pelo ID do projeto:
```
https://console.cloud.google.com/logs/query?project=PROJECT_ID
```
No campo Criador de consultas, insira uma consulta para encontrar a política de autorização do modo de simulação. Na consulta a seguir, substitua NAMESPACE pelo namespace:
```
logName="projects/PROJECT_ID/logs/server-accesslog-stackdriver" labels.destination_namespace="NAMESPACE" labels.dry_run_result="AuthzDenied"
```
Clique em Run query.
Ajuste o intervalo de tempo conforme necessário.

A captura de tela a seguir mostra os rótulos de simulação no registro de tráfego no Explorador de registros após a aplicação da política deny-path-headers de exemplo:

imagem

O modo de simulação é compatível com as políticas de autorização ALLOW e DENY, além dos resultados de simulação do Istio. O Cloud Service Mesh armazena os resultados de simulação para o Cloud Logging nos seguintes rótulos:

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

A tabela a seguir mostra os detalhes que são registrados para uma política de autorização no modo de simulação:

Política de autorização aplicada no modo de simulação	Corresponder resultado	Resultado de simulação	Cloud Logging
Somente a política `DENY`	Sem correspondência	permitido	dry_run_result: "AuthzAllowed"
Somente a política `DENY`	Correspondente	rejeitou	dry_run_result: "AuthzDenied" dry_run_policy_name: . dry_run_policy_rule:
Somente a política `ALLOW`	Sem correspondência	rejeitou	dry_run_result: "AuthzDenied"
Somente a política `ALLOW`	Correspondente	permitido	dry_run_result: "AuthzAllowed" dry_run_policy_name: . dry_run_policy_rule:
As políticas `ALLOW` e `DENY`	Nenhum resultado correspondente	rejeitou	dry_run_result: "AuthzDenied"
	Apenas a política `DENY` correspondente	rejeitou	dry_run_result: "AuthzDenied" dry_run_policy_name: . dry_run_policy_rule:
	Apenas a política `ALLOW` correspondente	permitido	dry_run_result: "AuthzAllowed" dry_run_policy_name: . dry_run_policy_rule:
	Corresponde às duas políticas	rejeitou	dry_run_result: "AuthzDenied" dry_run_policy_name: . dry_run_policy_rule:

Quando tiver certeza sobre o resultado de simulação, desative o modo de simulação usando uma das seguintes abordagens:

Remover completamente a anotação de simulação ou os
Mude o valor da anotação de simulação para false.

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

Registro de negação

A política de autorização negará uma solicitação se ela não for permitida pela política. Para protocolos HTTP (incluindo gRPC), a solicitação é negada com o código de status 403. Para protocolos não HTTP, a conexão é encerrada diretamente. O registro de tráfego do Cloud Logging inclui informações adicionais que são úteis para entender por que o tráfego está sendo negado. Por exemplo, o registro indica quantas solicitações foram negadas pela política de autorização, o que pode ajudar a determinar qual regra de política causou a negação versus as negações do aplicativo de back-end.

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

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 política de autorizaçãoDENY, é possível ver os resultados da política no Explorador de registros.

Acessar o Explorador de registros. No seguinte URL, substitua PROJECT_ID pelo ID do projeto:
```
https://console.cloud.google.com/logs/query?project=PROJECT_ID
```
No campo Query-builder, insira uma consulta para encontrar a política de autorização DENY. Na consulta a seguir, substitua NAMESPACE pelo namespace:
```
logName="projects/PROJECT_ID/logs/server-accesslog-stackdriver" labels.destination_namespace="NAMESPACE" labels.response_details="AuthzDenied"
```
Clique em Run query.
Ajuste o intervalo de tempo conforme necessário.

A captura de tela a seguir mostra uma entrada de registro no Explorador de registros após o exemplo de política deny-path-headers ser aplicada para aplicar a política. Para saber se a política de autorização foi responsável pelo erro 403, observe os rótulos:

imagem

O registro de tráfego do Explorador de registros inclui os seguintes rótulos para a negação de autorização:

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

A seguir

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

kubectl get authorizationpolicy --all-namespaces

Se houver uma política de autorização em vigor, será possível excluí-la com kubectl delete:

kubectl delete authorizationpolicy -n NAMESPACE AUTH_POLICY_NAME

Para mais informações sobre como conseguir o registro de tráfego, consulte Registros de acesso.