Datos de entrada y esquemas

Una política recibe dos orígenes de información. La entrada (input) es el documento que se evalúa: un manifiesto, un plan, una lista de componentes; cambia con cada ejecución. Los datos (data) son información que acompaña a la política y casi no cambia: una lista de registros prohibidos, el nombre de los equipos válidos, la tabla de responsables. Conftest carga los archivos de datos con la opción --data.

Separar los datos del código tiene una razón: quien mantiene la lista de registros no tiene por qué saber Rego, y una lista que cambia cada semana no debería obligar a editar una regla. El precio es que ahora hay un contrato entre los dos: el nombre de la clave que la regla lee y el nombre que el archivo de datos trae deben coincidir exactamente.

Cada tipo de recurso de Kubernetes guarda sus contenedores en un lugar distinto. En un Deployment o un StatefulSet, bajo spec.template.spec; en los recursos que lanzan trabajos programados, un nivel más abajo, bajo spec.jobTemplate. Una política que revisa input.spec.template.spec.containers solo ve los recursos que usan esa ruta. En los demás, la condición es indefinida y la política guarda silencio, no avisa de que no pudo mirar.

Lee la política de imágenes y compara su ruta con la estructura de cada manifiesto.

La salida de la herramienta dice lo que se encontró, no lo que se dejó de mirar. Para medir el hueco hay que contar por separado lo que existe y lo que la política alcanza. Los contenedores de inicio (initContainers) son otro ejemplo: son contenedores reales con imágenes reales, pero viven en una lista distinta de containers.

Cuenta las imágenes con la etiqueta latest que hay en los tres manifiestos y réstales las que la política de imágenes sí inspecciona.

La regla de registros itera sobre una clave de data. Si esa clave no existe en los datos, la iteración es indefinida y la regla no deniega nada, con la herramienta cargando el archivo sin quejarse. Es el mismo silencio de la tarea anterior, pero esta vez el error está en el contrato entre datos y código.

Compara el nombre que lee la política con el que trae el archivo de datos.

Una política que calla se descubre de una sola forma fiable: con una entrada que debería hacerla hablar. Eso es una prueba de denegación, y se escribe junto con la política. Hay además ayudas del propio ecosistema (OPA permite describir la forma de la entrada con un esquema y comprobar la política contra él), pero ninguna sustituye a la prueba con un caso conocido.