Políticas personalizadas y sus pruebas

5 tareas · 38 min · Principiante

Los catálogos gestionados cubren lo común. Lo propio de una empresa (sus etiquetas, sus nombres, sus regiones, sus excepciones) hay que escribirlo, y una regla escrita a mano es código que puede tener errores como cualquier otro. La diferencia es que un error en una regla de seguridad rara vez hace ruido: la regla deja de bloquear y nadie se entera. Por eso una política personalizada sin pruebas es una promesa sin comprobar. En Quincha Retail el equipo escribió una política de etiquetas obligatorias con sus pruebas. Lees la política, las pruebas, el historial y los resultados de la integración continua, y buscas cuándo y por qué la regla dejó de proteger.

0 de 5 · 0%

Objetivo de la sala

Una regla de seguridad puede fallar de dos maneras. Puede dar un falso positivo (bloquea algo legítimo) y entonces alguien protesta y se arregla. O puede dar un falso negativo (deja pasar lo que debía bloquear) y entonces no ocurre nada visible: el recurso se crea, el panel sigue verde y el hueco queda.

Las pruebas de una política están para cazar el segundo caso. Fijan, con ejemplos concretos, qué debe pasar y qué debe bloquearse; si alguien cambia la regla y deja de cumplirse un ejemplo, la integración continua se pone en rojo antes de fusionar el cambio.

Responde para continuar

¿Qué riesgo cubren sobre todo las pruebas de una regla de seguridad?

Que la regla deje de bloquear algo sin que nadie lo note Que la regla tarde demasiado en ejecutarse en la canalización Que bloquee algo legítimo

Ver pista de ayuda

Un error que bloquea molesta; un error que deja pasar no hace ruido. Piensa en cuál es más peligroso.

En Open Policy Agent las pruebas son reglas cuyo nombre empieza por test_, y se ejecutan con opa test. Dentro de una prueba, la palabra with permite sustituir input por un dato de ejemplo, de modo que se prueba la política contra un plan inventado sin necesitar ninguna nube.

Una buena suite no se queda en el caso feliz. Incluye el caso conforme (que pase), cada caso no conforme importante (que se deniegue, con el mensaje esperado) y los bordes: lo exento, lo que falta, lo mal escrito. Una política que solo se probó con un recurso bueno no ha demostrado que bloquee nada.

Responde para continuar

¿Qué debe incluir una suite de pruebas de una política?

Solo el caso conforme, que es el que demuestra que la regla funciona Una prueba por cada línea de la política, aunque repita los mismos datos Casos conformes, no conformes y bordes como las exenciones

Ver pista de ayuda

Piensa en lo que demuestra cada caso: lo conforme prueba que no estorba; lo no conforme, que bloquea.

Abre resultado-ci.txt. Contiene lo que imprimió opa test -v en cuatro cambios sucesivos del repositorio. Cada línea es una prueba con su resultado y al final hay un recuento. Una prueba en rojo no es una molestia: es la suite diciendo que algo que antes se cumplía ya no se cumple.

Responde para continuar

¿Qué prueba falló en el cambio en que la suite se puso en rojo? Escribe su nombre completo, sin la ruta del paquete.

Ver pista de ayuda

Busca la única línea con FAIL en resultado-ci.txt.

La política exime a ciertos tipos de recurso de llevar etiquetas, porque no las admiten. Una exención es justo el tipo de borde que conviene probar: es lo que más fácilmente se amplía por error, y cada tipo que se añade a la lista es un tipo que la política deja de vigilar.

Compara la lista de tipos exentos de politica.rego con los casos de politica_test.rego y decide qué tipo exento no ejercita ninguna prueba.

Responde para continuar

¿Qué tipo de recurso exime la política de llevar etiquetas sin que ninguna prueba lo ejercite? Escríbelo tal cual.

Ver pista de ayuda

Mira tipos_sin_etiquetas en la política y busca cada tipo dentro de las pruebas.

La suite no hizo daño: avisó. Lo que hizo daño fue lo que pasó después. historial.txt cuenta, cambio a cambio, qué se hizo con la regla y con sus pruebas, y resultado-ci.txt muestra el efecto de cada uno. Hay un cambio que relajó la regla y otro que, en lugar de arreglar el problema, tapó el aviso.

Aquí se pide el primero: el cambio con el que la regla empezó a proteger menos.

Responde para continuar

¿Qué cambio dejó la suite en rojo por primera vez? Escribe su identificador.

Ver pista de ayuda

Cruza la fecha de cada cambio del historial con el primer resultado que contiene un FAIL.

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

Entrar · Registrarse

1 Por qué probar una regla Lab

2 Qué casos probar Lab

3 La prueba que se puso en rojo Lab

4 La exención sin prueba Lab

5 El cambio que apagó la protección Lab

Whoami-Labs Pro utiliza cookies