275 lines
15 KiB
Markdown
275 lines
15 KiB
Markdown
# Decision: IA y agentes para operaciones de infraestructura
|
|
|
|
## Contexto
|
|
|
|
Gestionamos 100-500 servidores PVE/PBS con un equipo tecnico reducido. Ya tenemos decidido: Ansible + Semaphore (automatizacion), n8n (orquestacion futura), Netbox (inventario), Zammad (tickets), VictoriaMetrics + Loki (metricas/logs), Wazuh (seguridad), Grafana (dashboards). La pregunta es: como integramos IA para que nos ayude operativamente.
|
|
|
|
Dos dimensiones: uso interactivo (tecnico + IA) y agentes automatizados (IA trabaja sola o semi-sola).
|
|
|
|
---
|
|
|
|
## 8.1 Claude Code interactivo: copiloto para tecnicos
|
|
|
|
### Que es
|
|
|
|
Claude Code es un CLI que se instala en una maquina Linux. El tecnico abre terminal, ejecuta `claude`, y trabaja de forma conversacional. Claude Code puede leer ficheros, ejecutar comandos, buscar en el codigo, y generar scripts/playbooks.
|
|
|
|
### Donde se instala
|
|
|
|
En la **VM Bastion** (ya existe, SSH jump host). El tecnico hace SSH al bastion y desde ahi usa Claude Code con acceso a:
|
|
|
|
- Repos Forgejo clonados (playbooks Ansible, scripts)
|
|
- CLI de PBS via SSH a los nodos (`proxmox-backup-manager`)
|
|
- CLI de ZFS via SSH
|
|
- Logs locales y remotos
|
|
- API de Netbox, PBS, PVE (curl)
|
|
|
|
### Casos de uso reales
|
|
|
|
| Escenario | Que hace el tecnico | Que hace Claude Code |
|
|
|-----------|--------------------|--------------------|
|
|
| GC lleva 3 dias | "revisa el GC del cliente ACME" | Lee logs, estado del job, uso de disco, diagnóstica |
|
|
| Cliente nuevo | "genera playbook para cliente X, 200GB, sync desde pbs3343" | Genera YAML validado siguiendo el patron existente |
|
|
| Alerta Wazuh | "analiza esta alerta de file integrity" | Lee evento, correlaciona con logs, valora si es falso positivo |
|
|
| Script heredado | "que hace status_disk.sh y como mejorarlo" | Lee, documenta, sugiere mejoras |
|
|
| Incidencia disco | "el pool9 del pbs tiene IO alto" | Revisa iostat, zpool status, encuentra el dataset problematico |
|
|
| Post-mortem | "genera el timeline del incidente de ayer" | Lee logs de Loki, Wazuh, metricas, construye cronologia |
|
|
|
|
### Implementacion
|
|
|
|
```bash
|
|
# En VM Bastion (Debian 12)
|
|
curl -fsSL https://claude.ai/install.sh | bash
|
|
# Configurar API key
|
|
export ANTHROPIC_API_KEY="sk-ant-..."
|
|
|
|
# Crear CLAUDE.md con contexto de la infra
|
|
cat > /root/CLAUDE.md << 'EOF'
|
|
# Infraestructura DoCloud
|
|
- Pool ZFS: pool9 (PBS), pool10 (PVE)
|
|
- Playbooks: /opt/ansible/
|
|
- Scripts legacy: /root/*.sh
|
|
- PBS API: https://localhost:8007
|
|
- Netbox API: https://netbox.internal/api/
|
|
- Clientes: ver `proxmox-backup-manager datastore list`
|
|
EOF
|
|
```
|
|
|
|
### Recursos
|
|
|
|
- CPU/RAM: despreciable (solo durante uso interactivo)
|
|
- Coste: API key Anthropic, ~$20-50/mes segun uso del equipo
|
|
- No requiere VM dedicada (va en Bastion existente)
|
|
|
|
### Seguridad
|
|
|
|
- El tecnico ya tiene acceso SSH al bastion con sus credenciales
|
|
- Claude Code hereda los permisos del usuario que lo ejecuta
|
|
- No abre puertos, no es un servicio, no tiene persistencia
|
|
- Logs de sesion almacenables para auditoria
|
|
|
|
---
|
|
|
|
## 8.2 Agentes automatizados via n8n + API Claude
|
|
|
|
### Arquitectura
|
|
|
|
Los agentes no son procesos permanentes. Son **workflows de n8n** que se disparan por un trigger (alerta, cron, webhook), enriquecen contexto consultando APIs, llaman a Claude API con un prompt especializado, y actuan sobre el resultado (crear ticket, generar informe, notificar).
|
|
|
|
```
|
|
Triggers Agentes (n8n workflows) Acciones
|
|
┌──────────────┐ ┌─────────────────────┐ ┌──────────────┐
|
|
│ Alertmanager ├──────────────►│ Triaje de alertas ├─────────►│ Ticket Zammad│
|
|
│ │ │ (prompt seguridad) │ │ │
|
|
├──────────────┤ ├─────────────────────┤ ├──────────────┤
|
|
│ Cron semanal ├──────────────►│ Capacity planning ├─────────►│ Informe │
|
|
│ │ │ (prompt storage) │ │ Outline │
|
|
├──────────────┤ ├─────────────────────┤ ├──────────────┤
|
|
│ Wazuh alert ├──────────────►│ Analisis seguridad ├─────────►│ Ticket Zammad│
|
|
│ (nivel ≥10) │ │ (prompt forense) │ │ + Mattermost │
|
|
├──────────────┤ ├─────────────────────┤ ├──────────────┤
|
|
│ Zammad ticket├──────────────►│ Provisioning assist ├─────────►│ MR en Forgejo│
|
|
│ (alta-client)│ │ (prompt ansible) │ │ │
|
|
└──────────────┘ └────────┬────────────┘ └──────────────┘
|
|
│
|
|
Consultas read-only
|
|
┌───────────┼───────────┐
|
|
│ │ │
|
|
VictoriaMetrics Loki Netbox
|
|
(metricas) (logs) (inventario)
|
|
```
|
|
|
|
### Agente 1: Triaje de alertas (mayor ROI)
|
|
|
|
- **Trigger**: Alertmanager envia webhook a n8n
|
|
- **Contexto que recopila**:
|
|
- Metricas del servidor afectado (VictoriaMetrics API, ultimas 2h)
|
|
- Logs recientes del servidor (Loki API, ultimos 30 min)
|
|
- Datos del servidor en Netbox (cliente, tipo, rol, SLA)
|
|
- Historial de alertas similares (VictoriaMetrics alerts API)
|
|
- **Prompt especializado**: incluye la definicion de severidades de la empresa, SLAs por cliente, y arboles de decision para problemas comunes (disco, CPU, backup fallido, conectividad)
|
|
- **Output**: Ticket en Zammad con: severidad calculada, diagnostico, acciones recomendadas, metricas relevantes embebidas
|
|
- **Ejemplo real**: Alerta "pbs_gc_duration_seconds > 86400 en ACME" → agente consulta tamaño datastore, snapshots, ultimo GC exitoso, y genera: "GC de ACME lleva 26h. Datastore: 1.2TB, 340 snapshots. Ultimo GC exitoso: hace 12 dias. Recomendacion: verificar si hay un sync job concurrente bloqueando. Si no, considerar maintenance-mode y GC forzado."
|
|
|
|
### Agente 2: Capacity planning (semanal)
|
|
|
|
- **Trigger**: Cron lunes 08:00
|
|
- **Contexto**: Uso de disco de todos los datastores (VictoriaMetrics), quotas ZFS, tendencias 30/60/90 dias
|
|
- **Output**: Informe en Outline con tabla priorizada:
|
|
|
|
```
|
|
| Cliente | Usado | Quota | Tendencia 30d | Dias hasta lleno | Accion |
|
|
|---------|-------|-------|---------------|------------------|--------|
|
|
| ACME | 82% | 600GB | +2.1%/semana | ~45 dias | Avisar |
|
|
| GAMMA | 91% | 300GB | +5.3%/semana | ~12 dias | URGENTE|
|
|
| BETA | 34% | 1TB | estable | >1 año | OK |
|
|
```
|
|
|
|
### Agente 3: Analisis de seguridad (evento Wazuh)
|
|
|
|
- **Trigger**: Wazuh alerta nivel ≥10 via webhook
|
|
- **Contexto**: Evento Wazuh completo, logs Loki del servidor (misma ventana), eventos correlacionados (mismo servidor, ultima hora), baseline de comportamiento normal del servidor
|
|
- **Output**: Ticket Zammad clasificado:
|
|
- **Falso positivo**: justificacion detallada de por que es benigno
|
|
- **Incidente real**: pasos de respuesta recomendados, basados en el playbook de incidentes (decision-incidentes.md)
|
|
- **Indeterminado**: que verificaciones adicionales hacer manualmente
|
|
|
|
### Agente 4: Asistente de provisioning
|
|
|
|
- **Trigger**: Ticket Zammad con tag "alta-cliente" o webhook ICSManager
|
|
- **Contexto**: Datos del cliente (nombre, GB, servidor sync), inventario Netbox (verificar duplicados), recursos disponibles en PVE destino
|
|
- **Output**: Branch en Forgejo con YAML del cliente listo para revisar, o ticket actualizado con datos validados para lanzar playbook desde Semaphore
|
|
|
|
### Implementacion en n8n
|
|
|
|
Cada agente es un workflow con estos nodos:
|
|
|
|
```
|
|
Webhook/Cron → HTTP Request(s) → Claude API → IF/Switch → Action(s)
|
|
(trigger) (recopilar (analizar) (decidir) (actuar)
|
|
contexto)
|
|
```
|
|
|
|
El nodo "Claude API" es un HTTP Request a `https://api.anthropic.com/v1/messages` con:
|
|
- System prompt: instrucciones especializadas del agente + contexto de la infra
|
|
- User message: datos recopilados en los pasos anteriores
|
|
- Modelo: `claude-sonnet-4-6` para agentes rutinarios (mas barato, suficiente), `claude-opus-4-6` para analisis de seguridad (maximo razonamiento)
|
|
|
|
### Coste estimado
|
|
|
|
| Agente | Frecuencia | Tokens/ejecucion | Modelo | Coste/mes |
|
|
|--------|-----------|-------------------|--------|-----------|
|
|
| Triaje alertas | ~50-100/dia | ~3000-5000 | Sonnet | $15-30 |
|
|
| Capacity planning | 1/semana | ~10000 | Sonnet | $1-2 |
|
|
| Seguridad Wazuh | ~5-20/dia | ~5000-8000 | Opus | $10-25 |
|
|
| Provisioning | ~5-10/mes | ~3000 | Sonnet | $1-2 |
|
|
| **Total** | | | | **~$30-60/mes** |
|
|
|
|
---
|
|
|
|
## 8.3 Evaluacion de OpenClaw
|
|
|
|
### Que es OpenClaw
|
|
|
|
OpenClaw (antes Clawdbot/Moltbot) es un agente de IA open-source autonomo creado por Peter Steinberger. Se ejecuta localmente, conecta a LLMs (Claude, GPT, DeepSeek), y usa plataformas de mensajeria (WhatsApp, Telegram, Slack, Discord) como interfaz. Tiene 145k+ estrellas en GitHub y ~400k usuarios.
|
|
|
|
Caracteristicas principales:
|
|
- Corre localmente, trae tu propia API key
|
|
- Multi-canal: WhatsApp, Telegram, Slack, Signal, Teams, Matrix
|
|
- 100+ AgentSkills precofiguradas (ejecutar shell, gestionar ficheros, web automation)
|
|
- Memoria persistente entre conversaciones
|
|
- Open source (MIT)
|
|
|
|
### Ventajas potenciales para nuestro caso
|
|
|
|
| Ventaja | Detalle |
|
|
|---------|---------|
|
|
| Multi-canal | Los tecnicos podrian interactuar via Telegram/Mattermost sin SSH |
|
|
| Open source | Sin vendor lock-in, personalizable |
|
|
| Skills extensibles | Podriamos crear skills para PBS, ZFS, Netbox |
|
|
| Self-hosted | Control total de datos |
|
|
|
|
### Problemas criticos para nuestro caso
|
|
|
|
#### 1. Seguridad: INACEPTABLE para infraestructura de produccion
|
|
|
|
Este es el punto definitivo. OpenClaw tiene vulnerabilidades documentadas graves:
|
|
|
|
- **Prompt injection via skills**: Cisco demostro que skills de terceros pueden hacer data exfiltration sin que el usuario lo note
|
|
- **ClawJacked (marzo 2026)**: Vulnerabilidad que permite a atacantes controlar el agente via WebSocket local y acceder a datos del dispositivo
|
|
- **Superficie de ataque amplia**: Un agente con acceso a shell en un servidor que gestiona 100-500 servidores de clientes es exactamente el vector de ataque que acabamos de sufrir con el backdoor PAM
|
|
|
|
**Nosotros acabamos de recuperarnos de un credential stealer que tenia acceso shell. Poner un agente de IA con acceso shell y vulnerabilidades conocidas de prompt injection seria repetir el mismo error.**
|
|
|
|
#### 2. Modelo de ejecucion inadecuado
|
|
|
|
OpenClaw es un **agente personal** (asistente general) ejecutandose como demonio. Nuestras necesidades son **agentes especializados** con scope limitado que se ejecutan solo cuando hay un trigger. Diferencia fundamental:
|
|
|
|
| Aspecto | OpenClaw | Nuestro modelo (n8n + API) |
|
|
|---------|----------|---------------------------|
|
|
| Ejecucion | Demonio permanente | Bajo demanda (trigger) |
|
|
| Permisos | Acceso amplio al sistema | Read-only a APIs especificas |
|
|
| Scope | General ("haz lo que te pida") | Especializado ("triaje de alertas") |
|
|
| Auditoria | Logs propios | Logs de n8n + Loki |
|
|
| Superficie de ataque | WebSocket + shell + mensajeria | Solo API HTTP saliente |
|
|
| Acciones | Ejecuta directamente | Genera recomendaciones, humano aprueba |
|
|
|
|
#### 3. Complejidad innecesaria
|
|
|
|
- OpenClaw requiere su propia infraestructura (MongoDB para memoria, gateway, canales)
|
|
- Nosotros ya tenemos n8n (orquestacion) + Zammad (interfaz humana) + Mattermost (chat futuro)
|
|
- Añadir OpenClaw duplica funcionalidad sin añadir valor
|
|
|
|
#### 4. Gobernanza incierta
|
|
|
|
- El creador (Peter Steinberger) se unio a OpenAI en febrero 2026
|
|
- Proyecto con hype extremo pero inmaduro en seguridad
|
|
- China ha restringido su uso en agencias gubernamentales por riesgos de seguridad
|
|
|
|
### Veredicto: NO usar OpenClaw
|
|
|
|
**OpenClaw no encaja en nuestro caso por razones de seguridad y arquitectura.** No necesitamos un agente general con acceso al sistema. Necesitamos agentes especializados, scoped, auditables, sin acceso directo a shell.
|
|
|
|
Nuestro stack ya cubre todo lo que OpenClaw ofrece de forma mas segura:
|
|
- **Chat con IA**: Claude Code interactivo en Bastion (controlado, sin demonio)
|
|
- **Automatizacion con IA**: n8n + Claude API (scoped, read-only, auditable)
|
|
- **Mensajeria del equipo**: Mattermost/Zammad (ya decidido)
|
|
- **Ejecucion de tareas**: Ansible + Semaphore (aprobacion humana)
|
|
|
|
Si en el futuro OpenClaw madura en seguridad y necesitamos un asistente conversacional para tecnicos via chat, se puede reevaluar. Pero hoy, con nuestro historial de seguridad, la respuesta es clara: **no**.
|
|
|
|
---
|
|
|
|
## 8.4 Orden de implementacion
|
|
|
|
| Fase | Que | Cuando | Dependencias |
|
|
|------|-----|--------|-------------|
|
|
| **Fase 0** | Claude Code en Bastion | Dia 1, tras desplegar Bastion | Solo API key Anthropic |
|
|
| **Fase 1** | Agente triaje de alertas | Mes 1-2 | n8n desplegado, Alertmanager configurado |
|
|
| **Fase 2** | Agente capacity planning | Mes 2-3 | VictoriaMetrics con historico ≥30 dias |
|
|
| **Fase 3** | Agente analisis seguridad | Mes 3-4 | Wazuh maduro, baseline establecida |
|
|
| **Fase 4** | Agente provisioning | Mes 4+ | Playbooks Ansible estables, Netbox poblado |
|
|
|
|
### Principios de diseño de los agentes
|
|
|
|
1. **Read-only por defecto**: Los agentes consultan APIs pero nunca ejecutan comandos en produccion
|
|
2. **Humano en el bucle**: Las acciones de escritura (tickets, MRs) son para que un humano revise y apruebe
|
|
3. **Scope minimo**: Cada agente tiene un prompt especializado y solo accede a las APIs que necesita
|
|
4. **Auditabilidad**: Todo queda en n8n (historial de ejecuciones) + Loki (logs)
|
|
5. **Coste controlado**: Sonnet para tareas rutinarias, Opus solo para analisis complejos
|
|
|
|
---
|
|
|
|
## Resumen
|
|
|
|
> **Capa 8: IA y agentes para operaciones**
|
|
>
|
|
> - **8.1**: Claude Code interactivo en VM Bastion (copiloto para tecnicos, dia 1)
|
|
> - **8.2**: Agentes automatizados via n8n + Claude API (4 agentes especializados, despliegue progresivo meses 1-4)
|
|
> - **8.3**: OpenClaw evaluado y **descartado** (riesgos de seguridad inaceptables, arquitectura inadecuada, funcionalidad cubierta por stack existente)
|
|
> - **8.4**: Orden de implementacion en 4 fases
|
|
>
|
|
> **Recursos adicionales**: ninguno (Claude Code en Bastion existente, agentes en n8n ya planificado)
|
|
> **Coste operativo**: ~$30-60/mes en API Anthropic
|
|
> **Herramientas nuevas**: ninguna (todo sobre stack ya decidido)
|