@kwirthmagnify/kwirth-docs-pinocchio 0.2.31 → 0.2.34
This diff represents the content of publicly available package versions that have been released to one of the supported registries. The information contained in this diff is provided for informational purposes only and reflects changes between package versions as they appear in their respective public registries.
- package/admin/01-setup.md +98 -98
- package/admin/02-ai-config.md +125 -125
- package/admin/03-tools.md +132 -131
- package/admin/05-rbac.md +89 -89
- package/admin/06-limits.md +113 -113
- package/index.md +42 -42
- package/package.json +1 -1
- package/user/00-how-it-works.md +88 -88
- package/user/02-ui-tour.md +96 -96
- package/user/05-findings.md +108 -108
package/user/02-ui-tour.md
CHANGED
|
@@ -1,96 +1,96 @@
|
|
|
1
|
-
# Recorrido por la UI
|
|
2
|
-
|
|
3
|
-
Pinocchio es un canal, así que se abre como cualquier otro canal de
|
|
4
|
-
el selector y lo arrancas. No tiene diálogo de *Setup* — no hay nada que configurar antes de arrancar.
|
|
5
|
-
|
|
6
|
-
## La pestaña
|
|
7
|
-
|
|
8
|
-
La pestaña es una única tarjeta con una cabecera y un flujo de mensajes que crece hacia abajo.
|
|
9
|
-
|
|
10
|
-
|
|
11
|
-
|
|
12
|
-
**Cabecera**
|
|
13
|
-
|
|
14
|
-
| Elemento | Qué es |
|
|
15
|
-
|--------------|-------------------------------------------------------------------------------|
|
|
16
|
-
| `Events: N` | Número de entradas en el flujo (análisis + mensajes). No es el número de findings. |
|
|
17
|
-
| `Status` | `started`, `paused` o `stopped`, según el estado del canal. |
|
|
18
|
-
| **Clear** | Abre el diálogo de limpieza (ver abajo). |
|
|
19
|
-
| **Playground** | Abre el banco de pruebas. Ver [El Playground](06-playground.md). |
|
|
20
|
-
| **Config** | Abre el menú de configuración. |
|
|
21
|
-
|
|
22
|
-
**Flujo**
|
|
23
|
-
|
|
24
|
-
El cuerpo hace autoscroll al final mientras estés abajo del todo; si subes a leer algo, deja de seguirte
|
|
25
|
-
hasta que vuelvas al final. Cada análisis se pinta como:
|
|
26
|
-
|
|
27
|
-
1. Una línea de cabecera con la marca de tiempo, el evento (`ADDED Deployment 'nginx' in namespace 'demo'`),
|
|
28
|
-
el LLM usado y los tokens consumidos, más un botón **Report**.
|
|
29
|
-
2. Los **findings**, ordenados de `critical` a `low`, cada uno con su etiqueta de severidad.
|
|
30
|
-
3. Una **tira de resumen** con PSS, el recuento por severidad y el riesgo global.
|
|
31
|
-
|
|
32
|
-
Los findings y la tira de resumen son **clicables** y abren su diálogo de detalle.
|
|
33
|
-
|
|
34
|
-
## El menú Config
|
|
35
|
-
|
|
36
|
-
El botón **Config** abre un menú de tres entradas, la primera de ellas un grupo desplegable. El orden no es
|
|
37
|
-
casual: cada una depende de la anterior.
|
|
38
|
-
|
|
39
|
-
|
|
40
|
-
|
|
41
|
-
| Entrada | Se habilita cuando… | Qué configura |
|
|
42
|
-
|-------------------|----------------------------------------|--------------------------------------------------|
|
|
43
|
-
| **AI** ▸ **AI providers** | siempre | Proveedores de IA (OpenAI, Google, …) y su API key |
|
|
44
|
-
| **AI** ▸ **AI models** | hay al menos un provider | Modelos concretos, con temperatura y coste |
|
|
45
|
-
| **Trigger** | hay al menos un LLM | Los triggers y sus versiones |
|
|
46
|
-
| **Import / Export** | siempre | Volcado y carga de triggers en JSON |
|
|
47
|
-
|
|
48
|
-
**AI** es un grupo plegable —el patrón habitual de
|
|
49
|
-
plegado**: hay que clicarlo para ver *AI providers* y *AI models*. Es lo que menos se toca una vez montado,
|
|
50
|
-
por eso está recogido.
|
|
51
|
-
|
|
52
|
-
Si abres Pinocchio por primera vez y **Trigger** está en gris, no es un fallo: es que aún no hay un LLM
|
|
53
|
-
configurado. Empieza por **AI ▸ AI providers**. El detalle está en
|
|
54
|
-
[Providers y modelos de IA](../admin/02-ai-config.md).
|
|
55
|
-
|
|
56
|
-
> Los diálogos de **AI providers** y **AI models** no son de Pinocchio: son los diálogos comunes de IA de
|
|
57
|
-
>
|
|
58
|
-
> aquí lo verán también ellos.
|
|
59
|
-
|
|
60
|
-
## Los diálogos de detalle
|
|
61
|
-
|
|
62
|
-
**Detalle de un finding** (clic en cualquier finding) — muestra, en dos columnas, todo lo que el modelo
|
|
63
|
-
rellenó: Control ID, categoría, confianza, *risk score*, descripción, evidencia e impacto a la izquierda;
|
|
64
|
-
remediación y referencias a la derecha. Los campos vacíos no se pintan.
|
|
65
|
-
|
|
66
|
-
**Detalle del análisis** (clic en la tira de resumen) — el recurso analizado (kind, nombre, namespace,
|
|
67
|
-
imágenes), PSS actual y objetivo, riesgo global y recuento por severidad a la izquierda; controles superados,
|
|
68
|
-
lo que el modelo **no pudo ver** y los próximos pasos a la derecha.
|
|
69
|
-
|
|
70
|
-
**Report** (botón *Report* de la cabecera del análisis) — abre el informe en markdown renderizado. El botón
|
|
71
|
-
está deshabilitado si ese análisis no trajo informe.
|
|
72
|
-
|
|
73
|
-
## El diálogo Clear
|
|
74
|
-
|
|
75
|
-
Hay dos limpiezas distintas y conviene no confundirlas, porque una es local y la otra afecta a todo el mundo:
|
|
76
|
-
|
|
77
|
-
|
|
78
|
-
|
|
79
|
-
- **Clear my view** — vacía **tu** pantalla. El backend conserva sus análisis y te los reenviará si
|
|
80
|
-
reconectas.
|
|
81
|
-
- **Clear back** — borra los análisis guardados **en el canal**. Afecta a todos los fronts conectados y no
|
|
82
|
-
tiene vuelta atrás.
|
|
83
|
-
|
|
84
|
-
## Colores de severidad
|
|
85
|
-
|
|
86
|
-
Los mismos en toda la UI:
|
|
87
|
-
|
|
88
|
-
| Nivel | Color |
|
|
89
|
-
|------------|----------|
|
|
90
|
-
| `critical` | rojo |
|
|
91
|
-
| `high` | naranja |
|
|
92
|
-
| `medium` | verde |
|
|
93
|
-
| `low` | gris |
|
|
94
|
-
|
|
95
|
-
> ⚠️ Sí: `medium` se pinta en **verde**. Es el comportamiento actual del plugin y sorprende la primera vez.
|
|
96
|
-
> Guíate por el texto de la etiqueta, no por el color.
|
|
1
|
+
# Recorrido por la UI
|
|
2
|
+
|
|
3
|
+
Pinocchio es un canal, así que se abre como cualquier otro canal de Kwirth: eliges el canal **Pinocchio** en
|
|
4
|
+
el selector y lo arrancas. No tiene diálogo de *Setup* — no hay nada que configurar antes de arrancar.
|
|
5
|
+
|
|
6
|
+
## La pestaña
|
|
7
|
+
|
|
8
|
+
La pestaña es una única tarjeta con una cabecera y un flujo de mensajes que crece hacia abajo.
|
|
9
|
+
|
|
10
|
+
|
|
11
|
+
|
|
12
|
+
**Cabecera**
|
|
13
|
+
|
|
14
|
+
| Elemento | Qué es |
|
|
15
|
+
|--------------|-------------------------------------------------------------------------------|
|
|
16
|
+
| `Events: N` | Número de entradas en el flujo (análisis + mensajes). No es el número de findings. |
|
|
17
|
+
| `Status` | `started`, `paused` o `stopped`, según el estado del canal. |
|
|
18
|
+
| **Clear** | Abre el diálogo de limpieza (ver abajo). |
|
|
19
|
+
| **Playground** | Abre el banco de pruebas. Ver [El Playground](06-playground.md). |
|
|
20
|
+
| **Config** | Abre el menú de configuración. |
|
|
21
|
+
|
|
22
|
+
**Flujo**
|
|
23
|
+
|
|
24
|
+
El cuerpo hace autoscroll al final mientras estés abajo del todo; si subes a leer algo, deja de seguirte
|
|
25
|
+
hasta que vuelvas al final. Cada análisis se pinta como:
|
|
26
|
+
|
|
27
|
+
1. Una línea de cabecera con la marca de tiempo, el evento (`ADDED Deployment 'nginx' in namespace 'demo'`),
|
|
28
|
+
el LLM usado y los tokens consumidos, más un botón **Report**.
|
|
29
|
+
2. Los **findings**, ordenados de `critical` a `low`, cada uno con su etiqueta de severidad.
|
|
30
|
+
3. Una **tira de resumen** con PSS, el recuento por severidad y el riesgo global.
|
|
31
|
+
|
|
32
|
+
Los findings y la tira de resumen son **clicables** y abren su diálogo de detalle.
|
|
33
|
+
|
|
34
|
+
## El menú Config
|
|
35
|
+
|
|
36
|
+
El botón **Config** abre un menú de tres entradas, la primera de ellas un grupo desplegable. El orden no es
|
|
37
|
+
casual: cada una depende de la anterior.
|
|
38
|
+
|
|
39
|
+
|
|
40
|
+
|
|
41
|
+
| Entrada | Se habilita cuando… | Qué configura |
|
|
42
|
+
|-------------------|----------------------------------------|--------------------------------------------------|
|
|
43
|
+
| **AI** ▸ **AI providers** | siempre | Proveedores de IA (OpenAI, Google, …) y su API key |
|
|
44
|
+
| **AI** ▸ **AI models** | hay al menos un provider | Modelos concretos, con temperatura y coste |
|
|
45
|
+
| **Trigger** | hay al menos un LLM | Los triggers y sus versiones |
|
|
46
|
+
| **Import / Export** | siempre | Volcado y carga de triggers en JSON |
|
|
47
|
+
|
|
48
|
+
**AI** es un grupo plegable —el patrón habitual de Kwirth, el mismo que usan Excubitor y Agora— y **arranca
|
|
49
|
+
plegado**: hay que clicarlo para ver *AI providers* y *AI models*. Es lo que menos se toca una vez montado,
|
|
50
|
+
por eso está recogido.
|
|
51
|
+
|
|
52
|
+
Si abres Pinocchio por primera vez y **Trigger** está en gris, no es un fallo: es que aún no hay un LLM
|
|
53
|
+
configurado. Empieza por **AI ▸ AI providers**. El detalle está en
|
|
54
|
+
[Providers y modelos de IA](../admin/02-ai-config.md).
|
|
55
|
+
|
|
56
|
+
> Los diálogos de **AI providers** y **AI models** no son de Pinocchio: son los diálogos comunes de IA de
|
|
57
|
+
> Kwirth (`AiConfigProvider` / `AiConfigLlm`), los mismos que usan los demás plugins con IA. Lo que configures
|
|
58
|
+
> aquí lo verán también ellos.
|
|
59
|
+
|
|
60
|
+
## Los diálogos de detalle
|
|
61
|
+
|
|
62
|
+
**Detalle de un finding** (clic en cualquier finding) — muestra, en dos columnas, todo lo que el modelo
|
|
63
|
+
rellenó: Control ID, categoría, confianza, *risk score*, descripción, evidencia e impacto a la izquierda;
|
|
64
|
+
remediación y referencias a la derecha. Los campos vacíos no se pintan.
|
|
65
|
+
|
|
66
|
+
**Detalle del análisis** (clic en la tira de resumen) — el recurso analizado (kind, nombre, namespace,
|
|
67
|
+
imágenes), PSS actual y objetivo, riesgo global y recuento por severidad a la izquierda; controles superados,
|
|
68
|
+
lo que el modelo **no pudo ver** y los próximos pasos a la derecha.
|
|
69
|
+
|
|
70
|
+
**Report** (botón *Report* de la cabecera del análisis) — abre el informe en markdown renderizado. El botón
|
|
71
|
+
está deshabilitado si ese análisis no trajo informe.
|
|
72
|
+
|
|
73
|
+
## El diálogo Clear
|
|
74
|
+
|
|
75
|
+
Hay dos limpiezas distintas y conviene no confundirlas, porque una es local y la otra afecta a todo el mundo:
|
|
76
|
+
|
|
77
|
+
|
|
78
|
+
|
|
79
|
+
- **Clear my view** — vacía **tu** pantalla. El backend conserva sus análisis y te los reenviará si
|
|
80
|
+
reconectas.
|
|
81
|
+
- **Clear back** — borra los análisis guardados **en el canal**. Afecta a todos los fronts conectados y no
|
|
82
|
+
tiene vuelta atrás.
|
|
83
|
+
|
|
84
|
+
## Colores de severidad
|
|
85
|
+
|
|
86
|
+
Los mismos en toda la UI:
|
|
87
|
+
|
|
88
|
+
| Nivel | Color |
|
|
89
|
+
|------------|----------|
|
|
90
|
+
| `critical` | rojo |
|
|
91
|
+
| `high` | naranja |
|
|
92
|
+
| `medium` | verde |
|
|
93
|
+
| `low` | gris |
|
|
94
|
+
|
|
95
|
+
> ⚠️ Sí: `medium` se pinta en **verde**. Es el comportamiento actual del plugin y sorprende la primera vez.
|
|
96
|
+
> Guíate por el texto de la etiqueta, no por el color.
|
package/user/05-findings.md
CHANGED
|
@@ -1,108 +1,108 @@
|
|
|
1
|
-
# Leer los findings
|
|
2
|
-
|
|
3
|
-
Un análisis de tipo `artifact` no devuelve texto libre: devuelve un **objeto con un esquema fijo** que el
|
|
4
|
-
modelo está obligado a rellenar. Esta página explica qué significa cada campo y —más importante— **cuánto
|
|
5
|
-
te puedes fiar de él**.
|
|
6
|
-
|
|
7
|
-
## La línea de cabecera
|
|
8
|
-
|
|
9
|
-
```
|
|
10
|
-
2026-09-08T10:14:22.145Z ADDED Deployment 'api-gateway' in namespace 'prod'
|
|
11
|
-
[LLM:google/gemini-2.0-flash, IN:4821, OUT:1103]
|
|
12
|
-
```
|
|
13
|
-
|
|
14
|
-
- El evento que disparó el análisis.
|
|
15
|
-
- El **provider y el modelo** que lo produjeron. Útil cuando comparas versiones de un trigger.
|
|
16
|
-
- **IN / OUT** — tokens de entrada y de salida. Es tu factura. Si un trigger te sorprende en el coste, aquí
|
|
17
|
-
está la respuesta.
|
|
18
|
-
|
|
19
|
-
## Los findings
|
|
20
|
-
|
|
21
|
-
Cada finding es un hallazgo concreto. En la lista sólo se ven la severidad y la descripción; el resto está a
|
|
22
|
-
un clic.
|
|
23
|
-
|
|
24
|
-
| Campo | Valores | Qué es |
|
|
25
|
-
|----------------|-----------------------------------------------------------------------------------------|--------|
|
|
26
|
-
| `level` | `critical` · `high` · `medium` · `low` | Severidad. Ordena la lista. |
|
|
27
|
-
| `control_id` | texto | Identificador del control que se incumple. |
|
|
28
|
-
| `control_name` | texto | Nombre legible del control. Es el título del diálogo de detalle. |
|
|
29
|
-
| `category` | `privileges` · `identity` · `network` · `filesystem` · `supply_chain` · `resources` · `secrets` · `general` · `platform` | Familia del hallazgo. |
|
|
30
|
-
| `confidence` | `low` · `medium` · `high` | Cuánta seguridad dice tener **el modelo**. |
|
|
31
|
-
| `evidence` | texto | El fragmento concreto que lo demuestra. |
|
|
32
|
-
| `impact` | texto | Qué puede pasar si no se arregla. |
|
|
33
|
-
| `remediation` | texto | Cómo arreglarlo. |
|
|
34
|
-
| `references` | lista | Enlaces o identificadores de referencia. |
|
|
35
|
-
| `risk_score` | número | Puntuación numérica que asigna el modelo. |
|
|
36
|
-
|
|
37
|
-
> **El campo que hay que mirar siempre es `evidence`.** Un finding con evidencia concreta ("el contenedor
|
|
38
|
-
> `api` declara `securityContext.privileged: true`") es verificable en dos segundos. Un finding sin
|
|
39
|
-
> evidencia, o con evidencia genérica, es una alucinación candidata. Cruza `confidence` con `evidence`
|
|
40
|
-
> antes de abrir un ticket.
|
|
41
|
-
|
|
42
|
-
En la lista, si la descripción contiene un fragmento entre ` **` y `** `, se pinta en negrita y subrayado.
|
|
43
|
-
Es un pequeño formateo heredado; no es markdown completo.
|
|
44
|
-
|
|
45
|
-
## La tira de resumen
|
|
46
|
-
|
|
47
|
-
Bajo los findings aparece una tira con el resumen del análisis. Se puede clicar para ver el detalle completo.
|
|
48
|
-
|
|
49
|
-
**PSS: `baseline` → `restricted`**
|
|
50
|
-
|
|
51
|
-
Los [Pod Security Standards](https://kubernetes.io/docs/concepts/security/pod-security-standards/) de
|
|
52
|
-
Kubernetes. `pss_current` es el nivel que el modelo considera que cumple el recurso **tal como está**;
|
|
53
|
-
`pss_target` es al que podría llegar aplicando las remediaciones. Los valores posibles son `privileged`,
|
|
54
|
-
`baseline`, `restricted` y `undefined`.
|
|
55
|
-
|
|
56
|
-
`privileged` es el nivel **más permisivo** (sin restricciones) y `restricted` el **más estricto**. Si ves
|
|
57
|
-
`pss_current: privileged`, es una mala noticia, no una buena.
|
|
58
|
-
|
|
59
|
-
**critical:0 high:2 medium:5 low:1**
|
|
60
|
-
|
|
61
|
-
El `score_summary`: recuento de findings por severidad, tal como lo cuenta el modelo.
|
|
62
|
-
|
|
63
|
-
**Riesgo global**
|
|
64
|
-
|
|
65
|
-
`global_risk`, la valoración de conjunto: `low`, `medium`, `high` o `critical`.
|
|
66
|
-
|
|
67
|
-
## El detalle del análisis
|
|
68
|
-
|
|
69
|
-
Al clicar la tira se abren tres cosas que no caben en la línea de resumen:
|
|
70
|
-
|
|
71
|
-
- **Controls passed** — los controles que el recurso **sí** cumple. Sirve para ver que el modelo ha hecho el
|
|
72
|
-
repaso completo y no sólo ha buscado fallos.
|
|
73
|
-
- **Not visible** — los controles que el modelo **no ha podido evaluar** con la información que tenía. Este
|
|
74
|
-
campo es oro: te dice dónde el análisis es incompleto y qué tool deberías haberle dado. Si `not_visible`
|
|
75
|
-
está lleno, sube los `steps` o añade tools.
|
|
76
|
-
- **Next steps** — la lista de acciones recomendadas, en orden.
|
|
77
|
-
|
|
78
|
-
También muestra el **recurso** analizado (kind, nombre, namespace e imágenes) tal como lo identificó el
|
|
79
|
-
modelo. Compáralo con la línea de cabecera: si no coinciden, el modelo se ha confundido de objeto y el
|
|
80
|
-
análisis entero es sospechoso.
|
|
81
|
-
|
|
82
|
-
## El informe
|
|
83
|
-
|
|
84
|
-
El botón **Report** abre el campo `report`: un informe **en markdown** redactado por el modelo, pensado para
|
|
85
|
-
leerse como documento y no como lista. Se renderiza con el visor de markdown de
|
|
86
|
-
|
|
87
|
-
Es la salida que puedes pegar en un ticket o en un correo. Los findings son para triar; el informe es para
|
|
88
|
-
explicar.
|
|
89
|
-
|
|
90
|
-
## Cuando algo falla
|
|
91
|
-
|
|
92
|
-
Si la llamada al modelo revienta, Pinocchio **no se calla**: publica un análisis con dos findings de nivel
|
|
93
|
-
`critical`, uno con el mensaje de error legible y otro con el error serializado entero. Verás algo como:
|
|
94
|
-
|
|
95
|
-
```
|
|
96
|
-
critical Pinocchio analysis ended in error while processing 'events' when
|
|
97
|
-
analyzing 'api-gateway' in namespace 'prod' [Kind:Deployment]
|
|
98
|
-
critical {"name":"AI_APICallError","message":"...
|
|
99
|
-
```
|
|
100
|
-
|
|
101
|
-
Las causas más habituales: API key caducada, cuota agotada en el proveedor, o el modelo elegido no soporta
|
|
102
|
-
salida estructurada. El segundo finding, aunque sea feo, suele traer el mensaje exacto del proveedor.
|
|
103
|
-
|
|
104
|
-
## Análisis de triggers `business`
|
|
105
|
-
|
|
106
|
-
Los triggers de negocio **no producen findings**. Su salida es un único campo de texto que aparece en el
|
|
107
|
-
flujo como un mensaje normal, precedido de otro mensaje con el evento recibido. Nada de PSS, ni severidades,
|
|
108
|
-
ni informe.
|
|
1
|
+
# Leer los findings
|
|
2
|
+
|
|
3
|
+
Un análisis de tipo `artifact` no devuelve texto libre: devuelve un **objeto con un esquema fijo** que el
|
|
4
|
+
modelo está obligado a rellenar. Esta página explica qué significa cada campo y —más importante— **cuánto
|
|
5
|
+
te puedes fiar de él**.
|
|
6
|
+
|
|
7
|
+
## La línea de cabecera
|
|
8
|
+
|
|
9
|
+
```
|
|
10
|
+
2026-09-08T10:14:22.145Z ADDED Deployment 'api-gateway' in namespace 'prod'
|
|
11
|
+
[LLM:google/gemini-2.0-flash, IN:4821, OUT:1103]
|
|
12
|
+
```
|
|
13
|
+
|
|
14
|
+
- El evento que disparó el análisis.
|
|
15
|
+
- El **provider y el modelo** que lo produjeron. Útil cuando comparas versiones de un trigger.
|
|
16
|
+
- **IN / OUT** — tokens de entrada y de salida. Es tu factura. Si un trigger te sorprende en el coste, aquí
|
|
17
|
+
está la respuesta.
|
|
18
|
+
|
|
19
|
+
## Los findings
|
|
20
|
+
|
|
21
|
+
Cada finding es un hallazgo concreto. En la lista sólo se ven la severidad y la descripción; el resto está a
|
|
22
|
+
un clic.
|
|
23
|
+
|
|
24
|
+
| Campo | Valores | Qué es |
|
|
25
|
+
|----------------|-----------------------------------------------------------------------------------------|--------|
|
|
26
|
+
| `level` | `critical` · `high` · `medium` · `low` | Severidad. Ordena la lista. |
|
|
27
|
+
| `control_id` | texto | Identificador del control que se incumple. |
|
|
28
|
+
| `control_name` | texto | Nombre legible del control. Es el título del diálogo de detalle. |
|
|
29
|
+
| `category` | `privileges` · `identity` · `network` · `filesystem` · `supply_chain` · `resources` · `secrets` · `general` · `platform` | Familia del hallazgo. |
|
|
30
|
+
| `confidence` | `low` · `medium` · `high` | Cuánta seguridad dice tener **el modelo**. |
|
|
31
|
+
| `evidence` | texto | El fragmento concreto que lo demuestra. |
|
|
32
|
+
| `impact` | texto | Qué puede pasar si no se arregla. |
|
|
33
|
+
| `remediation` | texto | Cómo arreglarlo. |
|
|
34
|
+
| `references` | lista | Enlaces o identificadores de referencia. |
|
|
35
|
+
| `risk_score` | número | Puntuación numérica que asigna el modelo. |
|
|
36
|
+
|
|
37
|
+
> **El campo que hay que mirar siempre es `evidence`.** Un finding con evidencia concreta ("el contenedor
|
|
38
|
+
> `api` declara `securityContext.privileged: true`") es verificable en dos segundos. Un finding sin
|
|
39
|
+
> evidencia, o con evidencia genérica, es una alucinación candidata. Cruza `confidence` con `evidence`
|
|
40
|
+
> antes de abrir un ticket.
|
|
41
|
+
|
|
42
|
+
En la lista, si la descripción contiene un fragmento entre ` **` y `** `, se pinta en negrita y subrayado.
|
|
43
|
+
Es un pequeño formateo heredado; no es markdown completo.
|
|
44
|
+
|
|
45
|
+
## La tira de resumen
|
|
46
|
+
|
|
47
|
+
Bajo los findings aparece una tira con el resumen del análisis. Se puede clicar para ver el detalle completo.
|
|
48
|
+
|
|
49
|
+
**PSS: `baseline` → `restricted`**
|
|
50
|
+
|
|
51
|
+
Los [Pod Security Standards](https://kubernetes.io/docs/concepts/security/pod-security-standards/) de
|
|
52
|
+
Kubernetes. `pss_current` es el nivel que el modelo considera que cumple el recurso **tal como está**;
|
|
53
|
+
`pss_target` es al que podría llegar aplicando las remediaciones. Los valores posibles son `privileged`,
|
|
54
|
+
`baseline`, `restricted` y `undefined`.
|
|
55
|
+
|
|
56
|
+
`privileged` es el nivel **más permisivo** (sin restricciones) y `restricted` el **más estricto**. Si ves
|
|
57
|
+
`pss_current: privileged`, es una mala noticia, no una buena.
|
|
58
|
+
|
|
59
|
+
**critical:0 high:2 medium:5 low:1**
|
|
60
|
+
|
|
61
|
+
El `score_summary`: recuento de findings por severidad, tal como lo cuenta el modelo.
|
|
62
|
+
|
|
63
|
+
**Riesgo global**
|
|
64
|
+
|
|
65
|
+
`global_risk`, la valoración de conjunto: `low`, `medium`, `high` o `critical`.
|
|
66
|
+
|
|
67
|
+
## El detalle del análisis
|
|
68
|
+
|
|
69
|
+
Al clicar la tira se abren tres cosas que no caben en la línea de resumen:
|
|
70
|
+
|
|
71
|
+
- **Controls passed** — los controles que el recurso **sí** cumple. Sirve para ver que el modelo ha hecho el
|
|
72
|
+
repaso completo y no sólo ha buscado fallos.
|
|
73
|
+
- **Not visible** — los controles que el modelo **no ha podido evaluar** con la información que tenía. Este
|
|
74
|
+
campo es oro: te dice dónde el análisis es incompleto y qué tool deberías haberle dado. Si `not_visible`
|
|
75
|
+
está lleno, sube los `steps` o añade tools.
|
|
76
|
+
- **Next steps** — la lista de acciones recomendadas, en orden.
|
|
77
|
+
|
|
78
|
+
También muestra el **recurso** analizado (kind, nombre, namespace e imágenes) tal como lo identificó el
|
|
79
|
+
modelo. Compáralo con la línea de cabecera: si no coinciden, el modelo se ha confundido de objeto y el
|
|
80
|
+
análisis entero es sospechoso.
|
|
81
|
+
|
|
82
|
+
## El informe
|
|
83
|
+
|
|
84
|
+
El botón **Report** abre el campo `report`: un informe **en markdown** redactado por el modelo, pensado para
|
|
85
|
+
leerse como documento y no como lista. Se renderiza con el visor de markdown de Kwirth.
|
|
86
|
+
|
|
87
|
+
Es la salida que puedes pegar en un ticket o en un correo. Los findings son para triar; el informe es para
|
|
88
|
+
explicar.
|
|
89
|
+
|
|
90
|
+
## Cuando algo falla
|
|
91
|
+
|
|
92
|
+
Si la llamada al modelo revienta, Pinocchio **no se calla**: publica un análisis con dos findings de nivel
|
|
93
|
+
`critical`, uno con el mensaje de error legible y otro con el error serializado entero. Verás algo como:
|
|
94
|
+
|
|
95
|
+
```
|
|
96
|
+
critical Pinocchio analysis ended in error while processing 'events' when
|
|
97
|
+
analyzing 'api-gateway' in namespace 'prod' [Kind:Deployment]
|
|
98
|
+
critical {"name":"AI_APICallError","message":"...
|
|
99
|
+
```
|
|
100
|
+
|
|
101
|
+
Las causas más habituales: API key caducada, cuota agotada en el proveedor, o el modelo elegido no soporta
|
|
102
|
+
salida estructurada. El segundo finding, aunque sea feo, suele traer el mensaje exacto del proveedor.
|
|
103
|
+
|
|
104
|
+
## Análisis de triggers `business`
|
|
105
|
+
|
|
106
|
+
Los triggers de negocio **no producen findings**. Su salida es un único campo de texto que aparece en el
|
|
107
|
+
flujo como un mensaje normal, precedido de otro mensaje con el evento recibido. Nada de PSS, ni severidades,
|
|
108
|
+
ni informe.
|