Illumio MCP Server

Illumio MCP 服务

📚 文档网站 — 安装、入门指南、工作流、完整工具参考和集中式部署。

一个模型上下文协议（MCP）服务，为与 Illumio PCE（Policy Compute Engine）交互提供接口。此服务支持以编程方式访问 Illumio 工作负载管理、标签操作、流量流分析、自动隔离以及基础设施服务识别功能。

它能做什么？

通过对话式 AI 与 PCE 交互：

• 完整的 CRUD 操作：管理工作负载、标签、IP 列表、服务和规则集
• 分析整个时间窗口内的流量 — 汇总会统计 PCE 返回的所有流，而非仅统计前 500 条，并报告实际流量总量与显示数量
• 按任意标签聚合 — 默认使用 app/env，也可使用业务部门、合规范围、角色+位置；支持 PCE 定义的任意维度
• 影子 AI / 出站流量发现 — 查明哪个进程与哪个提供商通信，并通过 RDAP 和每周在 CI 中刷新的供应商公开 IP 范围进行归因
• 按进程限定策略 — 通过 Windows 出站服务和规则中的服务引用，实现“仅允许此二进制文件访问该应用”
• 自动隔离 — 分析流量并通过一条命令创建应用间分段策略
• 选择性强制执行 — 为选择性模式下的应用添加拒绝规则，并可配置消费者类型
• 基础设施服务识别 — 使用图中心性分析发现哪些应用属于基础设施服务，帮助确定优先制定策略的对象
• 拒绝规则管理 — 创建、更新和删除拒绝规则（包括紧急情况下的覆盖拒绝规则）
• 可直接编辑规则 — 使用 update-sec-rule / delete-sec-rule，无需重建规则集
• 事件监控 — 按严重性和类型筛选并查询 PCE 事件
• PCE 运行状况检查 — 验证连接和凭据
• 告知变更内容 — get-server-changelog 会向工具列表缓存已过期的会话报告行为变更

先决条件

• Python 3.12 或 3.13（请参阅 pyproject.toml 中的 requires-python）
• 可访问 Illumio PCE 实例
• 有效的 PCE API 凭据

安装

1. 克隆仓库：

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

2. 安装依赖项：

uv sync

配置

建议使用 uv 命令运行，这样更便于传入环境变量并在后台运行。

使用 uv 和 Claude Desktop

在 MacOS 上：~/Library/Application\ Support/Claude/claude_desktop_config.json 在 Windows 上：%APPDATA%/Claude/claude_desktop_config.json

将以下内容添加到 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"
      }
    }
  }
}

使用 OAuth 资源服务器的 HTTP 传输（Phase 3a）

服务通过 MCP Streamable HTTP 传输（规范版本 2025-03-26）运行，并验证由你的 IdP 签发的 OAuth 2.1 bearer 令牌。这是 Phase 3a：强制执行身份验证；每位用户的 PCE 密钥将在 Phase 3b 中引入。

启用身份验证运行（面向生产环境）

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

若未设置这些环境变量，服务将拒绝启动（除非设置了 MCP_DEV_INSECURE=1）。

MCP 客户端通过标准 RFC 9728 端点发现 AS：

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

对 /mcp 的未授权请求会返回 401，并附带 WWW-Authenticate: Bearer resource_metadata="<URL>"。任何符合规范的 MCP 客户端（Claude Desktop、ChatGPT、MCP Inspector）都会自动跟进该信息， 针对已配置的 AS 执行 PKCE 授权码流程。

不启用身份验证运行（仅限开发）

MCP_DEV_INSECURE=1 illumio-mcp-http

服务会记录一条醒目的警告。切勿在生产环境中使用。

健康检查端点（始终无需身份验证）

• GET /healthz — 存活状态
• GET /readyz — 就绪状态（Phase 3a 返回与 healthz 相同的结果；Phase 3b/c 将添加 PCE + JWKS 可达性检查）

两种 PCE 模式（Phase 3b 与 Phase 3e）

HTTP 服务支持三种 PCE 凭据来源方式，通过 MCP_PCE_MODE 选择：

模式	MCP_PCE_MODE	PCE 凭据	入驻流程	PCE 侧审计
按用户（默认）	per_user	每位通过身份验证的用户各有一个 PCE API 密钥，使用密钥库加密保存	用户通过 /setup 页面或 register-pce-credentials 工具注册	PCE 日志通过每位用户的 API 密钥显示真实用户
共享	shared	一个来自环境变量的 PCE 服务帐户密钥（与 stdio 相同）	无——任何通过身份验证的用户都可以立即使用	PCE 日志显示服务帐户；MCP 审计日志是“谁做了什么”的事实来源
混合	hybrid	用户注册了个人密钥时使用该密钥；否则使用共享服务帐户	可选——可立即使用；/setup 允许用户选择启用归属追踪	有意采用混合方式：已注册用户显示为个人，其他用户显示为服务帐户。每条 MCP 审计记录都会记录 effective_pce_mode，以便识别所用模式

选择按用户模式的情况：

• 你希望 PCE 侧审计能够识别具体用户
• 用户愿意提供一次自己的 PCE API 密钥
• 你可以接受每位用户各自持有 PCE 密钥带来的管理负担（PCE 有数量限制）

选择共享模式的情况：

• PCE 对每位用户的 API 密钥数量限制过于严格，不适合按用户模式
• 你希望用户能够零门槛入驻（无需 /setup 步骤）
• 你可以接受仅依赖 MCP 审计日志进行用户级归属追踪
• 你自行管理 PCE 服务帐户，并按计划轮换密钥

选择混合模式的情况：

• 你已采用共享模式，并希望分阶段迁移到按用户模式
• 合规要求需要为部分用户提供可识别身份的 PCE 侧归属追踪，但不希望强制所有人完成入驻
• 你接受 PCE 审计日志中存在混合记录，并会查看 MCP 审计日志中的 effective_pce_mode

混合模式要求同时配置共享环境变量（PCE_*、API_*）和 MCP_KEK；缺少任意一项都会导致服务拒绝启动。check-pce-credentials-status 会报告本次请求对当前调用用户适用的模式——包括用户已保存密钥但无法使用、调用最终以服务帐户身份执行的情况。

在共享模式下，不会挂载 /setup，凭据管理工具 （register-pce-credentials、delete-pce-credentials）会返回友好的错误提示，且无需设置 MCP_KEK。SSO + JWT + 基于角色的授权 + 审计日志 + 确认令牌仍然一律适用。

# 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

每用户 PCE 密钥（阶段 3b）

每位经过身份验证的用户都有自己的 PCE API 密钥/密钥机密，存储在加密的 SQLite 密钥库中。PCE 端的审计日志会正确归属到各个人员；撤销用户权限只需调用一次工具。

启用身份验证运行时还需设置以下环境变量：

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

KEK 绝不会与数据库存储在一起。丢失 KEK 会导致存储的凭据全部丢失（这是有意为之的故障关闭机制）。在生产环境中，应从 KMS 或 Vault 获取 MCP_KEK，而不是从操作员的 shell 获取。

接入方式（任选其一）：

1. 浏览器 — 完成身份验证后访问 /setup；在表单中粘贴凭据。
2. MCP 客户端 — 调用 register-pce-credentials 工具；这是注册凭据前唯一可用的工具。

其他凭据工具：

• check-pce-credentials-status — 此用户是否已注册凭据？
• delete-pce-credentials — 删除此用户的凭据。

基于角色的授权（阶段 3c）

服务会将每位用户的 IdP 组映射到三个内部角色之一：reader、operator、admin。调度器根据每个 ToolSpec 上的 roles 元数据执行逐工具授权。

通过环境变量配置组 → 角色映射（逗号分隔）：

# 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

各类工具的默认设置：

工具类别	允许的角色	示例
读取	reader, operator, admin	get-labels、get-workloads、get-traffic-flows
写入	operator, admin	create-*、update-*、delete-*
配置 + 批量操作	admin	provision-policy、ringfence-batch

没有匹配角色（且未设置 MCP_ROLE_DEFAULT）的用户会收到结构化的 forbidden_no_role 错误。

审计日志（阶段 3c）

调度器的每项决策（允许 / 拒绝 / 错误）都会写入 SQLite 审计数据库。架构和存储位置：

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

审计行包含 (ts, sub, iss, tool, decision, reason, role, request_id) — 绝不包含工具参数。request_id 与响应标头 X-Request-Id 相匹配，因此可以关联外部跟踪记录。

查询示例：

-- 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;

变更工具的确认令牌（阶段 3d）

标记为 requires_confirm=True 的工具（当前包括 provision-policy、ringfence-batch、register-pce-credentials、delete-pce-credentials）通过 HTTP 调用时，必须在 params._meta.confirm_token 中提供由服务签发的一次性确认令牌。Stdio 模式不受影响 — 启动进程的操作员可直接调用变更工具。

身份验证模式下所需的环境变量：

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

客户端如何使用

1. 不带令牌调用变更工具 → 服务返回：

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

2. 携带 JWT 和 params_hash 调用 POST /confirm：

   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. 在 params._meta.confirm_token 中携带令牌重新调用该工具。

令牌仅可使用一次（重放会返回 confirm_token_replay），并且限定于 (sub, tool, params_hash)。篡改任何字段都会使令牌失效。

逐步身份验证（可选，生产环境推荐）

设置 MCP_CONFIRM_FRESH_AUTH_SECONDS=300，要求 JWT 的 auth_time 声明必须在最近 5 分钟内。这样会强制用户在签发令牌前重新进行身份验证 — 在没有交互式会话模型的情况下，这是防范提示注入的最强措施。要求 IdP 提供 auth_time（Entra 和 Okta 在 OIDC 登录流程中都会提供）。

工具

工作负载管理

• get-workloads — 获取工作负载，可按名称、主机名、IP、标签和最大结果数进行可选筛选
• create-workload — 创建包含名称、IP 地址和标签的非托管工作负载
• update-workload — 更新现有工作负载的属性
• delete-workload — 从 PCE 中移除工作负载

标签操作

• get-labels — 获取标签，可按键、值和最大结果数进行可选筛选
• create-label — 使用键值对创建新标签
• update-label — 更新现有标签
• delete-label — 移除标签

规则集与规则管理

• get-rulesets — 获取规则集，可按名称、描述和启用状态进行筛选
• create-ruleset — 创建带有范围的新规则集
• update-ruleset — 更新规则集属性
• delete-ruleset — 删除规则集
• create-deny-rule — 在规则集中创建拒绝规则（常规拒绝或覆盖拒绝）
• update-deny-rule — 更新现有拒绝规则
• delete-deny-rule — 删除拒绝规则

IP 列表管理

• get-iplists — 获取 IP 列表，包含结构化的 ip_ranges 和 fqdns、pversion（draft|active）、Any 列表上的 is_default，以及用于精确查询“哪些列表涵盖此地址”的服务端 contains_ip
• create-iplist — 创建新的 IP 列表
• update-iplist — 更新现有 IP 列表
• delete-iplist — 删除 IP 列表

服务管理

• get-services — 获取服务，可按名称、端口、协议和结果数上限进行筛选
• create-service — 创建新的服务定义
• update-service — 更新现有服务
• delete-service — 删除服务

流量分析

• get-traffic-flows — 获取详细的流量数据，可按日期范围、源/目标、服务、策略决策等进行筛选
• get-traffic-flows-summary — 获取按应用、环境、端口和协议分组的汇总流量

自动化环隔离

• create-ringfence — 自动创建应用间分段策略。 分析流量数据，发现与目标应用通信的远程应用，然后创建规则集，其中包含：
  • 范围内允许规则 — 应用中的所有工作负载都可以自由通信
  • 范围外允许规则 — 为发现的每个远程应用创建一条针对 All Services 的允许规则
  • 选择性强制模式（selective=true）— 添加一条阻止所有入站流量的拒绝规则，并优先处理已知应用的允许规则。比完整强制模式更快进入强制执行阶段。
  • 拒绝消费者类型（deny_consumer 参数）：
    • any（默认）— 使用 IP 列表 Any（0.0.0.0/0）作为消费者，仅在目标端拒绝。最安全。
    • ams — 使用 All Workloads 作为消费者，将拒绝规则推送到每个受管理的工作负载。覆盖范围更广。
    • ams_and_any — 两者兼用，覆盖范围最大。
  • 策略覆盖感知 — 每条规则都会标注为 already_allowed（流量已由现有策略覆盖，创建规则仅用于记录）或 newly_allowed（用于填补策略缺口）。摘要会显示已有多少远程应用受到覆盖，以及有多少需要新增规则。
  • skip_allowed 参数 — 设置为 true，仅为尚未被现有策略覆盖的流量创建规则，从而生成仅用于填补缺口的最精简规则集
  • 安全合并 — 检测现有规则集和规则，不会创建重复项
  • 支持试运行 — 预览将创建的内容，而不实际更改任何内容

基础设施服务识别

• identify-infrastructure-services — 通过分析流量模式，发现哪些应用是基础设施服务。构建应用间通信图，并使用双模式评分识别两类基础设施：

  提供方基础设施（AD、DNS、共享数据库）——被许多应用使用，入度高、出度低。 使用方基础设施（监控、备份、日志传输）——与许多应用建立出站连接，出度高、入度低。

  每个应用会计算两个分数，取较高者：

  分数	度量指标（40%）	方向性（30%）	中介中心性（25%）	流量（5%）
  提供方	入度	使用方比例（入度/总度）	中介中心性	连接流量
  使用方	出度	提供方比例（出度/总度）	中介中心性	连接流量

  混合流量降权： score *= 1 / (1 + min(in_degree, out_degree) * 0.3)——同时存在大量入站和出站连接的应用属于业务应用，而非基础设施。纯单向应用（全部入站或全部出站）不受惩罚。

  非生产环境（staging、dev 等）会受到50% 的分数惩罚，因为基础设施服务通常位于生产环境中。

  应用分为以下层级：

  • 核心基础设施（分数 >= 75）——监控、AD、SIEM、DNS。优先为这些应用设置策略。
  • 共享服务（分数 >= 50）——共享数据库、消息队列。其次为这些应用设置策略。
  • 标准应用（分数 < 50）——普通业务应用。

  每个结果都包含 dominant_pattern 字段（"provider" 或 "consumer"），用于指示该应用更符合哪种基础设施类型。

  重要原因： 基础设施服务会被许多应用使用，或与许多应用建立出站连接。如果在未先放行基础设施服务的情况下隔离应用，就会破坏依赖关系。此工具会告诉你应优先为哪些服务设置策略。

策略生命周期

• provision-policy — 部署待处理的草稿更改，将其从草稿状态转为活动状态。可部署所有待处理更改，也可按 href 指定项目。包含更改说明，便于审计。
• compare-draft-active — 比较草稿策略与活动策略，预览部署时会发生哪些变化。显示新建、更新和删除的规则集、规则、IP 列表及服务。

强制执行就绪度

• enforcement-readiness — **评估应用是否已准备好进行强制执行。**分析流量流、现有策略覆盖范围、强制执行模式和隔离状态。返回就绪度评分（0-100）以及可执行的建议：
  • 策略覆盖范围（40 分）——有规则覆盖的流量占比
  • 已创建隔离规则集（20 分）——是否已创建隔离规则集
  • 强制执行模式（20 分）——工作负载是否处于 full/selective/visibility_only 模式
  • 无被阻止的流量（10 分）——没有非预期的阻止
  • 所有远程应用均已覆盖（10 分）——没有未覆盖的远程应用流量

批量操作

• ringfence-batch — **一次隔离多个应用。**可选用 identify-infrastructure-services 按基础设施评分自动排列应用顺序（先基础设施，再标准应用）。支持 dry-run 模式，可在应用更改前预览所有更改。

工作负载强制执行状态

• get-workload-enforcement-status — 获取各工作负载的强制执行模式状态，按应用和环境分组。显示各模式（idle、visibility_only、selective、full）的数量，并识别处于混合强制执行状态的应用——这是部署过程中常见的问题。

策略覆盖情况

• get-policy-coverage-report — 生成应用的策略覆盖报告，展示现有规则覆盖的流量以及会被阻止的流量。按入站／出站流量细分，识别未覆盖的服务和远程应用，并提供总体覆盖率。
• find-unmanaged-traffic — 查找涉及未托管工作负载或 IP 地址的流量。这些源和目标没有应用／环境标签，代表策略盲区。可按方向（入站／出站／两者）和连接数筛选。

安全分析

• detect-lateral-movement-paths — 通过分析应用间流量模式，检测潜在的横向移动路径。识别关键节点（桥接节点）；一旦这些节点遭到入侵，攻击者便可访问原本彼此隔离的应用组。计算从任意起始应用出发的可达性，并追踪可配置深度内的多跳路径。
• compliance-check — 初步检查策略态势是否符合某个框架（PCI-DSS、DORA、NIS2、NIST 800-53、CIS Controls、ISO 27001、SWIFT CSP、HIPAA 或一般最佳实践）。根据草稿策略和近期流量，通过关键词路由启发式进行检查，并以分数和逐项检查结果（PASS/FAIL/WARNING）汇总。不能作为审计证据。
• collect-compliance-evidence — 根据每个应用／环境范围对的分段控制审计证据，取自活动策略和观测到的流量：清单、强制执行、VEN 健康状况、未托管工作负载、已描述的提供方规则、无宽泛的使用方、获准服务与批准列表的对比、跨越入站和出站边界的流量及阻止流量时间线、草稿与活动策略的差异、时间窗口内的事件和流量。每项测试和范围对都会给出 PASS/FAIL/EXCEPTION/NOT_TESTED，以及相应规则、测量值和数据行。达到上限的拉取结果不会判定为通过。框架映射位于 illumio://compliance/* 资源中。

事件监控

• get-events — 获取 PCE 事件，可按事件类型、严重性、状态筛选，并限制结果数量

连接测试

• check-pce-connection — 验证 PCE 连接和凭据

测试

该项目包含一套全面的集成测试，可通过 MCP 协议连接真实 PCE 运行。

# 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

测试套件涵盖：

• 工具列表和架构验证
• 工作负载、标签、IP 列表、服务、规则集和拒绝规则的完整 CRUD 生命周期
• 流量查询和摘要
• Ringfence 创建（标准模式、选择性模式、拒绝使用方模式、合并幂等性）
• 基础设施服务识别（评分、排序、层级分类）
• 缺少资源时的错误处理

Illumio 规则处理顺序

了解规则处理顺序对于 Ringfence 至关重要：

1. 基本规则 — 内置规则，无法修改
2. 覆盖拒绝规则 — 阻止流量，优先于所有允许规则（用于紧急情况）
3. 允许规则 — 允许流量（Ringfence 远程应用规则位于此处）
4. 拒绝规则 — 阻止特定流量（Ringfence 的拒绝所有入站规则位于此处）
5. 默认操作 — 选择性模式 = 全部允许，完全强制执行 = 全部拒绝

在选择性强制执行模式下，默认操作为全部允许，因此需要拒绝规则才能使 Ringfence 生效。已知的远程应用会获得允许规则（步骤 3），这些规则会先于拒绝规则（步骤 4）处理。

视觉示例

以下示例均由 Claude Desktop 生成，数据来自此 MCP 服务。

应用分析

应用通信模式和依赖关系的详细视图

分析不同应用层级之间的流量模式

基础设施洞察

显示关键基础设施指标和状态的概览仪表板

基础设施服务通信的详细分析

安全评估

全面的安全分析报告

针对高风险漏洞的安全评估发现

PCI 合规性评估发现

SWIFT 合规性评估发现

修复规划

安全修复规划概览

安全修复实施的详细步骤

策略管理

IP 列表管理界面

规则集类别和组织方式概览

应用规则集排序配置

工作负载管理

工作负载分析和指标详情

工作负载流量模式的识别与分析

标签管理

按类型和类别组织 PCE 标签

服务分析

根据流量模式自动推断服务角色

分析排名前 5 的流量来源和目标

项目规划

项目实施时间线和里程碑

可用提示词

隔离应用

ringfence-application 提示词可帮助创建安全策略，通过控制入站和出站流量来隔离并保护应用。

必需参数：

• application_name：要隔离的应用名称
• application_environment：要隔离的应用环境

功能：

• 为应用内部的层间通信创建规则
• 使用流量流识别所需的外部连接
• 根据源应用实施入站流量限制
• 为必要的外部通信创建出站流量规则
• 处理范围内（相同应用/环境）和范围外（外部）连接
• 为远程应用连接创建单独的规则集

分析应用流量

analyze-application-traffic 提示词可详细分析应用流量模式和连接情况。

必需参数：

• application_name：要分析的应用名称
• application_environment：要分析的应用环境

分析功能：

• 按入站和出站流量对流量排序
• 按应用/环境/角色组合分组
• 识别相关标签类型和模式
• 以 React 组件格式显示结果
• 显示协议信息和端口信息
• 尝试识别已知服务模式（例如，端口 5666 上的 Nagios）
• 将流量分类为基础设施和应用类型
• 判断是否暴露于互联网
• 显示 Illumio 角色、应用和环境标签

如何使用 MCP 提示词

步骤 1：点击界面中的“Attach from MCP”按钮

步骤 2：从已安装的 MCP 服务中选择

步骤 3：填写必需的提示词参数：

步骤 4：点击 Submit，发送配置好的提示词

提示词的工作方式

• MCP 服务会将配置好的提示词发送给 Claude
• Claude 通过 Model Context Protocol 接收上下文
• 支持针对 Illumio 特定任务进行专门处理

此工作流可在 Illumio 系统与 Claude 之间自动共享上下文，用于应用流量分析和隔离任务。

Docker

此应用以 Docker 容器的形式托管在 GitHub Container Registry 中。

拉取容器

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

你也可以将 latest 替换为版本号，以使用指定版本：

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

与 Claude Desktop 搭配运行

要将此容器与 Claude Desktop 搭配使用，你需要：

1. 创建一个环境文件（例如 ~/.illumio-mcp.env），其中包含你的 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. 将以下配置添加到 Claude Desktop 配置文件中：

在 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"
            ]
        }
    }
}

请确保：

• 将 YOUR_USERNAME 替换为你的实际用户名
• 创建日志目录（例如 ~/tmp）
• 根据你的系统调整路径

独立运行

你也可以直接运行容器：

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

用于开发或测试时，你可以使用 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

然后运行：

docker-compose up

贡献

1. Fork 此仓库
2. 创建一个功能分支
3. 提交你的更改
4. 推送到该分支
5. 创建 Pull Request

许可证

本项目采用 GPL-3.0 许可证授权。详情请参阅 LICENSE 文件。

支持

如需支持，请创建问题。