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

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

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

  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

  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:

    imagem

  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:

    imagem

  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:

    imagem

  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"

    imagem

  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

    imagem imagem imagem

  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