Entrevista de diseño de sistemas: ¿Cómo diseñarías una política de auditoría de Kubernetes y una canalización de registros confiable?

Planteamiento y alcance

Un clúster multiinquilino debe responder quién cambió qué, cuándo y desde dónde, controlando al mismo tiempo la memoria del servidor de la API, el costo del registro y la filtración de Secrets. Diseña la política de auditoría, el backend de archivo o webhook, el muestreo y las alertas, el manejo de fallas y la verificación forense.

Qué está evaluando el entrevistador

• Comprensión de las reglas ordenadas y las diferencias entre None, Metadata, Request y RequestResponse.
• Distinción entre las etapas RequestReceived, ResponseStarted y ResponseComplete.
• Manejo de solicitudes de larga duración, cuerpos confidenciales, bloqueo del backend e integridad de los registros.
• Conexión de los objetivos de auditoría con alertas, retención, control de acceso y simulacros.

Preguntas para aclarar

1. ¿Qué recursos, verbos, inquilinos y entidades principales de alto riesgo deben auditarse?
2. ¿Qué cuerpos contienen Secrets, tokens o datos personales, y durante cuánto tiempo deben retenerse?
3. ¿El backend debe ser un archivo, un webhook o ambos, y qué ventana de pérdida y latencia es aceptable?
4. ¿Se requiere evidencia contra manipulaciones indebidas, replicación entre regiones y acceso restringido a los registros sin procesar?

Una respuesta en 30 segundos

Mapea las preguntas de investigación con campos y APIs de alto riesgo, luego ordena las reglas de lo específico a lo general. Usa Metadata para la mayoría del tráfico, Request para cambios seleccionados y RequestResponse con moderación para que los valores de los Secrets no entren en los registros ordinarios. Omite etapas tempranas solo cuando el motivo sea explícito. Protege los backends de archivos o webhooks TLS con almacenamiento en búfer, límites de tasa, cifrado, verificaciones de integridad, auditorías de acceso y alertas de pérdida. Realiza simulacros de fallas del backend para comprobar la semántica elegida.

Diseño paso a paso

1. Definir la pregunta forense

Transforma el quién, cuándo, dónde y qué en campos y consultas. Los objetos de alto riesgo incluyen Secrets, RoleBindings, webhooks, nodos y cuotas de inquilinos; los chequeos de salud rutinarios rara vez necesitan cuerpos completos. La política debe responder a investigaciones, no recopilar cada campo posible.

2. Escribir reglas ordenadas

Ordena las reglas de lo específico a lo general; la primera coincidencia establece el nivel. Usa Request o el RequestResponse necesario para cambios de alto riesgo, Metadata para lecturas rutinarias, None para ruido explícito y un respaldo de bajo nivel para evitar brechas silenciosas.

apiVersion: audit.k8s.io/v1
kind: Policy
omitStages:
  - RequestReceived
rules:
  - level: Request
    resources:
      - group: ""
        resources: ["secrets"]
  - level: Metadata
    omitStages: ["RequestReceived"]
    resources:
      - group: ""
        resources: ["pods"]
  - level: None
    users: ["system:kube-probe"]

3. Controlar etapas y campos confidenciales

Las solicitudes de larga duración pueden emitir ResponseStarted y más tarde ResponseComplete; la omisión de etapas puede reducir la duplicación, pero una solicitud no necesariamente produce un solo evento. Para Secrets y material de identidad, prefiere metadatos, hashes o resúmenes controlados, nunca valores sin procesar en un sistema de registros normal.

4. Seleccionar y proteger el backend

Rota, comprime, cifra y reenvía los registros de archivo de manera confiable. Un webhook necesita TLS, autenticación, colas y contrapresión. Particiona la canalización por inquilino y riesgo, utiliza almacenamiento de solo anexado y adjunta el ID de auditoría, la versión de la política y la hora de recepción. Los consumidores downstream no deben bloquear de forma sincrónica el servidor de la API.

5. Definir la semántica de fallas

Especifica qué sucede cuando el backend es inalcanzable, el disco está lleno, una cola se desborda o la red se particiona: descartar, bloquear o degradar. Las escrituras de alto riesgo pueden usar fail-closed solo después de cuantificar el impacto en el plano de control; el tráfico ordinario puede usar almacenamiento en búfer acotado y alertas. Registra los contadores de pérdida y el rango de escaneo para la recuperación.

6. Verificar y mejorar continuamente

Genera eventos a partir de usuarios conocidos, ServiceAccounts, proxies y solicitudes de larga duración. Verifica coincidencias de reglas, etapas, atribución de inquilinos y redacción de datos. Inyecta retrasos en webhooks, discos llenos y actualizaciones de políticas, luego verifica alertas, recuperación y consultas forenses. Realiza un seguimiento del volumen de eventos, pérdidas, latencia, costo y cobertura de investigación.

Respuesta modelo de alta calidad

Mapearía las preguntas de investigación a campos y recursos de alto riesgo, y luego ordenaría las reglas de lo específico a lo general. El tráfico rutinario recibe Metadata, los Secrets reciben metadatos controlados y los cambios seleccionados reciben Request; las etapas de larga duración son explícitas. El backend utiliza archivos cifrados o un webhook TLS con almacenamiento en búfer, contrapresión, integridad de solo anexado y auditoría de acceso, sin permitir que los consumidores bloqueen el servidor de la API. El comportamiento ante fallas incluye almacenamiento en búfer acotado, contadores de pérdidas y alertas, reservando fail-closed para escrituras de alto riesgo cuantificadas. Los eventos sintéticos, las solicitudes de larga duración y los simulacros de fallas comprueban la política y la ruta de recuperación.

Errores comunes

• Registrar cada solicitud en RequestResponse → filtración de información confidencial y costos descontrolados → clasificar por niveles según el riesgo.
• Ordenar las reglas de manera descuidada → una regla general oculta eventos de alto riesgo → ordenar de lo específico a lo general.
• Verificar únicamente que exista un archivo de registro → el bloqueo o la pérdida en el backend son invisibles → monitorear colas, latencia y pérdidas.
• Ignorar las etapas → las investigaciones de larga duración pierden la cronología → definir etapas y motivos de omisión.
• Bloquear de forma sincrónica el servidor de la API por consumidores de webhook → colapso del plano de control → aislar con búferes, tiempos de espera y contrapresión.

Preguntas de seguimiento y respuestas

¿Por qué no registrar cada solicitud de Secret en RequestResponse?

El cuerpo puede contener Secrets en texto plano. La mayoría de las investigaciones necesitan la entidad principal, el objeto, el verbo y el resultado; un acceso más profundo requiere redacción, permisos aislados y una retención corta y controlada.

¿Se debe bloquear la solicitud a la API cuando el webhook no está disponible?

Depende de los objetivos de riesgo y disponibilidad. Tras cuantificar el impacto, las escrituras de alto riesgo pueden fallar cerradas mientras que el tráfico ordinario utiliza almacenamiento en búfer acotado y alertas. Cualquiera de las dos opciones debe exponer el alcance de la pérdida y de la recuperación.

¿Cómo demuestras que los recursos desconocidos no se omiten silenciosamente?

Mantén un respaldo de bajo nivel, compara los inventarios de descubrimiento con solicitudes sintéticas y versiones de políticas, y activa revisiones cuando aparezca una nueva API en lugar de depender de la detección manual.