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
fluent-bit 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()
emmap()
- 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:
- É possível configurar filtros no ConfigMap
cos-auditd-fluent-bit-config
para que determinados dados não sejam registrados. Consulte a documentação sobre fluent-bit para Grep, Modificação, Modificador de registro e outros filtros. - Também é possível configurar o Stackdriver para filtrar os registros de entrada. Para mais detalhes, consulte Configurar e gerenciar coletores.
Como implantar o DaemonSet de geração de registros
Use um cluster atual ou crie um novo.
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
Edite os manifestos de exemplo de acordo com as suas necessidades. Consulte a seção anterior para detalhes sobre como o DaemonSet funciona.
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.
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 -
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.
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ó.
Exclua o DaemonSet, o ConfigMap e o namespace do cluster:
kubectl delete -f cos-auditd-logging.yaml
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
- Assista ao vídeo Cloud Forensics 101 (em inglês) para uma introdução à análise forense de nuvem.
- Saiba mais sobre a geração de registros de auditoria do Kubernetes e a política de auditoria (links em inglês).
- Leia a Visão geral da segurança do Kubernetes Engine.
- Saiba mais sobre os registros de auditoria do Cloud.