CreaRack-SL

Corrección: .mcp.json hallazgo falso (nunca en git); P1a ejecutado (rotación MCP_TOKENS + workflow)

Hallazgo falso: .mcp.json en git

Durante la auditoría s216 (10-07-2026, workspace), el reporte inicial afirmó:

🔴 Secretos versionados en .mcp.json (VERIFICADO): Bearer del MCP + CF-Access-Client-Secret en texto plano, trackeados en git.

Falsedad descubierta (misma auditoría, 2ª verificación): El archivo .mcp.json NUNCA entró al repositorio git — ha estado en .gitignore desde el inicio en ambos repos (workspace y CreaRack-Pro). La primera “verificación” fue un error de cadena lógica (&& mal construida en bash).

Lección: La segunda verificación contra git log --all fue lo que reveló la falsedad. Debería haberse cuestionado el diagnóstico cuando no apareció en el historial.


Exposición real (sí grave, pero diferente)

AspectoDetalle
¿Dónde están?Archivos locales .mcp.json en los 3 PCs del equipo (Edu, Dani, Txell)
¿Qué llevan?Token MCP (Bearer) en claro + CF Access secret en claro
¿Qué está mal?El mismo token para los 3 usuarios — las credenciales de Edu se usaban también desde los PCs de Dani y Txell
Impacto en auditoríaEl activity_log del MCP registraba “usuario: edu” para cambios realizados desde cualquiera de los 3 PCs (atribución falsa)
¿Comprometido?No: el token nunca estuvo expuesto públicamente (en git, en un servidor, etc.). Riesgo = interno (alguien con acceso al PC local podría leerlo)

Decisión P1a: Rotación ejecutada la misma noche

Orden de Edu (tras la corrección de falsedad): ejecutar P1a esa misma noche.

Cambios ejecutados

1. Token MCP (MCP_TOKENS)

Antes (1 token compartido):

MCP_TOKENS=Edu:abc123...xyz,Dani:abc123...xyz,Txell:abc123...xyz

(Los 3 tenían el mismo token bajo sus nombres)

Después (4 tokens únicos):

MCP_TOKENS=Edu:<nuevo-único>,Dani:<nuevo-único>,Txell:<nuevo-único>,CI:<nuevo-único>
  • Edu/Dani/Txell: tokens criptográficos nuevos (CSPRNG, 40 chars) — cada uno diferente
  • CI: token nuevo para GitHub Actions (workspace repo) + crons OPS (sin atribución a un usuario)

Generados con scripts/generate-mcp-tokens.ps1 (refactorizado: CSPRNG en lugar de Get-Random).

2. Configuración en Cloudflare Pages

  • Antes: escritura manual en la UI
  • Después: workflow automatizado .github/workflows/rotate-mcp-tokens.yml — PATCH vía API CF, bajo demanda

El CF_CLAUDE_TOKEN de Edu no tiene scope Pages, así que el workflow usa CLOUDFLARE_API_TOKEN (repo secret, scope acotado).

3. Migración de .mcp.json a variables de entorno

Antes:

{
  "tokens": {
    "mcp_workspace": "Edu:abc123..."  // hardcoded, valor en claro
  }
}

Después (versionado en git):

{
  "tokens": {
    "mcp_workspace": "${BIB_MCP_TOKEN}"  // expansion de variable de entorno
  }
}
  • Archivo versionado: .mcp.json ahora usa ${BIB_MCP_TOKEN} (variable del sistema Windows)
  • Archivo local (no en git): cada PC tiene su propio token en la variable de entorno del usuario

4. Actualización del inventario y playbook

  • crearack-tech--guides--inventario-de-secretos.md: añadido token CI + historial de rotación (fecha, razón, quién)
  • crearack-tech--guides--secret-rotation-playbook.md §6: reescrito con pasos exactos para futuras rotaciones
    • Generar 4 tokens
    • Publicar secret temporal MCP_TOKENS_NEW
    • Disparar workflow rotate-mcp-tokens.yml
    • Consumidores: GH Actions (workspace + Pro), OPS crons, env User (3 PCs)
    • Limpiar secret temporal

P1b: Pendiente (CF Access service token)

El CF Access secret (ea9f61… en OPS) no fue tocado en P1a porque:

  1. Urgencia rebajada: nunca estuvo en git (gitignored) — riesgo solo local
  2. Coordinación más compleja: rotación instantánea en el edge (CF /rotate), hay que sincronizar:
    • GH secrets en 2 repos (workspace + CreaRack-Pro)
    • /opt/bib-reindex/.cf-access-secret en OPS
    • Env User en 3 PCs
    • Dokploy PROD/STAGE (redeploy obligatorio — la rotación no propaga al edge)

Dueño: Edu (ventana ~10 minutos sin prisa).


Verificaciones post-rotación

Realizadas:

  • ✅ MCP tools: validar con MCP_TOKEN nuevo = 200, con viejo = 401
  • ✅ Workflows GH: verificar que MCP_TOKEN nuevo en workspace repo + CreaRack-Pro está activo
  • ✅ OPS crons: prueba manual de /opt/bib-reindex/cron-*.sh con token CI nuevo
  • ✅ Perfiles locales: Dani y Txell actualizaron su env var BIB_MCP_TOKEN (tarea en el Gestor)

Cierre

Esta decisión registra una corrección de hallazgo falso (.mcp.json nunca en git) + la ejecución inmediata de mitigation (rotación de tokens + workflow permanente). El proceso expone la importancia de re-verificar hallazgos sorprendentes y no asumir “verificado” sin un segundo método independiente.

Véase también

  • [[entity—ci—workflow—rotate-mcp-tokens]]
  • [[entity—ci—script—generate-mcp-tokens]]
  • [[crearack-tech—guides—secret-rotation-playbook]]
  • [[crearack-tech—guides—inventario-de-secretos]]
  • [[incident—20260710—exposicion-mcp-tokens-local]]