Configurar políticas de auditoria para os seus serviços

Uma política de auditoria permite-lhe auditar o acesso a dados nos seus serviços na Cloud Service Mesh. A auditoria dos seus serviços ajuda a responder às perguntas "quem fez o quê, quando e, possivelmente, porquê". Com uma política de auditoria, pode especificar quando é criado um registo de auditoria e o conteúdo dos registos. Este guia explica como instalar o Cloud Service Mesh para poder usar uma política de auditoria.

Uma vez que vê os registos de auditoria no Explorador de registos do Cloud Logging na consola Google Cloud , as políticas de auditoria são suportadas apenas nas seguintes plataformas:

  • GKE no Google Cloud
  • Google Distributed Cloud
  • Google Distributed Cloud

Uma política de auditoria expande a AuthorizationPolicy adicionando uma ação AUDIT. Só tem efeito no respetivo âmbito da política de destino (que pode ser uma carga de trabalho, um espaço de nomes ou toda a malha). As políticas são aplicadas ORed, ou seja, um pedido é registado se alguma política o indicar. Se nenhuma política de auditoria se aplicar a uma determinada carga de trabalho, não é gerado nenhum registo de auditoria para essa carga de trabalho.

Segue-se um exemplo de uma política de auditoria para auditar todo o acesso de ESCRITA 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 existe nenhum registo de auditoria no gateway de entrada.
  • O conteúdo de auditoria não é configurável.
  • Atualmente, os registos de auditoria do Cloud Service Mesh têm a mesma propriedade de fiabilidade que os registos de acesso normais. Por exemplo, se um pod de carga de trabalho for reiniciado, alguns registos de auditoria da carga de trabalho, se não forem mantidos, podem ser perdidos.

Antes de começar

Siga os passos em Instale ferramentas dependentes e valide o cluster para:

Prepare a configuração do gateway

O Cloud Service Mesh dá-lhe a opção de implementar e gerir gateways como parte da sua malha de serviços. Um gateway descreve um balanceador de carga que opera no limite da malha e recebe ligações HTTP/TCP de entrada ou saída. As gateways são proxies Envoy que lhe oferecem um controlo detalhado sobre o tráfego que entra e sai da malha.

O asmcli não instala o istio-ingressgateway. Recomendamos que implemente e faça a gestão do plano de controlo e das gateways separadamente. Para mais informações, consulte o artigo Instalar e atualizar gateways.

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

  1. Siga os passos em Instale o Cloud Service Mesh. Quando executar asmcli install, inclua a seguinte opção:

    --option audit-authorizationpolicy

    Por 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

    Certifique-se de que especifica outros ficheiros de sobreposição que precisa de configurar para a malha de serviços na nuvem.

  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 o artigo Implemente e reimplemente cargas de trabalho.

Atualizações

  1. Siga os passos no artigo Atualize o Cloud Service Mesh. Quando executar asmcli install, inclua a seguinte opção:

    --option audit-authorizationpolicy

    Por 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

    Certifique-se de que especifica outros ficheiros de sobreposição que precisa de configurar para a malha de serviços na nuvem.

  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 mais detalhes, consulte o artigo Mude para o novo plano de controlo

Usar o registo de auditoria

Esta secção usa o exemplo Bookinfo para demonstrar como usar o registo de auditoria.

  1. Implemente a aplicação de exemplo Bookinfo no espaço de nomes predefinido.

  2. Obtenha o endereço IP externo do gateway de entrada e envie pedidos para a aplicação de exemplo para gerar algum tráfego.

  3. Na Google Cloud consola, aceda ao menu de navegação e selecione Registo > Explorador de registos:

    Aceda ao Explorador de registos

  4. Selecione um Google Cloud projeto.

  5. Como ainda não implementou uma política de auditoria, não existem registos de auditoria. Tenha em atenção que o registo de auditoria é diferente do registo de acesso. Para ver os registos de acesso, introduza a seguinte consulta no campo Criador de consultas e clique em Executar consulta:stackdriver

    logName="projects/PROJECT_ID/logs/server-accesslog-stackdriver"

    Para mais informações sobre a utilização do Explorador de registos, consulte a Vista geral do Explorador de registos.

Configurar a política de auditoria e verificar os registos de auditoria

Esta secção oferece várias opções para auditar a aplicação Bookinfo. Depois de implementar a política de auditoria, pode enviar alguns pedidos e, em seguida, verificar o registo de auditoria no Logs Explorer.

  1. Introduza o seguinte comando para obter as credenciais de autenticação para interagir com o cluster. Este comando também define o contexto atual de kubectl para o cluster.

    gcloud container clusters get-credentials CLUSTER_NAME \
    --project=PROJECT_ID \
    --zone=CLUSTER_LOCATION

  2. Aplique a seguinte política de auditoria para auditar os pedidos GET para o 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. Enviar alguns pedidos para o Bookinfo.

  4. No Explorador de registos, introduza a seguinte consulta no campo Criador de consultas e clique em Executar consulta:

    logName="projects/PROJECT_ID/logs/server-istio-audit-log"

    A consulta devolve registos semelhantes aos seguintes:

    imagem

  5. Aplique a seguinte política para auditar pedidos ao bookinfo-ratings serviço. As políticas de auditoria são cumulativas. Depois de aplicar a seguinte política, vê registos de auditoria para pedidos à ProductPage e às 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 tem de ser propagada antes de entrar em vigor.

  6. Envie 10 ou mais pedidos para Bookinfo para se certificar de que atinge o serviço de classificações e, em seguida, verifique o registo de auditoria no Explorador de registos. O registo de auditoria é semelhante ao seguinte:

    imagem

  7. Aplique a seguinte política de auditoria a todos os serviços no espaço de nomes predefinido.

    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 alguns pedidos para o Bookinfo e, em seguida, verifique o registo de auditoria no Explorador de registos. O registo de auditoria regista agora todos os pedidos:

    imagem

  9. Se quiser restringir a política de auditoria novamente à página do produto e às classificações, pode eliminar a política audit-all:

    kubectl delete authorizationpolicy audit-all -n default

Resolução de problemas

Se não vir registos de auditoria depois de ativar uma política de auditoria, seguem-se alguns aspetos que pode verificar:

  1. Certifique-se de que existe tráfego para o período especificado no Explorador de registos. Se estiver a testar com o Bookinfo, pode enviar pedidos executando o seguinte comando várias vezes:

    curl -s http://EXTERNAL_IP/productpage | grep Bookstore

  2. Verifique se existe um AuthorizationPolicy no gateway de entrada que bloqueia pedidos ao serviço auditado.

  3. Verifique os registos de acesso stackdriver com o seguinte filtro no Logs Explorer para confirmar se os seus pedidos chegaram à aplicação:

    logName="projects/PROJECT_ID/logs/server-accesslog-stackdriver"

    imagem

  4. Para se certificar de que o Stackdriver está configurado e o registo de auditoria está ativado, despeje a configuração do estado istiod atual. Na config_dump, pesquise enable_audit_log e o nome da política de auditoria.

    istioctl dashboard envoy POD_NAME.NAMESPACE

    imagem imagem imagem

  5. Para se certificar de que os seus pedidos são associados às regras da política de auditoria, pode verificar os registos de depuração do controlo de acesso baseado em funções (CABF). Ative o registo 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 alguns pedidos e, em seguida, verifique os registos do pod com o comando kubectl logs:

    kubectl logs POD_NAME -n NAMESPACE -c istio-proxy

O que se segue?