Ative os registos auditd do Linux em nós do GKE

Esta página explica como ativar os registos de auditoria do sistema operativo detalhados nos nós do Google Kubernetes Engine que executam o SO otimizado para contentores. Esta página também explica como configurar um agente de registo fluent-bit para enviar registos para o Cloud Logging. A ativação dos registos detalhados pode fornecer informações valiosas sobre o estado do cluster e das cargas de trabalho, como mensagens de erro, tentativas de início de sessão e execuções binárias. Pode usar estas informações para depurar problemas ou investigar incidentes de segurança.

A ativação do registo auditd do Linux não é suportada em clusters do GKE Autopilot, porque a Google gere os nós e as máquinas virtuais (VMs) subjacentes.

Esta página destina-se a especialistas em segurança que reveem e analisam registos de segurança. Use estas informações para compreender os requisitos e as limitações dos registos do SO detalhados e orientar a implementação quando os ativar nos seus nós do GKE. Para saber mais acerca das funções comuns e das tarefas de exemplo que referimos no Trusted Cloud by S3NS conteúdo, consulte o artigo Funções e tarefas comuns de utilizadores do GKE.

Antes de ler esta página, certifique-se de que conhece os registos de auditoria do sistema operativo Linux.

O registo de auditoria do sistema operativo é diferente dos registos de auditoria do Cloud e dos registos de auditoria do Kubernetes.

Vista geral

Para recolher registos de cada nó num cluster, use um DaemonSet que executa exatamente um pod em cada nó do cluster onde o DaemonSet é elegível para ser agendado. Este pod configura o daemon de registo auditd no anfitrião e configura o agente de registo para enviar os registos para o Logging ou qualquer outro serviço de carregamento de registos.

Por definição, a auditoria ocorre após um evento e é uma medida de segurança retrospetiva. Os registos do auditd sozinhos provavelmente não são suficientes para realizar análises forenses no seu cluster. Considere a melhor forma de usar o registo auditd como parte da sua estratégia de segurança geral.

Limitações

Os mecanismos de registo descritos nesta página só funcionam em nós que executam o SO otimizado para contentores em clusters padrão do GKE.

Como funciona o DaemonSet de registo

Esta secção descreve o funcionamento do DaemonSet de registo de exemplo para que o possa configurar de acordo com as suas necessidades. A secção seguinte explica como implementar o DaemonSet.

O manifesto de exemplo define um DaemonSet, um ConfigMap e um espaço de nomes para os conter.

O DaemonSet implementa um pod em cada nó no cluster. O Pod contém dois contentores. O primeiro é um init container que inicia o serviço systemd cloud-audit-setup disponível nos nós do SO otimizado para contentores. O segundo contentor, cos-auditd-fluent-bit, contém uma instância do fluent-bit que está configurada para recolher os registos de auditoria do Linux do jornal do nó e exportá-los para o Cloud Logging.

O DaemonSet de registo de exemplo regista os seguintes eventos:

  • auditd modificações da configuração do sistema
  • Verificações de autorizações do AppArmor
  • Execuções de execve(), socket(), setsockopt() e mmap()
  • ligações de rede
  • inícios de sessão de utilizadores
  • Sessão SSH e todos os outros TTYs (incluindo sessões kubectl exec -t)

Configure o DaemonSet de registo

Configura o DaemonSet de registo através de um ConfigMap, cos-auditd-fluent-bit-config. O exemplo fornecido envia registos de auditoria para o registo, mas pode configurá-lo para enviar registos para outros destinos.

O volume de registos produzido pelo auditd pode ser muito grande e pode incorrer em custos adicionais porque consome recursos do sistema e envia mais registos do que a configuração de registo predefinida. Pode configurar filtros para gerir o volume de registo:

Implemente o DaemonSet de registo

  1. Pode usar um cluster existente ou criar um novo.

  2. Transfira os 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 secção anterior para ver detalhes sobre o funcionamento do DaemonSet. Tenha em atenção que a fluent-bitimagem usada neste exemplo de manifesto destina-se apenas a fins de demonstração. Como prática recomendada, substitua a imagem por uma imagem de uma fonte controlada com o resumo SHA-256.

  4. Inicialize variáveis comuns:

    export CLUSTER_NAME=CLUSTER_NAME
export CLUSTER_LOCATION=COMPUTE_REGION

    Substitua o seguinte:

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

  5. Implemente o espaço de nomes de registo, o DaemonSet e o ConfigMap:

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

  6. Verifique se os pods de registo foram iniciados. Se definiu um espaço de nomes diferente nos seus manifestos, substitua cos-auditd pelo nome do espaço de nomes que está a usar.

    kubectl get pods --namespace=cos-auditd

    Se os pods estiverem em execução, o resultado tem o seguinte aspeto:

    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 é implementado em cada nó no cluster. Neste caso, o cluster tem três nós.

  7. Agora, pode aceder aos registos de auditoria em Registo. No Explorador de registos, filtre os resultados com a seguinte consulta:

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

    Em alternativa, pode 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 registos

Para saber como encaminhar os seus registos para destinos suportados, consulte o artigo Configurar e gerir destinos.

Desative os registos

Para desativar o registo auditd, elimine o DaemonSet de registo e reinicie os nós. A configuração de auditoria é bloqueada assim que é ativada e só pode ser alterada recriando o nó.

  1. Elimine o DaemonSet, o ConfigMap e o respetivo espaço de nomes do cluster:

    kubectl delete -f cos-auditd-logging.yaml

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

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

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

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

    Por último, recrie as instâncias:

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

O que se segue?