Como configurar políticas de auditoria em serviços
Uma política de auditoria permite auditar o acesso aos dados dos seus serviços no Cloud 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. Este guia explica como instalar o Cloud Service Mesh para que você possa usar uma política de auditoria.
Como você visualiza os registros de auditoria no Explorador de registros do Cloud Logging no Console do Google Cloud, as políticas de auditoria são compatíveis apenas com as seguintes plataformas:
- GKE no Google Cloud
- Google Distributed Cloud
- Google Distributed Cloud
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 Cloud Service Mesh têm a mesma propriedade de confiabilidade como registros de acesso normais. 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.
Antes de começar
Siga as etapas em Instalar ferramentas dependentes e validar o cluster para:- Instale as ferramentas necessárias
- Fazer o download de
asmcli
- Conceder permissões de administrador de cluster
- Validar o projeto e o cluster
Preparar a configuração do gateway
O Cloud Service Mesh oferece a opção de implantar e gerenciar gateways como parte da malha de serviço. Um gateway descreve um balanceador de carga operando na borda da malha que recebe conexões HTTP/TCP de entrada ou saída. Os gateways são proxies Envoy que fornecem um controle refinado sobre o tráfego que entra e sai da malha.
O app asmcli
não instala o istio-ingressgateway
. Recomendamos
que você implante e gerencie o plano de controle e os gateways separadamente. Para mais informações, consulte
Como instalar e fazer upgrade de gateways.
Como personalizar a instalação do Anthos Service Mesh
Para usar uma política de auditoria, personalize a instalação do Cloud Service Mesh:
Instalações
Siga as etapas em Instale o Cloud Service Mesh. Ao executar
asmcli install
, inclua a seguinte opção:--option audit-authorizationpolicy
Exemplo:
./asmcli install \ --project_id PROJECT_ID \ --cluster_name CLUSTER_NAME \ --cluster_location CLUSTER_LOCATION \ --ca mesh_ca \ --output_dir DIR_PATH \ --enable_all \ --option audit-authorizationpolicy
Especifique outros arquivos de sobreposição necessários para configurar o Cloud Service Mesh.
Conclua a instalação do Cloud Service Mesh para ativar a injeção automática de proxy sidecar nas suas cargas de trabalho. Consulte Implantar e reimplantar cargas de trabalho.
Upgrades
Siga as etapas em Fazer upgrade do Cloud Service Mesh. Ao executar
asmcli install
, inclua a seguinte opção:--option audit-authorizationpolicy
Exemplo:
./asmcli install \ --project_id PROJECT_ID \ --cluster_name CLUSTER_NAME \ --cluster_location CLUSTER_LOCATION \ --ca mesh_ca \ --output_dir DIR_PATH \ --enable_all \ --option audit-authorizationpolicy
Especifique outros arquivos de sobreposição necessários para configurar o Cloud Service Mesh.
Conclua a instalação do Cloud Service Mesh para ativar o arquivo secundário automático de proxy em suas cargas de trabalho. Para upgrades, consulte Mudar para o novo plano de controle
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