Ativar registros auditd do Linux em nós do GKE

Nesta página, você verá como ativar registros detalhados de auditoria do sistema operacional (em inglês) em nós do Google Kubernetes Engine que executam o Container-Optimized OS. Nesta página, também explicamos como configurar um agente do Logging de bits fluentes para enviar registros ao Cloud Logging. A ativação de registros detalhados pode fornecer informações valiosas sobre o estado do cluster e das cargas de trabalho, como mensagens de erro, tentativas de login e execuções binárias. Use essas informações para depurar problemas ou investigar incidentes de segurança.

A ativação da geração de registros de auditoria do Linux não é compatível em clusters do GKE Autopilot, porque o Google gerencia os nós e as máquinas virtuais subjacentes (VMs).

Esta página é destinada a especialistas em segurança que analisam registros de segurança. Use essas informações para entender os requisitos e as limitações dos registros detalhados do SO e orientar a implementação ao ativá-los nos nós do GKE. Para saber mais sobre papéis comuns e tarefas de exemplo referenciados no Google Cloud conteúdo, consulte Tarefas e funções de usuário comuns do GKE.

Antes de ler esta página, você precisa conhecer os registros de auditoria do sistema operacional Linux.

Os registros de auditoria do sistema operacional são diferentes dos registros de auditoria do Cloud e dos registros de auditoria do Kubernetes.

Visão geral

Para coletar os registros de cada nó em um cluster, use um DaemonSet que executa apenas um Pod em cada nó do cluster onde o DaemonSet é elegível para ser programado. Esse pod configura o daemon de geração de registros auditd no host e configura o agente do Logging para enviar os registros para o Stackdriver ou qualquer outro serviço de processamento de registro.

Por definição, a auditoria ocorre após um evento e é uma medida de segurança retrospectiva. Os registros auditd provavelmente não são suficientes para a perícia no cluster. Considere a melhor maneira de usar o registro auditd como parte de sua estratégia geral de segurança.

Limitações

Os mecanismos de geração de registros descritos nesta página funcionam apenas em nós que executam o Container-Optimized OS em clusters do GKE Standard.

Como o DaemonSet de geração de registro funciona

Nesta seção, é descrito como o exemplo de DaemonSet de geração de registro (em inglês) funciona, de modo que seja possível configurá-lo para atender às suas necessidades. Na próxima seção, você aprenderá a implantar o DaemonSet.

O manifesto de exemplo define um DaemonSet, um ConfigMap e um namespace para contê-los.

O DaemonSet implanta um pod para cada nó no cluster, sendo que o pod contém dois contêineres. O primeiro é um contêiner de inicialização que inicia o serviço systemd cloud-audit-setup disponível nos nós do Container-Optimized OS. O segundo contêiner, cos-auditd-fluent-bit, contém uma instância de bits fluentes que está configurado para coletar os registros de auditoria do Linux no diário de nós e exportá-los para o Cloud Logging.

Os registros de DaemonSet de exemplo registram os seguintes eventos:

  • Modificações de configuração de sistema auditd
  • Verificações de permissão do AppArmor
  • Execuções execve(), socket(), setsockopt() e mmap()
  • Conexões de rede
  • Logins de usuários
  • Sessão SSH e todos os outros TTYs (incluindo sessões kubectl exec -t)

Configurar o DaemonSet de geração de registros

Configure o DaemonSet de geração de registros usando um ConfigMap, cos-auditd-fluent-bit-config. O exemplo fornecido envia registros de auditoria para o Logging, mas é possível configurá-los para enviar registros a outros destinos.

O volume de registros produzidos por auditd pode ser muito grande e pode incorrer em mais custos, já que consome recursos do sistema e envia mais registros do que a configuração de geração de registros padrão. É possível configurar filtros para gerenciar o volume de geração de registros:

Implantar o DaemonSet de geração de registros

  1. Use um cluster atual ou crie um novo.

  2. Faça o download dos manifestos de exemplo:

    curl https://raw.githubusercontent.com/GoogleCloudPlatform/k8s-node-tools/master/troubleshooting/os-audit/cos-auditd-logging.yaml > cos-auditd-logging.yaml

  3. Edite os manifestos de exemplo de acordo com as suas necessidades. Consulte a seção anterior para detalhes sobre como o DaemonSet funciona. A imagem fluent-bit usada neste manifesto de exemplo é apenas para demonstração. Como prática recomendada, substitua a imagem por uma imagem de uma fonte controlada com resumo SHA-256.

  4. Inicializar variáveis comuns:

    export CLUSTER_NAME=CLUSTER_NAME
export CLUSTER_LOCATION=COMPUTE_REGION

    Substitua:

    • CLUSTER_NAME: o nome do cluster.
    • COMPUTE_REGION: a região do Compute Engine do cluster; Para clusters zonais, use a zona.

  5. Implante o ConfigMap, o Namespace e o DaemonSet de geração de registros:

    envsubst '$CLUSTER_NAME,$CLUSTER_LOCATION' < cos-auditd-logging.yaml \
| kubectl apply -f -

  6. Verifique se os pods de geração de registro foram iniciados. Se você definiu um namespace diferente nos manifestos, substitua cos-auditd pelo nome do namespace que está usando.

    kubectl get pods --namespace=cos-auditd

    Se os pods estiverem em execução, a saída terá a seguinte aparência:

    NAME                                             READY   STATUS    RESTARTS   AGE
cos-auditd-logging-g5sbq                         1/1     Running   0          27s
cos-auditd-logging-l5p8m                         1/1     Running   0          27s
cos-auditd-logging-tgwz6                         1/1     Running   0          27s

    Um pod é implantado em cada nó do cluster. Nesse caso o cluster tem três nós.

  7. Agora é possível acessar os registros de auditoria no Stackdriver. No Explorador de registros, filtre os resultados usando a seguinte consulta:

    LOG_ID("linux-auditd")
resource.labels.cluster_name = "CLUSTER_NAME"
resource.labels.location = "COMPUTE_REGION"

    Como alternativa, é possível usar a CLI gcloud (use --limit porque o conjunto de resultados pode ser muito grande):

    gcloud logging read --limit=100 "LOG_ID("linux-auditd") AND resource.labels.cluster_name = "${CLUSTER_NAME}" AND resource.labels.location = "${CLUSTER_LOCATION}""

Exportar registros

Para saber como rotear seus registros para destinos compatíveis, consulte Configurar e gerenciar coletores.

Desativar registros

Para desativar a geração de registros auditd nos nós, exclua o DaemonSet de geração de registros e implante o cos-auditd-logging-disable DaemonSet para reverter as mudanças de serviço do systemd em cada nó. Depois de implantar esse DaemonSet, não será possível ativar a geração de registros auditd, a menos que os nós sejam recriados.

  1. Exclua o DaemonSet de geração de registros original e os recursos relacionados:

    kubectl delete daemonset cos-auditd-logging -n cos-auditd
kubectl delete configmap fluent-bit-config -n cos-auditd
# The namespace will be deleted by the cleanup daemonset's namespace definition

  2. Aplique o cos-auditd-logging-disable DaemonSet de limpeza:

    kubectl apply -f 'https://raw.githubusercontent.com/GoogleCloudPlatform/k8s-node-tools/master/troubleshooting/os-audit/cos-auditd-logging-disable.yaml'

  3. Verifique se os pods cleanup-auditd estão em execução em todos os nós:

    kubectl get pods -n cos-auditd -l name=cleanup-auditd -w

    Aguarde até que todos os pods mostrem Running.

  4. Depois que os pods de limpeza estiverem em execução, confirme se novos linux-auditd registros não serão gerados executando as consultas da seção Como implantar o DaemonSet de geração de registros. Por exemplo, use o seguinte comando da CLI gcloud:

    gcloud logging read --limit=10 --freshness="5m" \
  "LOG_ID(\"linux-auditd\") AND \
  resource.labels.cluster_name = \"${CLUSTER_NAME}\" AND \
  resource.labels.location = \"${CLUSTER_LOCATION}\""

    Esse comando verifica os registros nos últimos cinco minutos. Se a revisão dos dados for bem-sucedida, a saída estará vazia.

    Da mesma forma, ao usar o Cloud Explorer com o mesmo filtro, você não verá novas entradas de registro aparecendo após o tempo de limpeza.

  5. Exclua o DaemonSet e o namespace de limpeza:

    kubectl delete -f cleanup-auditd-daemonset.yaml

    Esse comando vai excluir o DaemonSet e o namespace cos-auditd.

A seguir