Como 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. Não é possível ativar a geração de registros de auditoria do Linux nos clusters do GKE Autopilot porque o Google gerencia os nós e as máquinas virtuais subjacentes (VMs).

Os registros de auditoria do sistema operacional são diferentes dos registros de auditoria do Cloud e dos registros de auditoria do Kubernetes (em inglês).

Visão geral

Os registros do sistema operacional nos nós fornecem 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.

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 post mortem. Os registros auditd provavelmente não são suficientes para a análise forense 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)

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

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

  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}""

Como exportar registros

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

Limpeza

Para desativar a geração de registros auditd, exclua o DaemonSet de geração de registros e reinicie os nós. A configuração de auditoria é bloqueada depois de ativada e só pode ser alterada recriando o nó.

  1. Exclua o DaemonSet, o ConfigMap e o namespace do cluster:

    kubectl delete -f cos-auditd-logging.yaml

  2. Reinicie os nós do cluster. Primeiro, encontre o grupo de instância ao qual eles pertencem:

    instance_group=$(gcloud compute instance-groups managed list \
                    --format="value(name)" \
                    --filter=${CLUSTER_NAME})

    Em seguida, veja as próprias instâncias:

    instances=$(gcloud compute instance-groups managed list-instances ${instance_group} \
               --format="csv(instance)[no-heading][terminator=',']")

    Por fim, recrie as instâncias:

    gcloud compute instance-groups managed recreate-instances ${instance_group} \
   --instances=${instances}

A seguir