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
:
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" |
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" |
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 DENY
polí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, substituaNAMESPACE
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:
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çãodeny-path-headers
no espaço de nomesfoo
. - 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 Aceder aos registos no Cloud Logging.