Ativar registros auditd do Linux em nós do GKE

Nesta página, você vai aprender a ativar registros detalhados de auditoria do sistema operacional 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. Ativar os 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.

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

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

Antes de ler esta página, confira 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 (em inglês).

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 Logging 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 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)

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:

Implante 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. A imagem fluent-bit usada neste manifesto de exemplo é apenas para fins de demonstração. Como prática recomendada, substitua a imagem por uma 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, 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(name)[no-heading][terminator=',']")

    Por fim, recrie as instâncias:

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

A seguir