Illumio MCP Server

Interactúa con el Illumio Policy Compute Engine (PCE) para gestionar cargas de trabajo, etiquetas y analizar flujos de tráfico.

GitHub
12

Documentación

MseeP.ai Security Assessment Badge

Servidor MCP de Illumio

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 tráfico, ringfencing automatizado e identificación de servicios de infraestructura.

Illumio Server MCP server

¿Qué puede hacer?

Usa IA conversacional para hablar con tu PCE:

  • CRUD completo sobre cargas de trabajo, etiquetas, listas de IP, servicios y conjuntos de reglas
  • Análisis de tráfico — consulta flujos, obtén resúmenes, filtra por decisión de política
  • Ringfencing automatizado — analiza el tráfico y crea políticas de segmentación app-a-app con un solo comando
  • Aplicación selectiva — añade reglas de denegación para apps en modo selectivo con sabores de consumidor configurables
  • Identificación de servicios de infraestructura — descubre qué apps son servicios de infraestructura mediante análisis de centralidad de grafo, para saber qué priorizar en las políticas
  • Gestión de reglas de denegación — crea, actualiza y elimina reglas de denegación (incluida la denegación por anulación para emergencias)
  • Monitoreo de eventos — consulta eventos del PCE con filtros de severidad y tipo
  • Comprobaciones de salud del PCE — verifica conectividad y credenciales

Requisitos previos

  • Python 3.8+
  • 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
  1. 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.

Uso con uv y Claude Desktop

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

Añade 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 la Fase 3a: la identidad está aplicada; 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 conforme a la especificación (Claude Desktop, ChatGPT, MCP Inspector) sigue automáticamente para ejecutar el flujo de código de autorización 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 — liveness
  • GET /readyz — readiness (la Fase 3a devuelve lo mismo que healthz; las Fases 3b/c añadirá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:

ModoMCP_PCE_MODECredenciales PCEIncorporaciónAuditoría en el lado del PCE
Por usuario (predeterminado)per_userUna clave de API del PCE por usuario autenticado, cifrada en el almacén de clavesEl usuario se registra mediante la página /setup o la herramienta register-pce-credentialsLos registros del PCE muestran a la persona real mediante la clave de API por usuario
CompartidosharedUna clave de cuenta de servicio del PCE desde el entorno (igual que stdio)Ninguna — funciona de inmediato para cualquier usuario autenticadoLos 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 en el lado del PCE que identifique a la persona
  • Los usuarios estén dispuestos a proporcionar su propia clave de API del 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 de forma demasiado agresiva para el modo por usuario
  • Quieras una incorporación sin fricción (sin paso de /setup)
  • Te baste con depender únicamente 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 calendario

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 forma 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 del PCE almacenados 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, fail-closed). 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 IdP de cada usuario a uno de tres roles internos: lector, operador, admin. La autorización por herramienta la aplica el despachador usando los metadatos roles en cada ToolSpec.

Configura la asignación grupo → rol mediante variables de entorno (separadas 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 herramientaRoles permitidosEjemplos
Lecturaslector, operador, adminget-labels, get-workloads, get-traffic-flows
Escriturasoperador, admincreate-*, update-*, delete-*
Aprovisionamiento + masivoadminprovision-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 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 repeticiones devuelven confirm_token_replay) y están 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 exigir que la reclamación auth_time del JWT esté dentro de los últimos 5 minutos. Obliga al usuario a reautenticarse antes de emitir un token: la defensa más sólida contra la inyección de prompts disponible sin un modelo de sesión interactivo. Requiere que el IdP emita auth_time (Entra y Okta ambos 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 ámbitos
  • update-ruleset — Actualiza las propiedades del conjunto de reglas
  • delete-ruleset — Elimina un conjunto de reglas
  • create-deny-rule — Crea una regla de denegación (denegación normal 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 flujos 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 app, entorno, puerto y protocolo

Ringfencing automatizado

  • create-ringfence — Creación automatizada de políticas de segmentación app-a-app. Analiza los flujos de tráfico para descubrir qué apps remotas se comunican con una app objetivo y luego crea un conjunto de reglas con:
    • Regla de permiso intra-ámbito — todas las cargas de trabajo dentro de la app pueden comunicarse libremente
    • Reglas de permiso extra-ámbito — cada app remota descubierta recibe una regla de permiso en All Services
    • Modo de aplicación selectiva (selective=true) — añade una regla de denegación que bloquea todo el tráfico entrante, con reglas de permiso para apps conocidas procesadas primero. Te lleva a la aplicación más rápido que el modo de aplicación completa.
    • Sabores de consumidor de denegación (parámetro deny_consumer):
      • any (predeterminado) — lista de IP Any (0.0.0.0/0) como consumidor, denegación solo en el destino. El más seguro.
      • ams — All Workloads como consumidor, denegación aplicada a cada carga de trabajo gestionada. Más amplio.
      • ams_and_any — Ambos. Cobertura máxima.
    • Conciencia de cobertura de política — cada regla se anota como already_allowed (tráfico cubierto por política existente, creada para documentación) o newly_allowed (rellenando una brecha de política). El resumen muestra cuántas apps remotas ya están cubiertas frente a cuántas necesitan reglas nuevas.
    • Parámetro skip_allowed — establecido en true para crear solo reglas para tráfico aún no cubierto por política existente, produciendo conjuntos de reglas mínimos que solo rellenan brechas
    • Seguro contra fusiones — detecta conjuntos de reglas y reglas existentes, nunca crea duplicados
    • Soporte de ejecución en seco — previsualiza lo que se crearía sin hacer cambios

Identificación de servicios de infraestructura

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

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

    Se calculan dos puntuaciones por app, y gana la más alta:

    PuntuaciónMétrica de grado (40%)Direccionalidad (30%)Intermediación (25%)Volumen (5%)
    ProveedorGrado de entradaRatio de consumo (entrada/total)Centralidad de intermediaciónVolumen de conexiones
    ConsumidorGrado de salidaRatio de producción (salida/total)Centralidad de intermediaciónVolumen de conexiones

    Atenuación de tráfico mixto: score *= 1 / (1 + min(in_degree, out_degree) * 0.3) — las apps con conexiones entrantes Y salientes significativas son apps de negocio, no infraestructura. Las apps puramente direccionales (todo entrada O todo salida) no reciben penalización. Los entornos que no son de producción (staging, dev, etc.) reciben una penalización del 50% en la puntuación, ya que los servicios de infraestructura normalmente viven en producción.

Las aplicaciones se clasifican en niveles:

  • Infraestructura principal (puntuación >= 75) — monitoreo, AD, SIEM, DNS. Aplique políticas a estas primero.
  • Servicio compartido (puntuación >= 50) — bases de datos compartidas, colas de mensajes. Aplique políticas a estas en segundo lugar.
  • Aplicación estándar (puntuación < 50) — aplicaciones empresariales 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 es importante: Los servicios de infraestructura son consumidos por muchas aplicaciones O se conectan a muchas aplicaciones. Si aísla aplicaciones sin permitir primero los servicios de infraestructura, rompe dependencias. Esta herramienta le indica qué políticas aplicar primero.

Ciclo de vida de políticas

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

Preparación para la aplicación de políticas

  • enforcement-readiness — Evaluar si una aplicación está lista para la aplicación de políticas. Analiza flujos de tráfico, cobertura de políticas existente, modos de aplicación de políticas y estado de aislamiento. Devuelve una puntuación de preparación (0-100) con recomendaciones accionables:
    • Cobertura de políticas (40 puntos) — qué porcentaje del tráfico está cubierto por reglas
    • Existe aislamiento (20 puntos) — si se ha creado un conjunto de reglas de aislamiento
    • Modo de aplicación de políticas (20 puntos) — si las cargas de trabajo están 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 sin cubrir

Operaciones por lotes

  • ringfence-batch — Aislar 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). Admite modo de ejecución en seco para previsualizar todos los cambios antes de aplicarlos.

Estado de aplicación de políticas en cargas de trabajo

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

Cobertura de políticas

  • get-policy-coverage-report — Generar un informe de cobertura de políticas para una aplicación que muestre qué tráfico está cubierto por reglas existentes vs qué sería bloqueado. Desglosa por entrante/saliente, identifica servicios y aplicaciones remotas sin cubrir, y proporciona un porcentaje de cobertura general.
  • find-unmanaged-traffic — Encontrar tráfico que involucra cargas de trabajo no gestionadas o direcciones IP. Estos son orígenes/destinos sin etiquetas de aplicación/entorno, que representan puntos ciegos de políticas. Filtra por dirección (entrante/saliente/ambos) y conteo de conexiones.

Análisis de seguridad

  • detect-lateral-movement-paths — Detectar posibles rutas de movimiento lateral analizando patrones de tráfico entre aplicaciones. Identifica puntos de articulación (nodos puente) cuyo compromiso 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 — Verificar cumplimiento de políticas contra marcos (PCI-DSS, NIST 800-53, CIS Controls, o mejores prácticas generales). Evalúa segmentación, modos de aplicación de políticas, exposición de puertos de alto riesgo y cobertura de políticas. Devuelve una puntuación de cumplimiento con hallazgos por verificación (PASS/FAIL/WARNING).

Monitoreo de eventos

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

Pruebas de conexión

  • check-pce-connection — Verificar 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 de IP, servicios, conjuntos de reglas y reglas de denegación
  • Consultas y resúmenes de flujos de tráfico
  • Creación de aislamiento (estándar, selectivo, variantes de denegación de 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 denegación por anulación — bloquean tráfico anulando todas las permitidas (uso de emergencia)
  3. Reglas de permitir — permiten tráfico (las reglas de aplicaciones remotas de aislamiento van aquí)
  4. Reglas de denegación — bloquean tráfico específico (la denegación de todo el tráfico entrante del aislamiento va aquí)
  5. Acción predeterminada — modo selectivo = permitir todo, aplicación completa = denegar todo

En la aplicación selectiva, el valor predeterminado es permitir todo, por lo que se necesita una regla de denegación para que el aislamiento sea efectivo. Las aplicaciones remotas conocidas reciben reglas de permitir (paso 3) que se procesan antes de la denegación (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

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

Application Tier Analysis Análisis de patrones de tráfico entre diferentes niveles de aplicaciones

Información de infraestructura

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

Infrastructure Services Análisis detallado de comunicaciones de servicios de infraestructura

Evaluación de seguridad

Security Analysis Report Informe integral de análisis de seguridad

High Risk Findings Hallazgos de evaluación de seguridad para vulnerabilidades de alto riesgo

PCI Compliance Hallazgos de evaluación de cumplimiento de PCI

SWIFT Compliance Hallazgos de evaluación de cumplimiento de SWIFT

Planificación de remediación

Remediation Plan Overview Descripción general de la planificación de remediación de seguridad

Detailed Remediation Steps Pasos detallados para la implementación de la remediación de seguridad

Gestión de políticas

IP Lists Overview Interfaz de gestión para listas de IP

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

Application Ruleset Ordering Configuración del orden de conjuntos de reglas de aplicaciones

Gestión de cargas de trabajo

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

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

Gestión de etiquetas

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

Análisis de servicios

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

Top Sources and Destinations Análisis de las 5 principales fuentes y destinos de tráfico

Planificación de proyectos

Project Plan 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 tanto dentro del alcance (misma app/entorno) como 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 de etiquetas y patrones 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 prompts de MCP

Paso 1: Haga clic en el botón "Attach from MCP" en la interfaz

MCP Prompt Workflow

Paso 2: Elija entre los servidores MCP instalados

MCP Prompt Workflow

Paso 3: Complete los argumentos requeridos del prompt:

MCP Prompt Workflow

Paso 4: Haga 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 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 puede 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á:

  1. Crear un archivo de entorno (por ejemplo, ~/.illumio-mcp.env) con sus 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
  1. Agregar la siguiente configuración a su 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úrese de:

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

Ejecutar de forma independiente

También puede 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, puede 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 ejecute:

docker-compose up

Contribuciones

  1. Haga un fork del repositorio
  2. Cree una rama de características
  3. Confirme sus cambios
  4. Envíe a la rama
  5. Cree una Solicitud de Extracción

Licencia

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

Soporte

Para soporte, por favor cree un issue.