Uma política de auditoria permite auditar o acesso aos dados dos seus serviços no Anthos Service Mesh. A auditoria dos serviços ajuda a responder perguntas como "quem fez o quê, quando e por quê". Com uma política de auditoria, é possível especificar quando um registro de auditoria é criado e seu conteúdo. É possível visualizar os registros de auditoria no Explorador de registros do Cloud Logging, no Console do Google Cloud. Neste guia, explicamos como instalar o Anthos Service Mesh para o GKE no Google Cloud a fim de usar uma política de auditoria.
Uma política de auditoria estende
AuthorizationPolicy
adicionando uma ação AUDIT
. Ele entra em vigor somente no escopo da política
de destino, que pode ser uma carga de trabalho, um namespace ou toda a malha. As políticas são
ORed
juntas, ou seja, uma solicitação é registrada se alguma política diz isso. Se nenhuma política
de auditoria se aplicar a uma determinada carga de trabalho, nenhum registro de auditoria será gerado para ela.
Veja um exemplo de política de auditoria para auditar todo o acesso WRITE ao
caminho /user/profile/*
em myapi
:
apiVersion: security.istio.io/v1beta1
kind: AuthorizationPolicy
metadata:
namespace: ns1
name: anyname
spec:
selector:
matchLabels:
app: myapi
action: AUDIT
rules:
- to:
- operation:
methods: ["POST", "UPDATE", "DELETE"]
paths: ["/user/profile/*"]
Limitações
- Não há registro de auditoria no gateway de entrada.
- O conteúdo da auditoria não é configurável.
- Atualmente, os registros de auditoria do Anthos Service Mesh têm a mesma propriedade de confiabilidade dos registros de acesso normal. Por exemplo, se um pod de carga de trabalho for reiniciado, alguns registros de auditoria da carga de trabalho, se não persistidos, serão perdidos.
Como personalizar a instalação do Anthos Service Mesh
Para usar uma política de auditoria, personalize a instalação do Anthos Service Mesh:
Siga as etapas em Como instalar o Anthos Service Mesh no GKE para usar um script fornecido pelo Google para instalar o Anthos Service Mesh. Ao executar o script, inclua a seguinte opção:
--option audit-authorizationpolicy
Exemplo:
./install_asm \ --project_id PROJECT_ID \ --cluster_name CLUSTER_NAME \ --cluster_location CLUSTER_LOCATION \ --mode install \ --output_dir DIR_PATH \ --enable_all \ --option audit-authorizationpolicy
Conclua a instalação do Anthos Service Mesh para ativar a injeção automática de proxy sidecar nas suas cargas de trabalho. Para mais detalhes, consulte Como implantar e reimplantar cargas de trabalho.
Como usar os registros de auditoria
Nesta seção, usamos o exemplo do Bookinfo para demonstrar como usar o registro de auditoria.
Implante o aplicativo de amostra Bookinfo no namespace padrão.
Consiga o endereço IP externo do gateway de entrada e envie solicitações ao aplicativo de amostra para gerar tráfego.
No Console do Google Cloud, acesse o menu de navegação
e selecione Logging > Explorador de registros:Selecione um projeto do Google Cloud.
Como você ainda não implantou uma política, não haverá registros de auditoria. O registro de auditoria é diferente do registro de acesso. Para ver registros de acesso
stackdriver
, digite a seguinte consulta no campo Criador de consultas e clique em Executar consulta:logName="projects/PROJECT_ID/logs/server-accesslog-stackdriver"
Para mais informações sobre como usar o Explorador de registros, consulte a Visão geral do Explorador de registros.
Como configurar a política e verificar os registros de auditoria
Esta seção fornece várias opções para auditar o aplicativo Bookinfo. Após implantar a política de auditoria, é possível enviar algumas solicitações e verificar o registro de auditoria no Logs Explorer.
Insira o comando a seguir para receber credenciais de autenticação para interagir com o cluster. Esse comando também define o contexto atual para
kubectl
no cluster.gcloud container clusters get-credentials CLUSTER_NAME \ --project=PROJECT_ID \ --zone=CLUSTER_LOCATION
Aplique a seguinte política de auditoria para auditar as solicitações
GET
no caminho/productpage
:kubectl apply -f - << EOF apiVersion: "security.istio.io/v1beta1" kind: "AuthorizationPolicy" metadata: name: "audit-productpage" namespace: default spec: action: AUDIT rules: - to: - operation: methods: ["GET"] paths: ["/productpage"] EOF
Envie algumas solicitações para o Bookinfo.
No Explorador de registros, digite a seguinte consulta no campo Criador de consultas e clique em Executar consulta:
logName="projects/PROJECT_ID/logs/server-istio-audit-log"
A consulta retorna registros semelhantes aos seguintes:
Aplique a política a seguir se quiser auditar solicitações para o serviço
bookinfo-ratings
. As políticas de auditoria são aditivas. Depois de aplicar a política a seguir, você verá registros de auditoria das solicitações do ProductPage e Ratings.kubectl apply -f - << EOF apiVersion: "security.istio.io/v1beta1" kind: "AuthorizationPolicy" metadata: name: "audit-ratings" namespace: default spec: action: AUDIT rules: - from: - source: principals: ["cluster.local/ns/default/sa/bookinfo-ratings"] to: - operation: methods: ["GET"] EOF
A nova política de auditoria precisa ser propagada antes de entrar em vigor.
Enviar dez ou mais solicitações ao Bookinfo para garantir que você acessou o serviço de avaliações e, em seguida, verifique o registro de auditoria no Explorador de registros. O registro de auditoria é semelhante a este:
Aplique a política a seguir para auditar todos os serviços no namespace padrão.
kubectl apply -f - << EOF apiVersion: security.istio.io/v1beta1 kind: AuthorizationPolicy metadata: namespace: default name: "audit-all" spec: action: AUDIT rules: - {} EOF
Envie mais algumas solicitações ao Bookinfo e verifique o registro de auditoria no Explorador de registros. O registro de auditoria agora grava todas as solicitações:
Se você quiser restringir a política de auditoria para ProductPage e Ratings, exclua a política
audit-all
:kubectl delete authorizationpolicy audit-all -n default
Solução de problemas
Se você não vir registros de auditoria depois de ativar uma política de auditoria, faça o seguinte:
Verifique se há tráfego para o período especificado no Explorador de registros. Se você estiver testando o Bookinfo, poderá enviar solicitações executando o seguinte comando várias vezes:
curl -s http://EXTERNAL_IP/productpage | grep Bookstore
Verifique se há um
AuthorizationPolicy
no gateway de entrada que bloqueia solicitações para o serviço auditado.Verifique os registros de acesso
stackdriver
com o seguinte filtro no Explorador de registros para verificar se suas solicitações chegaram ao aplicativo:logName="projects/PROJECT_ID/logs/server-accesslog-stackdriver"
Para ter certeza de que o Stackdriver está configurado e o registro de auditoria está ativado, copie a configuração do estado
istiod
atual. Na pesquisaconfig_dump
deenable_audit_log
e no nome da política de auditoria.istioctl dashboard envoy POD_NAME.NAMESPACE
Para garantir que suas solicitações correspondam às regras da política de auditoria, verifique os registros de depuração do controle de acesso baseado em papéis (RBAC). Ative o registro de depuração do RBAC com o seguinte comando:
kubectl exec POD_NAME -n NAMESPACE -c istio-proxy -- pilot-agent request POST 'logging?rbac=debug'
Envie algumas solicitações e, em seguida, verifique os registros do pod com o comando
kubectl logs
:kubectl logs POD_NAME -n NAMESPACE -c istio-proxy