Reglas de admisión como control detectivo

5 tareas · 40 min · Principiante

La admisión es el punto donde el clúster decide si acepta lo que le piden crear. Se suele pensar como un portero que bloquea, pero puede funcionar también como un testigo: en vez de rechazar, anota en la auditoría que lo pedido incumple una regla. Esa anotación es una detección sin riesgo de romper un despliegue, y además dice cuánto se rompería si mañana se pasara a bloquear. En Embotelladora Ceiba Dorada lees las etiquetas de Pod Security de cuatro namespaces, dos políticas propias y siete eventos de auditoría con anotación. Aprendes la diferencia entre bloquear, avisar y anotar, y a usar el modo de auditoría para decidir cuándo bloquear.

0 de 5 · 0%

Objetivo de la sala

Pod Security Admission, el control de admisión que viene con Kubernetes, tiene tres modos que se activan con etiquetas del namespace: enforce rechaza lo que incumple, warn devuelve una advertencia al usuario que lo pidió y audit anota la violación en el evento de auditoría y deja pasar el pod. Las políticas de admisión validantes tienen acciones parecidas, Deny, Warn y Audit, en el enlace de la política.

Abre politicas_de_admision y espacios_y_etiquetas.

Responde para continuar

¿Qué hace la acción Audit de una política cuando una solicitud la incumple?

Anota el incumplimiento en el evento de auditoría de esa solicitud y deja que siga adelante Devuelve una advertencia a quien hizo la solicitud sin escribir nada en el registro de auditoría Rechaza la solicitud y escribe en el registro de auditoría la razón del rechazo

Cada namespace puede tener un nivel distinto para cada modo. Si enforce es el nivel menos exigente y audit uno más estricto, el namespace deja pasar todo, pero cada pod que no cumpla el nivel estricto queda anotado. Es una forma de saber qué se rompería sin romperlo todavía.

Responde para continuar

Escribe el namespace cuyo modo enforce está en el nivel menos exigente y que solo audita lo demás.

Ver pista de ayuda

Busca en `espacios_y_etiquetas` el nivel `privileged` en la columna `enforce`.

La anotación pod-security.kubernetes.io/audit-violations nombra el nivel que se habría incumplido y el campo concreto. Un conteo por namespace dice dónde está la deuda de configuración. Abre eventos_con_anotacion.

Responde para continuar

Escribe cuántos eventos del namespace tienda traen una anotación de violación de Pod Security.

Ver pista de ayuda

Filtra `namespace` por `tienda` y cuenta las filas cuya `anotacion` es la de audit-violations.

Además de Pod Security hay dos políticas propias. Una de ellas solo tiene la acción Audit y mira si una imagen usa la etiqueta latest, que no dice qué contenido arranca. Su anotación lleva un valor distinto al de Pod Security. Aquí el valor está resumido: en un clúster real la forma exacta de la anotación se comprueba en la documentación de la versión instalada.

Responde para continuar

Escribe el workload que quedó señalado por la política que solo audita la etiqueta latest.

Ver pista de ayuda

Mira la fila de `eventos_con_anotacion` cuya anotación no es la de Pod Security.

En operaciones, pagos y tienda las anotaciones se repiten sobre los mismos workloads, no sobre workloads distintos cada día. Antes de cambiar un modo de audit a enforce hay que saber qué dejaría de funcionar y quién lo pidió.

Responde para continuar

¿Qué hace el equipo antes de activar enforce en un namespace?

Esperar a que otro control de la empresa bloquee los pods y entonces apagar el modo de auditoría Arreglar o justificar con el dueño cada workload anotado y activarlo cuando no haya anotaciones nuevas Activarlo en todos los namespaces de una vez, porque las anotaciones ya dicen que hay incumplimientos

Inicia sesión para registrar tus puntos y progreso en el ranking.

Entrar · Registrarse

1 Tres acciones, un mismo control

2 El namespace que solo anota Lab

3 Contar las anotaciones Lab

4 La política propia que también anota Lab

5 Cuándo pasar de anotar a bloquear

Whoami-Labs Pro utiliza cookies