cks

3.16 Audit log

Detalhamento da configuração de audit logging do API server para o CKS.

O que é

O audit log do Kubernetes registra as requisições recebidas pelo API server. Você define uma política (quais recursos, quais usuários, que nível de detalhe) e o destino do log (arquivo, etc.). No CKS pode ser necessário configurar ou ajustar a política e os argumentos do kube-apiserver (ex.: --audit-policy-file, --audit-log-path, --audit-log-maxbackup).

Documentação oficial

Argumentos do API server

No manifest estático do kube-apiserver (/etc/kubernetes/manifests/kube-apiserver.yaml):

–audit-policy-file: caminho do arquivo de política de audit (YAML).
–audit-log-path: caminho do arquivo de log (ex.: /var/log/kubernetes/audit.log ou /etc/kubernetes/audit/logs/audit.log).
–audit-log-maxbackup: número de arquivos de backup a manter (ex.: 1 para reduzir espaço e cumprir requisitos do exame).

O API server precisa ter acesso de leitura à policy e de escrita ao diretório do log (volumes/volumeMounts no manifest).

Níveis da política (level)

Cada regra na policy pode ter um level:

Level	Descrição
None	Não registra eventos que batem nessa regra.
Metadata	Registra apenas metadata (quem, quando, qual recurso/verbo), sem request/response body.
Request	Metadata + body da request (sem response body).
RequestResponse	Metadata + body da request e da response.

Ordem das regras importa: a primeira que casar define o level. Regras mais específicas (recurso, namespace, usuário) costumam vir primeiro.

Exemplo de policy (estrutura)

apiVersion: audit.k8s.io/v1
kind: Policy
rules:
# Não logar eventos de leitura em certos recursos
- level: None
  resources:
  - group: ""
    resources: ["events"]
# Secrets: RequestResponse para auditoria sensível
- level: RequestResponse
  resources:
  - group: ""
    resources: ["secrets"]
# Resto: Metadata
- level: Metadata
  resources:
  - group: ""
    resources: ["*"]

Ajuste resources, namespaces, userGroups, etc., conforme o enunciado.

Reiniciar / recarregar o API server

Como o API server é um Pod estático, ao alterar o manifest em /etc/kubernetes/manifests/ o kubelet recria o Pod. Alternativas:

Mover o manifest para fora da pasta e de volta (para forçar recriação).
Ou apenas editar e salvar; o kubelet detecta mudança e recria.

Depois de aplicar, verifique se o Pod do API server subiu e se o audit log está sendo escrito.

Limpar o log (exemplo do enunciado)

Se o exercício pedir “limpar” o arquivo de log:

echo > /etc/kubernetes/audit/logs/audit.log
# ou
truncate -s 0 /etc/kubernetes/audit/logs/audit.log

Use o path configurado no seu cluster.

Resumo para o exame

–audit-policy-file, –audit-log-path, –audit-log-maxbackup=1 no kube-apiserver.
Policy: levels **None Metadata Request RequestResponse**, regras por resources/userGroups.
Reiniciar: editar manifest em /etc/kubernetes/manifests/ (ou mover e devolver).
Limpar log: echo > <audit-log-path>.