Centralized log aggregation configured with timestamps, severity, and trace IDs

Logs written only to stdout and discarded when a pod restarts leave no forensic trail for incidents — there is no record of which requests preceded a data breach, no timestamp evidence for compliance audits, and no visibility into error patterns that precede outages (NIST 800-53 AU-3, AU-9). CIS Kubernetes 3.2.2 requires log aggregation and forwarding. Missing trace IDs means individual requests cannot be correlated across service boundaries, turning a multi-service investigation into manual log grep archaeology. 30-day retention is the minimum threshold for detecting slow-burn attacks that unfold over weeks.

Deploy a log aggregation sidecar or DaemonSet. For Fluent Bit to CloudWatch, add to k8s/logging/fluent-bit.yaml:

apiVersion: apps/v1
kind: DaemonSet
metadata:
  name: fluent-bit
  namespace: logging
spec:
  template:
    spec:
      containers:
        - name: fluent-bit
          image: fluent/fluent-bit:2.2
          volumeMounts:
            - name: varlog
              mountPath: /var/log
      volumes:
        - name: varlog
          hostPath:
            path: /var/log

Structure application logs as JSON with three required fields: timestamp (ISO 8601), level (severity), and traceId (propagated from the incoming X-Request-ID or traceparent header). Set log retention to 30 days minimum in your aggregation target — CloudWatch log groups default to Never expire which costs more; set explicitly to 30 days.