Illumio MCP Server

Servidor MCP de Illumio

📚 Sitio de documentación — instalación, primeros pasos, flujos de trabajo, la referencia completa de herramientas y despliegue centralizado.

Un servidor de Model Context Protocol (MCP) que proporciona una interfaz para interactuar con Illumio PCE (Policy Compute Engine). Este servidor permite el acceso programático a la gestión de cargas de trabajo de Illumio, operaciones de etiquetas, análisis de flujo de tráfico, ringfencing automatizado e identificación de servicios de infraestructura.

¿Qué puede hacer?

Usa IA conversacional para hablar con tu PCE:

• CRUD completo en cargas de trabajo, etiquetas, listas de IP, servicios y conjuntos de reglas
• Análisis de tráfico en toda la ventana — los resúmenes agregan cada flujo que el PCE devuelve, no solo los primeros 500, e informan cuánto existe vs cuánto se muestra
• Agregación por cualquier etiqueta — app/env por defecto, o unidad de negocio, alcance de cumplimiento, rol+ubicación; cualquier dimensión que tu PCE defina
• Descubrimiento de Shadow-AI / egreso — qué proceso habla con qué proveedor, con atribución de RDAP y rangos publicados por el proveedor actualizados semanalmente en CI
• Política calificada por proceso — "solo este binario puede alcanzar esa aplicación", mediante servicios de egreso de Windows y referencias de servicios en reglas
• Ringfencing automatizado — analiza el tráfico y crea políticas de segmentación de aplicación a aplicación con un solo comando
• Aplicación selectiva — agrega reglas de denegación para aplicaciones en modo selectivo con sabores de consumidor configurables
• Identificación de servicios de infraestructura — descubre qué aplicaciones son servicios de infraestructura usando análisis de centralidad de grafos, para saber qué priorizar en las políticas
• Gestión de reglas de denegación — crea, actualiza y elimina reglas de denegación (incluyendo denegación por anulación para emergencias)
• Reglas editables en su lugar — update-sec-rule / delete-sec-rule en lugar de reconstruir un conjunto de reglas
• Monitoreo de eventos — consulta eventos del PCE con filtros de severidad y tipo
• Verificaciones de salud del PCE — verifica conectividad y credenciales
• Te avisa cuando cambia — get-server-changelog informa cambios de comportamiento a una sesión cuya lista de herramientas en caché está desactualizada

Requisitos previos

• Python 3.12 o 3.13 (consulta requires-python en pyproject.toml)
• Acceso a una instancia de Illumio PCE
• Credenciales de API válidas para el PCE

Instalación

1. Clona el repositorio:

git clone https://github.com/alexgoller/illumio-mcp-server.git
cd illumio-mcp-server

2. Instala las dependencias:

uv sync

Configuración

Debes ejecutar esto usando el comando uv, que facilita pasar variables de entorno y ejecutarlo en segundo plano.

Usando uv y Claude Desktop

En MacOS: ~/Library/Application\ Support/Claude/claude_desktop_config.json En Windows: %APPDATA%/Claude/claude_desktop_config.json

Agrega lo siguiente a la sección custom_settings:

"mcpServers": {
    "illumio-mcp": {
      "command": "uv",
      "args": [
        "--directory",
        "/path/to/illumio-mcp-server",
        "run",
        "illumio-mcp"
      ],
      "env": {
        "PCE_HOST": "your-pce-host",
        "PCE_PORT": "your-pce-port",
        "PCE_ORG_ID": "1",
        "API_KEY": "api_key",
        "API_SECRET": "api_secret"
      }
    }
  }
}

Transporte HTTP con servidor de recursos OAuth (Fase 3a)

El servidor se ejecuta sobre HTTP usando el transporte MCP Streamable HTTP (revisión de especificación 2025-03-26) y valida tokens de portador OAuth 2.1 emitidos por tu IdP. Esto es Fase 3a: la identidad se aplica; las claves PCE por usuario llegan en la Fase 3b.

Ejecución con autenticación (con forma de producción)

export MCP_PUBLIC_URL=https://mcp.illumio.example
export MCP_OAUTH_ISSUER=https://login.microsoftonline.com/<tenant-id>/v2.0
export MCP_OAUTH_JWKS_URL=https://login.microsoftonline.com/<tenant-id>/discovery/v2.0/keys
export MCP_OAUTH_AUDIENCE=https://mcp.illumio.example
export MCP_OAUTH_REQUIRED_SCOPE=illumio-mcp.use   # default; override if needed
illumio-mcp-http --host 127.0.0.1 --port 8080

El servidor se niega a iniciar sin estas variables de entorno (a menos que MCP_DEV_INSECURE=1).

Los clientes MCP descubren el AS mediante el endpoint estándar RFC 9728:

GET /.well-known/oauth-protected-resource

Las solicitudes no autenticadas a /mcp devuelven 401 con WWW-Authenticate: Bearer resource_metadata="<URL>", que cualquier cliente MCP compatible con la especificación (Claude Desktop, ChatGPT, MCP Inspector) sigue automáticamente para ejecutar el flujo de código PKCE contra el AS configurado.

Ejecución sin autenticación (solo desarrollo)

MCP_DEV_INSECURE=1 illumio-mcp-http

El servidor registra una advertencia prominente. NO lo uses en producción.

Endpoints de salud (siempre sin autenticación)

• GET /healthz — vivacidad
• GET /readyz — preparación (la Fase 3a devuelve lo mismo que healthz; las Fases 3b/c agregarán alcance de PCE + JWKS)

Dos modos de PCE (Fase 3b vs Fase 3e)

El servidor HTTP admite dos formas de obtener credenciales del PCE, seleccionadas mediante MCP_PCE_MODE:

Modo	MCP_PCE_MODE	Credenciales PCE	Incorporación	Auditoría del lado del PCE
Por usuario (predeterminado)	per_user	Una clave de API PCE por usuario autenticado, cifrada en el almacén de claves	El usuario se registra mediante la página /setup o la herramienta register-pce-credentials	Los registros del PCE muestran a la persona real mediante la clave de API por usuario
Compartido	shared	Una clave de cuenta de servicio PCE desde el entorno (igual que stdio)	Ninguna — funciona de inmediato para cualquier usuario autenticado	Los registros del PCE muestran la cuenta de servicio; el registro de auditoría de MCP es la fuente de verdad para "quién hizo qué"

Elige por usuario cuando:

• Quieras atribución de auditoría del lado del PCE para identificar a la persona
• Los usuarios estén dispuestos a proporcionar su propia clave de API PCE una vez
• Puedas tolerar la proliferación de claves PCE por usuario (el PCE tiene límites)

Elige compartido cuando:

• El PCE limite las claves de API por usuario demasiado agresivamente para el modo por usuario
• Quieras incorporación sin fricción (sin paso de /setup)
• Estés de acuerdo con depender solo del registro de auditoría de MCP para la atribución a nivel humano
• Operes tú mismo la cuenta de servicio del PCE y la rote según un cronograma

En modo compartido, /setup no está montado, las herramientas de gestión de credenciales (register-pce-credentials, delete-pce-credentials) se niegan con un error amigable, y MCP_KEK no es obligatorio. SSO + JWT + autorización basada en roles + registro de auditoría

• tokens de confirmación siguen aplicándose de manera idéntica.

# Shared mode — same env that stdio uses today, plus auth/role config
export MCP_PCE_MODE=shared
export PCE_HOST=https://your-pce.example.com
export PCE_PORT=8443
export PCE_ORG_ID=1
export API_KEY=your_pce_api_key_name
export API_SECRET=your_pce_api_key_secret
# (other auth/role env vars from earlier sections still apply)
illumio-mcp-http

Claves PCE por usuario (Fase 3b)

Cada usuario autenticado tiene su propia clave/secreto de API PCE almacenado en un almacén de claves SQLite cifrado. Los registros de auditoría del lado del PCE atribuyen correctamente por persona; revocar a un usuario es una sola llamada de herramienta.

Entorno adicional requerido al ejecutar con autenticación:

export MCP_KEK=$(python -c 'import os, base64; print(base64.b64encode(os.urandom(32)).decode())')
export MCP_KEYSTORE_PATH=/var/lib/illumio-mcp/keys.db   # default: ./data/keys.db

El KEK nunca se almacena junto a la base de datos. Pérdida del KEK = pérdida total de las credenciales almacenadas (intencional, cierre por fallo). Para producción, obtén MCP_KEK de KMS o Vault en lugar del shell del operador.

Rutas de incorporación (cualquiera funciona):

1. Navegador — visita /setup después de autenticarte; pega las credenciales en el formulario.
2. Cliente MCP — llama a la herramienta register-pce-credentials; la única herramienta disponible antes de que se registren las credenciales.

Otras herramientas de credenciales:

• check-pce-credentials-status — ¿tiene este usuario credenciales registradas?
• delete-pce-credentials — elimina las credenciales de este usuario.

Autorización basada en roles (Fase 3c)

El servidor asigna los grupos de IdP de cada usuario a uno de tres roles internos: lector, operador, admin. La autorización por herramienta se aplica mediante el despachador usando los metadatos roles en cada ToolSpec.

Configura la asignación grupo → rol mediante entorno (separado por comas):

# A user matching ANY of these groups gets that role; highest role wins.
export MCP_ROLE_GROUPS_ADMIN=sg-illumio-mcp-admin
export MCP_ROLE_GROUPS_OPERATOR=sg-illumio-mcp-operator,sg-illumio-mcp-admin
export MCP_ROLE_GROUPS_READER=sg-illumio-mcp-readonly,sg-illumio-mcp-operator,sg-illumio-mcp-admin

# Optional: fallback role when no group matches. Leave unset to refuse.
# export MCP_ROLE_DEFAULT=reader

Valores predeterminados herramienta por herramienta:

Categoría de herramienta	Roles permitidos	Ejemplos
Lecturas	lector, operador, admin	get-labels, get-workloads, get-traffic-flows
Escrituras	operador, admin	create-*, update-*, delete-*
Aprovisionamiento + masivo	admin	provision-policy, ringfence-batch

Un usuario sin un rol coincidente (y sin MCP_ROLE_DEFAULT) recibe un error estructurado forbidden_no_role.

Registro de auditoría (Fase 3c)

Cada decisión del despachador (permitir / denegar / error) se escribe en una base de datos de auditoría SQLite. Esquema y ubicación de almacenamiento:

# Defaults to <keystore_dir>/audit.db
export MCP_AUDIT_LOG_PATH=/var/lib/illumio-mcp/audit.db

Las filas de auditoría incluyen (ts, sub, iss, tool, decision, reason, role, request_id) — nunca argumentos de herramientas. El request_id coincide con el encabezado de respuesta X-Request-Id para que los rastreos externos puedan correlacionarse.

Ejemplos de consulta:

-- Recent denied calls per user
SELECT ts, sub, tool, reason FROM audit_log
WHERE decision='denied'
ORDER BY ts DESC LIMIT 20;

-- Tool-call volume by user
SELECT sub, COUNT(*) FROM audit_log
WHERE ts > date('now', '-7 days')
GROUP BY sub ORDER BY 2 DESC;

Tokens de confirmación para herramientas de mutación (Fase 3d)

Las herramientas marcadas con requires_confirm=True (actualmente provision-policy, ringfence-batch, register-pce-credentials, delete-pce-credentials) requieren un token de confirmación de un solo uso emitido por el servidor en params._meta.confirm_token cuando se llaman por HTTP. El modo stdio no se ve afectado: el operador que inició el proceso puede llamar a las herramientas de mutación directamente.

Entorno requerido en modo de autenticación:

export MCP_CONFIRM_HMAC_KEY=$(python -c 'import os, base64; print(base64.b64encode(os.urandom(32)).decode())')
# Optional:
# export MCP_CONFIRM_TTL_SECONDS=120
# export MCP_CONFIRM_JTI_PATH=/var/lib/illumio-mcp/jti.db
# export MCP_CONFIRM_FRESH_AUTH_SECONDS=300   # require JWT auth_time within 5 min

Cómo lo usa un cliente

1. Llama a la herramienta de mutación sin token → el servidor devuelve:

   {"error": "confirm_required", "params_hash": "<sha256>", "message": "..."}
   

2. Llama a POST /confirm con el JWT y el params_hash:

   curl -X POST https://mcp.illumio.example/confirm \
     -H "Authorization: Bearer $JWT" \
     -H "Content-Type: application/json" \
     -d '{"tool":"provision-policy","params_hash":"<sha256>"}'
   # → {"confirm_token": "...", "expires_in": 120}
   

3. Vuelve a llamar a la herramienta con el token en params._meta.confirm_token.

Los tokens son de un solo uso (las reproducciones devuelven confirm_token_replay) y limitados a (sub, tool, params_hash). Alterar cualquier campo invalida el token.

Autenticación escalonada (opcional, recomendada para producción)

Establece MCP_CONFIRM_FRESH_AUTH_SECONDS=300 para requerir que la reclamación auth_time del JWT esté dentro de los últimos 5 minutos. Fuerza al usuario a reautenticarse antes de emitir un token: la defensa más fuerte contra inyección de indicaciones disponible sin un modelo de sesión interactiva. Requiere que el IdP emita auth_time (tanto Entra como Okta lo hacen para flujos de inicio de sesión OIDC).

Herramientas

Gestión de cargas de trabajo

• get-workloads — Recupera cargas de trabajo con filtrado opcional por nombre, hostname, IP, etiquetas y resultados máximos
• create-workload — Crea una carga de trabajo no gestionada con nombre, direcciones IP y etiquetas
• update-workload — Actualiza las propiedades de una carga de trabajo existente
• delete-workload — Elimina una carga de trabajo del PCE

Operaciones de etiquetas

• get-labels — Recupera etiquetas con filtrado opcional por clave, valor y resultados máximos
• create-label — Crea una nueva etiqueta con par clave-valor
• update-label — Actualiza una etiqueta existente
• delete-label — Elimina una etiqueta

Gestión de conjuntos de reglas y reglas

• get-rulesets — Obtiene conjuntos de reglas con filtrado opcional por nombre, descripción y estado habilitado
• create-ruleset — Crea un nuevo conjunto de reglas con alcances
• update-ruleset — Actualiza propiedades del conjunto de reglas
• delete-ruleset — Elimina un conjunto de reglas
• create-deny-rule — Crea una regla de denegación (denegación regular o por anulación) en un conjunto de reglas
• update-deny-rule — Actualiza una regla de denegación existente
• delete-deny-rule — Elimina una regla de denegación

Gestión de listas de IP

• get-iplists — Obtiene listas de IP con filtrado opcional por nombre, descripción, FQDN y resultados máximos
• create-iplist — Crea una nueva lista de IP
• update-iplist — Actualiza una lista de IP existente
• delete-iplist — Elimina una lista de IP

Gestión de servicios

• get-services — Obtiene servicios con filtrado opcional por nombre, puerto, protocolo y resultados máximos
• create-service — Crea una nueva definición de servicio
• update-service — Actualiza un servicio existente
• delete-service — Elimina un servicio

Análisis de tráfico

• get-traffic-flows — Obtiene datos detallados de flujo de tráfico con filtrado por rango de fechas, origen/destino, servicio, decisión de política y más
• get-traffic-flows-summary — Obtiene resúmenes de tráfico agregados agrupados por aplicación, entorno, puerto y protocolo

Aislamiento Automatizado

• create-ringfence — Creación automatizada de políticas de segmentación app-a-app. Analiza los flujos de tráfico para descubrir qué aplicaciones remotas se comunican con una aplicación objetivo, y luego crea un conjunto de reglas con:
  • Regla de permitir dentro del alcance — todas las cargas de trabajo dentro de la aplicación pueden comunicarse libremente
  • Reglas de permitir fuera del alcance — cada aplicación remota descubierta recibe una regla de permitir en Todos los Servicios
  • Modo de aplicación selectivo (selective=true) — añade una regla de denegar que bloquea todo el tráfico entrante, con reglas de permitir para aplicaciones conocidas procesadas primero. Te lleva a la aplicación más rápido que el modo de aplicación completo.
  • Variantes de denegar consumidor (parámetro deny_consumer):
    • any (predeterminado) — Lista IP Cualquiera (0.0.0.0/0) como consumidor, denegar solo en el destino. Más seguro.
    • ams — Todas las Cargas de Trabajo como consumidor, denegar enviado a cada carga de trabajo gestionada. Más amplio.
    • ams_and_any — Ambos. Cobertura máxima.
  • Conciencia de cobertura de políticas — cada regla se anota como already_allowed (tráfico cubierto por política existente, creado para documentación) o newly_allowed (llenando una brecha de política). El resumen muestra cuántas aplicaciones remotas ya están cubiertas frente a las que necesitan nuevas reglas.
  • Parámetro skip_allowed — configúralo en true para crear solo reglas para tráfico aún no cubierto por política existente, produciendo conjuntos de reglas mínimos que llenan solo brechas
  • Seguro para fusionar — detecta conjuntos de reglas y reglas existentes, nunca crea duplicados
  • Soporte de simulación — previsualiza lo que se crearía sin hacer cambios

Identificación de Servicios de Infraestructura

• identify-infrastructure-services — Descubre qué aplicaciones son servicios de infraestructura analizando patrones de tráfico. Construye un grafo de comunicación app-a-app y utiliza puntuación de doble patrón para reconocer dos tipos de infraestructura:

  Infraestructura proveedora (AD, DNS, BD compartida) — consumida por muchas aplicaciones, alto grado de entrada, bajo grado de salida. Infraestructura consumidora (monitoreo, respaldo, envío de registros) — se conecta a muchas aplicaciones, alto grado de salida, bajo grado de entrada.

  Se calculan dos puntuaciones por aplicación, y gana la más alta:

  Puntuación	Métrica de grado (40%)	Direccionalidad (30%)	Intermediación (25%)	Volumen (5%)
  Proveedor	Grado de entrada	Ratio de consumidor (entrada/total)	Centralidad de intermediación	Volumen de conexiones
  Consumidor	Grado de salida	Ratio de productor (salida/total)	Centralidad de intermediación	Volumen de conexiones

  Atenuación de tráfico mixto: score *= 1 / (1 + min(in_degree, out_degree) * 0.3) — las aplicaciones con conexiones entrantes Y salientes significativas son aplicaciones de negocio, no infraestructura. Las aplicaciones puramente direccionales (todo entrada O todo salida) no reciben penalización.

  Los entornos no productivos (staging, dev, etc.) reciben una penalización de puntuación del 50% ya que los servicios de infraestructura típicamente viven en producción.

  Las aplicaciones se clasifican en niveles:

  • Infraestructura Principal (puntuación >= 75) — monitoreo, AD, SIEM, DNS. Política estos primero.
  • Servicio Compartido (puntuación >= 50) — bases de datos compartidas, colas de mensajes. Política estos segundo.
  • Aplicación Estándar (puntuación < 50) — aplicaciones de negocio normales.

  Cada resultado incluye un campo dominant_pattern ("proveedor" o "consumidor") que indica qué tipo de infraestructura se asemeja la aplicación.

  Por qué esto importa: Los servicios de infraestructura son consumidos por muchas aplicaciones O se conectan a muchas aplicaciones. Si aíslas aplicaciones sin permitir primero los servicios de infraestructura, rompes dependencias. Esta herramienta te dice qué política aplicar primero.

Ciclo de Vida de Políticas

• provision-policy — Aprovisiona cambios de borrador pendientes para moverlos de estado de borrador a activo. Puede aprovisionar todos los cambios pendientes o elementos específicos por href. Incluye descripciones de cambios para auditoría.
• compare-draft-active — Compara política de borrador vs activa para previsualizar qué cambiaría al aprovisionar. Muestra conjuntos de reglas, reglas, listas IP y servicios creados, actualizados y eliminados.

Preparación para Aplicación

• enforcement-readiness — Evalúa si una aplicación está lista para aplicación. Analiza flujos de tráfico, cobertura de política existente, modos de aplicación y estado de aislamiento. Devuelve una puntuación de preparación (0-100) con recomendaciones accionables:
  • Cobertura de política (40 puntos) — qué porcentaje de tráfico está cubierto por reglas
  • Existe aislamiento (20 puntos) — ¿se ha creado un conjunto de reglas de aislamiento?
  • Modo de aplicación (20 puntos) — ¿están las cargas de trabajo en completo/selectivo/solo_visibilidad?
  • Sin tráfico bloqueado (10 puntos) — sin bloqueos no intencionados
  • Todas las aplicaciones remotas cubiertas (10 puntos) — sin tráfico de aplicaciones remotas descubierto

Operaciones por Lote

• ringfence-batch — Aísla múltiples aplicaciones a la vez. Opcionalmente usa identify-infrastructure-services para ordenar automáticamente las aplicaciones por puntuación de infraestructura (infraestructura primero, luego aplicaciones estándar). Soporta modo de simulación para previsualizar todos los cambios antes de aplicar.

Estado de Aplicación de Cargas de Trabajo

• get-workload-enforcement-status — Obtén el estado del modo de aplicación en las cargas de trabajo, agrupado por aplicación y entorno. Muestra conteos por modo (inactivo, solo_visibilidad, selectivo, completo) e identifica aplicaciones con estados de aplicación mixtos — un problema común durante despliegues.

Cobertura de Políticas

• get-policy-coverage-report — Genera un informe de cobertura de políticas para una aplicación mostrando qué tráfico está cubierto por reglas existentes frente a lo que se bloquearía. Desglosa por entrante/saliente, identifica servicios y aplicaciones remotas descubiertos, y proporciona un porcentaje de cobertura general.
• find-unmanaged-traffic — Encuentra tráfico que involucra cargas de trabajo no gestionadas o direcciones IP. Estos son orígenes/destinos sin etiquetas de app/env, representando puntos ciegos de política. Filtra por dirección (entrante/saliente/ambos) y conteo de conexiones.

Análisis de Seguridad

• detect-lateral-movement-paths — Detecta posibles rutas de movimiento lateral analizando patrones de tráfico app-a-app. Identifica puntos de articulación (nodos puente) cuya compromisión proporcionaría acceso a grupos de aplicaciones de otro modo desconectados. Calcula la alcanzabilidad desde cualquier aplicación inicial y traza rutas de múltiples saltos hasta una profundidad configurable.
• compliance-check — Verifica el cumplimiento de políticas contra marcos (PCI-DSS, NIST 800-53, Controles CIS, o mejores prácticas generales). Evalúa segmentación, modos de aplicación, exposición de puertos de alto riesgo y cobertura de políticas. Devuelve una puntuación de cumplimiento con hallazgos por verificación (APROBADO/FALLIDO/ADVERTENCIA).

Monitoreo de Eventos

• get-events — Obtén eventos de PCE con filtrado opcional por tipo de evento, severidad, estado y límites de resultados

Prueba de Conexión

• check-pce-connection — Verifica la conectividad y credenciales de PCE

Pruebas

El proyecto incluye una suite integral de pruebas de integración que se ejecuta contra un PCE real usando el protocolo MCP.

# Set up credentials in .env
cat > .env << EOF
PCE_HOST=your-pce-host
PCE_PORT=8443
PCE_ORG_ID=1
API_KEY=your-api-key
API_SECRET=your-api-secret
EOF

# Run all tests
uv run pytest tests/ -v

La suite de pruebas cubre:

• Listado de herramientas y validación de esquemas
• Ciclo de vida completo de CRUD para cargas de trabajo, etiquetas, listas IP, servicios, conjuntos de reglas y reglas de denegar
• Consultas y resúmenes de flujos de tráfico
• Creación de aislamiento (estándar, selectivo, variantes de denegar consumidor, idempotencia de fusión)
• Identificación de servicios de infraestructura (puntuación, ordenamiento, clasificación de niveles)
• Manejo de errores para recursos faltantes

Orden de Procesamiento de Reglas de Illumio

Entender el procesamiento de reglas es esencial para el aislamiento:

1. Reglas esenciales — integradas, no se pueden modificar
2. Reglas de denegar anulación — bloquean tráfico anulando todos los permitir (uso de emergencia)
3. Reglas de permitir — permiten tráfico (las reglas de aplicaciones remotas de aislamiento van aquí)
4. Reglas de denegar — bloquean tráfico específico (la regla de denegar todo entrante de aislamiento va aquí)
5. Acción predeterminada — modo selectivo = permitir todo, aplicación completa = denegar todo

En aplicación selectiva, el predeterminado es permitir todo, por lo que se necesita una regla de denegar para que el aislamiento sea efectivo. Las aplicaciones remotas conocidas reciben reglas de permitir (paso 3) que se procesan antes del denegar (paso 4).

Ejemplos Visuales

Todos los ejemplos a continuación fueron generados por Claude Desktop y con datos obtenidos a través de este servidor MCP.

Análisis de Aplicaciones

Vista detallada de patrones de comunicación y dependencias de aplicaciones

Análisis de patrones de tráfico entre diferentes niveles de aplicaciones

Perspectivas de Infraestructura

Panel de descripción general que muestra métricas y estado clave de infraestructura

Análisis detallado de comunicaciones de servicios de infraestructura

Evaluación de Seguridad

Informe integral de análisis de seguridad

Hallazgos de evaluación de seguridad para vulnerabilidades de alto riesgo

Hallazgos de evaluación de cumplimiento PCI

Hallazgos de evaluación de cumplimiento SWIFT

Planificación de Remediación

Descripción general de la planificación de remediación de seguridad

Pasos detallados para la implementación de remediación de seguridad

Gestión de Políticas

Interfaz de gestión para listas IP

Descripción general de categorías y organización de conjuntos de reglas

Configuración del ordenamiento de conjuntos de reglas de aplicaciones

Gestión de Cargas de Trabajo

Análisis detallado y métricas de cargas de trabajo

Identificación y análisis de patrones de tráfico de cargas de trabajo

Gestión de Etiquetas

Organización de etiquetas de PCE por tipo y categoría

Análisis de Servicios

Inferencia automática de roles de servicios basada en patrones de tráfico

Análisis de los 5 principales orígenes y destinos de tráfico

Planificación de Proyectos

Cronograma de implementación del proyecto e hitos

Prompts Disponibles

Aislar Aplicación

El prompt ringfence-application ayuda a crear políticas de seguridad para aislar y proteger aplicaciones controlando el tráfico entrante y saliente.

Argumentos Requeridos:

• application_name: Nombre de la aplicación a aislar
• application_environment: Entorno de la aplicación a aislar

Características:

• Crea reglas para comunicación entre niveles dentro de la aplicación
• Usa flujos de tráfico para identificar conexiones externas requeridas
• Implementa restricciones de tráfico entrante basadas en aplicaciones de origen
• Crea reglas de tráfico saliente para comunicaciones externas necesarias
• Maneja conexiones dentro del alcance (misma app/env) y fuera del alcance (externas)
• Crea conjuntos de reglas separados para conexiones de aplicaciones remotas

Analizar Tráfico de Aplicaciones

El prompt analyze-application-traffic proporciona análisis detallado de patrones de tráfico y conectividad de aplicaciones.

Argumentos Requeridos:

• application_name: Nombre de la aplicación a analizar
• application_environment: Entorno de la aplicación a analizar

Características de Análisis:

• Ordena el tráfico por flujos entrantes y salientes
• Agrupa por combinaciones de aplicación/entorno/rol
• Identifica tipos y patrones de etiquetas relevantes
• Muestra resultados en formato de componente React
• Muestra información de protocolo y puerto
• Intenta identificar patrones de servicios conocidos (por ejemplo, Nagios en el puerto 5666)
• Categoriza el tráfico en tipos de infraestructura y aplicación
• Determina la exposición a internet
• Muestra etiquetas de rol, aplicación y entorno de Illumio

Cómo usar los prompts de MCP

Paso 1: Haz clic en el botón "Adjuntar desde MCP" en la interfaz

Paso 2: Elige entre los servidores MCP instalados

Paso 3: Completa los argumentos de prompt requeridos:

Paso 4: Haz clic en Enviar para enviar el prompt configurado

Cómo funcionan los prompts

• El servidor MCP envía el prompt configurado a Claude
• Claude recibe contexto a través del Protocolo de Contexto de Modelo
• Permite manejo especializado de tareas específicas de Illumio

Este flujo de trabajo permite compartir contexto automatizado entre sistemas de Illumio y Claude para análisis de tráfico de aplicaciones y tareas de aislamiento.

Docker

La aplicación está disponible como contenedor Docker desde el Registro de Contenedores de GitHub.

Extraer el contenedor

docker pull ghcr.io/alexgoller/illumio-mcp-server:latest

También puedes usar una versión específica reemplazando latest con un número de versión:

docker pull ghcr.io/alexgoller/illumio-mcp-server:1.0.0

Ejecutar con Claude Desktop

Para usar el contenedor con Claude Desktop, necesitarás:

1. Crear un archivo de entorno (por ejemplo, ~/.illumio-mcp.env) con tus credenciales de PCE:

PCE_HOST=your-pce-host
PCE_PORT=your-pce-port
PCE_ORG_ID=1
API_KEY=your-api-key
API_SECRET=your-api-secret

2. Añadir la siguiente configuración a tu archivo de configuración de Claude Desktop: En MacOS (~/Library/Application Support/Claude/claude_desktop_config.json):

{
    "mcpServers": {
        "illumio-mcp-docker": {
            "command": "docker",
            "args": [
                "run",
                "-i",
                "--init",
                "--rm",
                "-v",
                "/Users/YOUR_USERNAME/tmp:/var/log/illumio-mcp",
                "-e",
                "DOCKER_CONTAINER=true",
                "-e",
                "PYTHONWARNINGS=ignore",
                "--env-file",
                "/Users/YOUR_USERNAME/.illumio-mcp.env",
                "illumio-mcp:latest"
            ]
        }
    }
}

Asegúrate de:

• Reemplazar YOUR_USERNAME con tu nombre de usuario real
• Crear el directorio de registros (por ejemplo, ~/tmp)
• Ajustar las rutas según tu sistema

Ejecutar de forma independiente

También puedes ejecutar el contenedor directamente:

docker run -i --init --rm \
  -v /path/to/logs:/var/log/illumio-mcp \
  -e DOCKER_CONTAINER=true \
  -e PYTHONWARNINGS=ignore \
  --env-file ~/.illumio-mcp.env \
  ghcr.io/alexgoller/illumio-mcp-server:latest

Docker Compose

Para desarrollo o pruebas, puedes usar Docker Compose:

version: '3'
services:
  illumio-mcp:
    image: ghcr.io/alexgoller/illumio-mcp-server:latest
    init: true
    volumes:
      - ./logs:/var/log/illumio-mcp
    environment:
      - DOCKER_CONTAINER=true
      - PYTHONWARNINGS=ignore
    env_file:
      - ~/.illumio-mcp.env

Luego ejecuta:

docker-compose up

Contribuciones

1. Haz un fork del repositorio
2. Crea una rama de características
3. Confirma tus cambios
4. Haz push a la rama
5. Crea una Pull Request

Licencia

Este proyecto está licenciado bajo la Licencia GPL-3.0. Consulta el archivo LICENSE para más detalles.

Soporte

Para soporte, por favor crea un issue.