Como configurar políticas de auditoria em serviços

Observação: este guia só oferece suporte ao Cloud Service Mesh com APIs do Istio e não oferece suporte às APIs do Google Cloud. Para mais informações, consulte Visão geral do Cloud Service Mesh.

Visualização — Audit policy

Esse recurso está sujeito aos "Termos de ofertas pré-GA" na seção "Termos de Serviço gerais" dos Termos específicos de serviço. Os recursos pré-GA estão disponíveis "no estado em que se encontram" e podem ter suporte limitado. Para mais informações, consulte as descrições da fase de lançamento.

Este tutorial só oferece suporte à implementação do plano de controle no cluster.

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 o conteúdo dos registros. Neste guia, explicamos como instalar o Cloud Service Mesh para 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 (somente software) para VMware
• Google Distributed Cloud (somente software) em bare metal

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 dos 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 Cloud Service Mesh

Para usar uma política de auditoria, personalize a instalação do Cloud Service Mesh:

Instalações

1. Siga as etapas em Instalar 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.

2. 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

1. 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.

2. Conclua a instalação do Cloud Service Mesh para ativar a injeção automática de proxy sidecar nas 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.

1. Implante o aplicativo de amostra Bookinfo no namespace padrão.

2. Consiga o endereço IP externo do gateway de entrada e envie solicitações ao aplicativo de amostra para gerar tráfego.

3. No Console do Google Cloud, acesse o menu de navegação e selecione Logging > Explorador de registros:
   

   Acesse o Explorador de registros

4. Selecione um projeto do Google Cloud.

5. 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.

1. 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
   

   Observação: para o cluster regional, substitua --region por --zone.

2. 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
   

3. Envie algumas solicitações para o Bookinfo.

4. 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:

   

5. 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.

6. 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:

   

7. 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
   

8. 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:

   

9. 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:

1. 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
   

2. Verifique se há um AuthorizationPolicy no gateway de entrada que bloqueia solicitações para o serviço auditado.

3. 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"
   

   

4. 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 pesquisa config_dump de enable_audit_log e no nome da política de auditoria.

   istioctl dashboard envoy POD_NAME.NAMESPACE
   

   

5. 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'
   

6. 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
   

A seguir

• Saiba mais sobre a segurança no Cloud Service Mesh