Illumio MCP Server

Illumio MCP Server

Um servidor Model Context Protocol (MCP) que fornece uma interface para interagir com o Illumio PCE (Policy Compute Engine). Este servidor permite acesso programático ao gerenciamento de workloads do Illumio, operações de labels, análise de tráfego, ringfencing automatizado e identificação de serviços de infraestrutura.

O que ele pode fazer?

Use IA conversacional para falar com seu PCE:

• CRUD completo em workloads, labels, listas de IP, serviços e rulesets
• Análise de tráfego — consultar fluxos, obter resumos, filtrar por decisão de política
• Ringfencing automatizado — analisar tráfego e criar políticas de segmentação app-to-app com um comando
• Enforcement seletivo — adicionar regras de negação para apps em modo seletivo com sabores de consumidor configuráveis
• Identificação de serviços de infraestrutura — descobrir quais apps são serviços de infraestrutura usando análise de centralidade de grafo, para saber o que priorizar na política
• Gerenciamento de regras de negação — criar, atualizar e excluir regras de negação (incluindo negação por override para emergências)
• Monitoramento de eventos — consultar eventos do PCE com filtros de severidade e tipo
• Verificações de saúde do PCE — verificar conectividade e credenciais

Pré-requisitos

• Python 3.8+
• Acesso a uma instância do Illumio PCE
• Credenciais de API válidas para o PCE

Instalação

1. Clone o repositório:

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

2. Instale as dependências:

uv sync

Configuração

Você deve executar isso usando o comando uv, que facilita passar variáveis de ambiente e executar em segundo plano.

Usando uv e Claude Desktop

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

Adicione o seguinte à seção 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 com OAuth Resource Server (Fase 3a)

O servidor roda sobre HTTP usando o transporte MCP Streamable HTTP (revisão da spec 2025-03-26) e valida tokens bearer OAuth 2.1 emitidos pelo seu IdP. Esta é a Fase 3a: a identidade é aplicada; chaves PCE por usuário chegam na Fase 3b.

Executando com autenticação (formato de produção)

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

O servidor se recusa a iniciar sem essas variáveis de ambiente (a menos que MCP_DEV_INSECURE=1).

Clientes MCP descobrem o AS via o endpoint padrão RFC 9728:

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

Requisições não autenticadas para /mcp retornam 401 com WWW-Authenticate: Bearer resource_metadata="<URL>", que qualquer cliente MCP compatível com a spec (Claude Desktop, ChatGPT, MCP Inspector) segue automaticamente para executar o fluxo de código de autorização PKCE contra o AS configurado.

Executando sem autenticação (apenas dev)

MCP_DEV_INSECURE=1 illumio-mcp-http

O servidor registra um aviso proeminente. NÃO use em produção.

Endpoints de saúde (sempre não autenticados)

• GET /healthz — liveness
• GET /readyz — readiness (a Fase 3a retorna o mesmo que healthz; as Fases 3b/c adicionarão alcance do PCE + JWKS)

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

O servidor HTTP suporta duas formas de obter credenciais do PCE, selecionadas via MCP_PCE_MODE:

Modo	MCP_PCE_MODE	Credenciais do PCE	Onboarding	Auditoria no lado do PCE
Por usuário (padrão)	per_user	Uma chave de API do PCE por usuário autenticado, criptografada no keystore	Usuário registra via página /setup ou ferramenta register-pce-credentials	Logs do PCE mostram o humano real via chave de API por usuário
Compartilhado	shared	Uma chave de conta de serviço do PCE do env (mesma que stdio)	Nenhum — funciona imediatamente para qualquer usuário autenticado	Logs do PCE mostram a conta de serviço; o log de auditoria do MCP é a fonte da verdade para "quem fez o quê"

Escolha por usuário quando:

• Você quiser atribuição de auditoria no lado do PCE para identificar o humano
• Usuários estiverem dispostos a fornecer sua própria chave de API do PCE uma vez
• Você puder tolerar a proliferação de chaves PCE por usuário (o PCE tem limites)

Escolha compartilhado quando:

• O PCE limitar chaves de API por usuário de forma muito agressiva para o modo por usuário
• Você quiser onboarding sem fricção (sem etapa /setup)
• Você estiver OK em confiar apenas no log de auditoria do MCP para atribuição em nível humano
• Você operar a conta de serviço do PCE e rotacioná-la em um cronograma

No modo compartilhado, /setup não é montado, as ferramentas de gerenciamento de credenciais (register-pce-credentials, delete-pce-credentials) recusam com um erro amigável, e MCP_KEK não é necessário. SSO + JWT + autorização baseada em papéis + log de auditoria + tokens de confirmação ainda se aplicam 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

Chaves PCE por usuário (Fase 3b)

Cada usuário autenticado tem sua própria chave/segredo de API do PCE armazenada em um keystore SQLite criptografado. Os logs de auditoria no lado do PCE atribuem corretamente por humano; revogar um usuário é uma única chamada de ferramenta.

Env adicional necessário ao executar com autenticação:

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

O KEK nunca é armazenado ao lado do banco de dados. Perda do KEK = perda total das credenciais armazenadas (intencional, fail-closed). Para produção, obtenha MCP_KEK do KMS ou Vault em vez do shell do operador.

Caminhos de onboarding (qualquer um funciona):

1. Navegador — visite /setup após autenticar; cole as credenciais no formulário.
2. Cliente MCP — chame a ferramenta register-pce-credentials; a única ferramenta disponível antes de as credenciais serem registradas.

Outras ferramentas de credenciais:

• check-pce-credentials-status — este usuário tem credenciais registradas?
• delete-pce-credentials — remove as credenciais deste usuário.

Autorização baseada em papéis (Fase 3c)

O servidor mapeia os grupos do IdP de cada usuário para um dos três papéis internos: reader, operator, admin. A autorização por ferramenta é aplicada pelo dispatcher usando os metadados roles em cada ToolSpec.

Configure o mapeamento grupo → papel via env (separado por vírgulas):

# 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

Padrões por ferramenta:

Categoria de ferramenta	Papéis permitidos	Exemplos
Leituras	reader, operator, admin	get-labels, get-workloads, get-traffic-flows
Escritas	operator, admin	create-*, update-*, delete-*
Provisionamento + em massa	admin	provision-policy, ringfence-batch

Um usuário sem papel correspondente (e sem MCP_ROLE_DEFAULT) recebe um erro estruturado forbidden_no_role.

Log de auditoria (Fase 3c)

Cada decisão do dispatcher (permitir / negar / erro) é gravada em um banco de dados de auditoria SQLite. Esquema e local de armazenamento:

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

As linhas de auditoria incluem (ts, sub, iss, tool, decision, reason, role, request_id) — nunca argumentos de ferramenta. O request_id corresponde ao cabeçalho de resposta X-Request-Id para que rastreamentos externos possam ser correlacionados.

Exemplos 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 confirmação para ferramentas de mutação (Fase 3d)

Ferramentas marcadas com requires_confirm=True (atualmente provision-policy, ringfence-batch, register-pce-credentials, delete-pce-credentials) exigem um token de confirmação de uso único emitido pelo servidor em params._meta.confirm_token quando chamadas via HTTP. O modo Stdio não é afetado — o operador que iniciou o processo pode chamar ferramentas de mutação diretamente.

Env necessário no modo de autenticação:

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

Como um cliente usa

1. Chame a ferramenta de mutação sem token → o servidor retorna:

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

2. Chame POST /confirm com o JWT e o 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. Rechame a ferramenta com o token em params._meta.confirm_token.

Os tokens são de uso único (replays retornam confirm_token_replay) e escopados a (sub, tool, params_hash). Alterar qualquer campo invalida o token.

Autenticação step-up (opcional, recomendada para produção)

Defina MCP_CONFIRM_FRESH_AUTH_SECONDS=300 para exigir que a claim auth_time do JWT esteja dentro dos últimos 5 minutos. Força o usuário a reautenticar antes de emitir um token — a defesa mais forte contra injeção de prompt disponível sem um modelo de sessão interativa. Exige que o IdP emita auth_time (Entra e Okta fazem isso para fluxos de login OIDC).

Ferramentas

Gerenciamento de Workloads

• get-workloads — Recuperar workloads com filtragem opcional por nome, hostname, IP, labels e máximo de resultados
• create-workload — Criar um workload não gerenciado com nome, endereços IP e labels
• update-workload — Atualizar as propriedades de um workload existente
• delete-workload — Remover um workload do PCE

Operações de Labels

• get-labels — Recuperar labels com filtragem opcional por chave, valor e máximo de resultados
• create-label — Criar um novo label com par chave-valor
• update-label — Atualizar um label existente
• delete-label — Remover um label

Gerenciamento de Rulesets e Regras

• get-rulesets — Obter rulesets com filtragem opcional por nome, descrição e status de habilitado
• create-ruleset — Criar um novo ruleset com escopos
• update-ruleset — Atualizar propriedades do ruleset
• delete-ruleset — Remover um ruleset
• create-deny-rule — Criar uma regra de negação (regular ou override deny) em um ruleset
• update-deny-rule — Atualizar uma regra de negação existente
• delete-deny-rule — Remover uma regra de negação

Gerenciamento de Listas de IP

• get-iplists — Obter listas de IP com filtragem opcional por nome, descrição, FQDN e máximo de resultados
• create-iplist — Criar uma nova lista de IP
• update-iplist — Atualizar uma lista de IP existente
• delete-iplist — Remover uma lista de IP

Gerenciamento de Serviços

• get-services — Obter serviços com filtragem opcional por nome, porta, protocolo e máximo de resultados
• create-service — Criar uma nova definição de serviço
• update-service — Atualizar um serviço existente
• delete-service — Remover um serviço

Análise de Tráfego

• get-traffic-flows — Obter dados detalhados de fluxo de tráfego com filtragem por intervalo de datas, origem/destino, serviço, decisão de política e mais
• get-traffic-flows-summary — Obter resumos agregados de tráfego agrupados por app, env, porta e protocolo

Ringfencing Automatizado

• create-ringfence — Criação automatizada de política de segmentação app-to-app. Analisa fluxos de tráfego para descobrir quais apps remotos se comunicam com um app alvo e, em seguida, cria um ruleset com:
  • Regra de permissão intra-escopo — todos os workloads dentro do app podem se comunicar livremente
  • Regras de permissão extra-escopo — cada app remoto descoberto recebe uma regra de permissão em All Services
  • Modo de enforcement seletivo (selective=true) — adiciona uma regra de negação bloqueando todo o tráfego de entrada, com regras de permissão para apps conhecidos processadas primeiro. Leva você ao enforcement mais rápido que o modo de enforcement total.
  • Sabores de consumidor de negação (parâmetro deny_consumer):
    • any (padrão) — lista de IP Any (0.0.0.0/0) como consumidor, negação apenas no destino. Mais seguro.
    • ams — All Workloads como consumidor, negação aplicada a cada workload gerenciado. Mais amplo.
    • ams_and_any — Ambos. Cobertura máxima.
  • Consciência de cobertura de política — cada regra é anotada como already_allowed (tráfego coberto por política existente, criado para documentação) ou newly_allowed (preenchendo uma lacuna de política). O resumo mostra quantos apps remotos já estão cobertos vs. precisam de novas regras.
  • Parâmetro skip_allowed — defina como true para criar apenas regras para tráfego ainda não coberto por política existente, produzindo rulesets mínimos que preenchem apenas lacunas
  • Seguro para merge — detecta rulesets e regras existentes, nunca cria duplicatas
  • Suporte a dry-run — visualize o que seria criado sem fazer alterações

Identificação de Serviços de Infraestrutura

• identify-infrastructure-services — Descubra quais apps são serviços de infraestrutura analisando padrões de tráfego. Constrói um grafo de comunicação app-to-app e usa pontuação de padrão duplo para reconhecer dois tipos de infraestrutura:

  Infra de provedor (AD, DNS, DB compartilhado) — consumida por muitos apps, alto grau de entrada, baixo grau de saída. Infra de consumidor (monitoramento, backup, envio de logs) — conecta-se a muitos apps, alto grau de saída, baixo grau de entrada.

  Dois escores são calculados por app, e o maior vence:

  Escore	Métrica de grau (40%)	Direcionalidade (30%)	Betweenness (25%)	Volume (5%)
  Provedor	Grau de entrada	Razão de consumidor (entrada/total)	Centralidade de betweenness	Volume de conexões
  Consumidor	Grau de saída	Razão de produtor (saída/total)	Centralidade de betweenness	Volume de conexões

  Atenuação de tráfego misto: score *= 1 / (1 + min(in_degree, out_degree) * 0.3) — apps com conexões significativas de entrada E saída são apps de negócios, não infraestrutura. Apps puramente direcionais (tudo entrada OU tudo saída) não recebem penalidade. Ambientes de não produção (staging, dev, etc.) recebem uma penalidade de 50% na pontuação já que os serviços de infraestrutura normalmente vivem em produção.

Os aplicativos são classificados em camadas:

• Infraestrutura Principal (pontuação >= 75) — monitoramento, AD, SIEM, DNS. Aplique políticas primeiro.
• Serviço Compartilhado (pontuação >= 50) — bancos de dados compartilhados, filas de mensagens. Aplique políticas em segundo lugar.
• Aplicativo Padrão (pontuação < 50) — aplicativos de negócios normais.

Cada resultado inclui um campo dominant_pattern ("provider" ou "consumer") indicando qual tipo de infraestrutura o aplicativo se assemelha.

Por que isso importa: Os serviços de infraestrutura são consumidos por muitos aplicativos OU conectam-se a muitos aplicativos. Se você isolar aplicativos sem permitir primeiro os serviços de infraestrutura, você quebra dependências. Esta ferramenta informa o que priorizar em políticas.

Ciclo de Vida de Políticas

• provision-policy — Provisionar alterações pendentes de rascunho para movê-las do estado de rascunho para ativo. Pode provisionar todas as alterações pendentes ou itens específicos por href. Inclui descrições de alterações para trilha de auditoria.
• compare-draft-active — Comparar política de rascunho vs ativa para pré-visualizar o que mudaria no provisionamento. Mostra rulesets, regras, listas de IP e serviços criados, atualizados e excluídos.

Prontidão para Aplicação de Políticas

• enforcement-readiness — Avaliar se um aplicativo está pronto para a aplicação de políticas. Analisa fluxos de tráfego, cobertura de políticas existente, modos de aplicação e status de isolamento. Retorna uma pontuação de prontidão (0-100) com recomendações acionáveis:
  • Cobertura de políticas (40 pontos) — qual porcentagem do tráfego é coberta por regras
  • Isolamento existente (20 pontos) — um conjunto de regras de isolamento foi criado
  • Modo de aplicação (20 pontos) — as cargas de trabalho estão em full/selective/visibility_only
  • Nenhum tráfego bloqueado (10 pontos) — sem bloqueios não intencionais
  • Todos os aplicativos remotos cobertos (10 pontos) — sem tráfego de aplicativos remotos descoberto

Operações em Lote

• ringfence-batch — Isolar vários aplicativos de uma vez. Opcionalmente usa identify-infrastructure-services para ordenar automaticamente os aplicativos por pontuação de infraestrutura (infraestrutura primeiro, depois aplicativos padrão). Suporta modo de simulação (dry-run) para pré-visualizar todas as alterações antes de aplicar.

Status de Aplicação de Políticas em Cargas de Trabalho

• get-workload-enforcement-status — Obter o status do modo de aplicação em todas as cargas de trabalho, agrupado por aplicativo e ambiente. Mostra contagens por modo (idle, visibility_only, selective, full) e identifica aplicativos com estados de aplicação mistos — um problema comum durante implantações.

Cobertura de Políticas

• get-policy-coverage-report — Gerar um relatório de cobertura de políticas para um aplicativo mostrando qual tráfego é coberto pelas regras existentes versus o que seria bloqueado. Detalha por entrada/saída, identifica serviços e aplicativos remotos não cobertos e fornece uma porcentagem geral de cobertura.
• find-unmanaged-traffic — Encontrar tráfego envolvendo cargas de trabalho não gerenciadas ou endereços IP. Essas são fontes/destinos sem rótulos de aplicativo/ambiente, representando pontos cegos de políticas. Filtra por direção (entrada/saída/ambos) e contagem de conexões.

Análise de Segurança

• detect-lateral-movement-paths — Detectar possíveis caminhos de movimento lateral analisando padrões de tráfego entre aplicativos. Identifica pontos de articulação (nós ponte) cujo comprometimento forneceria acesso a grupos de aplicativos de outra forma desconectados. Calcula a alcançabilidade a partir de qualquer aplicativo inicial e rastreia caminhos de múltiplos saltos até uma profundidade configurável.
• compliance-check — Verificar conformidade de políticas em relação a frameworks (PCI-DSS, NIST 800-53, CIS Controls ou melhores práticas gerais). Avalia segmentação, modos de aplicação, exposição de portas de alto risco e cobertura de políticas. Retorna uma pontuação de conformidade com achados por verificação (PASS/FAIL/WARNING).

Monitoramento de Eventos

• get-events — Obter eventos do PCE com filtragem opcional por tipo de evento, severidade, status e limites de resultado

Teste de Conexão

• check-pce-connection — Verificar conectividade e credenciais do PCE

Testes

O projeto inclui uma suíte abrangente de testes de integração que executa contra um PCE real usando o 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

A suíte de testes cobre:

• Listagem de ferramentas e validação de esquema
• Ciclo de vida CRUD completo para cargas de trabalho, rótulos, listas de IP, serviços, rulesets e regras de negação
• Consultas e resumos de fluxos de tráfego
• Criação de isolamento (padrão, seletivo, variantes de negação de consumidor, idempotência de mesclagem)
• Identificação de serviços de infraestrutura (pontuação, ordenação, classificação em camadas)
• Tratamento de erros para recursos ausentes

Ordem de Processamento de Regras do Illumio

Entender o processamento de regras é essencial para o isolamento:

1. Regras essenciais — integradas, não podem ser modificadas
2. Regras de negação de sobreposição — bloqueiam tráfego sobrepondo todas as permissões (uso emergencial)
3. Regras de permissão — permitem tráfego (regras de aplicativos remotos de isolamento vão aqui)
4. Regras de negação — bloqueiam tráfego específico (negação de todo tráfego de entrada do isolamento vai aqui)
5. Ação padrão — modo seletivo = permitir tudo, aplicação total = negar tudo

Na aplicação seletiva, o padrão é permitir tudo, então uma regra de negação é necessária para tornar o isolamento eficaz. Aplicativos remotos conhecidos recebem regras de permissão (passo 3) que são processadas antes da negação (passo 4).

Exemplos Visuais

Todos os exemplos abaixo foram gerados pelo Claude Desktop e com dados obtidos através deste servidor MCP.

Análise de Aplicativos

Visão detalhada dos padrões de comunicação e dependências do aplicativo

Análise dos padrões de tráfego entre diferentes camadas de aplicativos

Insights de Infraestrutura

Painel de visão geral mostrando métricas e status chave da infraestrutura

Análise detalhada das comunicações dos serviços de infraestrutura

Avaliação de Segurança

Relatório abrangente de análise de segurança

Resultados da avaliação de segurança para vulnerabilidades de alto risco

Resultados da avaliação de conformidade PCI

Resultados da avaliação de conformidade SWIFT

Planejamento de Remediação

Visão geral do planejamento de remediação de segurança

Passos detalhados para a implementação da remediação de segurança

Gerenciamento de Políticas

Interface de gerenciamento para listas de IP

Visão geral das categorias e organização de rulesets

Configuração da ordenação de rulesets de aplicativos

Gerenciamento de Cargas de Trabalho

Análise detalhada e métricas de cargas de trabalho

Identificação e análise dos padrões de tráfego de cargas de trabalho

Gerenciamento de Rótulos

Organização dos rótulos do PCE por tipo e categoria

Análise de Serviços

Inferência automática de papéis de serviço com base nos padrões de tráfego

Análise dos 5 principais destinos e origens de tráfego

Planejamento de Projetos

Cronograma de implementação do projeto e marcos

Prompts Disponíveis

Isolamento de Aplicativo

O prompt ringfence-application ajuda a criar políticas de segurança para isolar e proteger aplicativos controlando o tráfego de entrada e saída.

Argumentos Obrigatórios:

• application_name: Nome do aplicativo a ser isolado
• application_environment: Ambiente do aplicativo a ser isolado

Recursos:

• Cria regras para comunicação entre camadas dentro do aplicativo
• Usa fluxos de tráfego para identificar conexões externas necessárias
• Implementa restrições de tráfego de entrada com base nos aplicativos de origem
• Cria regras de tráfego de saída para comunicações externas necessárias
• Lida com conexões intra-escopo (mesmo app/ambiente) e extra-escopo (externas)
• Cria rulesets separados para conexões de aplicativos remotos

Analisar Tráfego de Aplicativo

O prompt analyze-application-traffic fornece análise detalhada dos padrões de tráfego e conectividade do aplicativo.

Argumentos Obrigatórios:

• application_name: Nome do aplicativo a ser analisado
• application_environment: Ambiente do aplicativo a ser analisado

Recursos de Análise:

• Ordena o tráfego por fluxos de entrada e saída
• Agrupa por combinações de aplicativo/ambiente/papel
• Identifica tipos e padrões de rótulos relevantes
• Exibe resultados em formato de componente React
• Mostra informações de protocolo e porta
• Tenta identificar padrões de serviços conhecidos (ex.: Nagios na porta 5666)
• Categoriza o tráfego em tipos de infraestrutura e aplicativo
• Determina exposição à internet
• Exibe rótulos de papel, aplicativo e ambiente do Illumio

Como usar os prompts do MCP

Passo 1: Clique no botão "Attach from MCP" na interface

Passo 2: Escolha entre os servidores MCP instalados

Passo 3: Preencha os argumentos obrigatórios do prompt:

Passo 4: Clique em Enviar para enviar o prompt configurado

Como os prompts funcionam

• O servidor MCP envia o prompt configurado para o Claude
• O Claude recebe o contexto através do Model Context Protocol
• Permite tratamento especializado de tarefas específicas do Illumio

Este fluxo de trabalho permite o compartilhamento automatizado de contexto entre os sistemas Illumio e o Claude para análise de tráfego de aplicativos e tarefas de isolamento.

Docker

O aplicativo está disponível como um contêiner Docker no GitHub Container Registry.

Baixar o contêiner

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

Você também pode usar uma versão específica substituindo latest por um número de versão:

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

Executar com Claude Desktop

Para usar o contêiner com o Claude Desktop, você precisará:

1. Criar um arquivo de ambiente (ex.: ~/.illumio-mcp.env) com suas credenciais do 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. Adicionar a seguinte configuração ao seu arquivo de configuração do Claude Desktop:

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

Certifique-se de:

• Substituir YOUR_USERNAME pelo seu nome de usuário real
• Criar o diretório de log (ex.: ~/tmp)
• Ajustar os caminhos de acordo com o seu sistema

Executar de forma autônoma

Você também pode executar o contêiner diretamente:

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 desenvolvimento ou testes, você pode usar o 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

Depois execute:

docker-compose up

Contribuindo

1. Faça um fork do repositório
2. Crie um branch de funcionalidade
3. Faça commit das suas alterações
4. Envie para o branch
5. Crie um Pull Request

Licença

Este projeto é licenciado sob a Licença GPL-3.0. Consulte o arquivo LICENSE para detalhes.

Suporte

Para suporte, por favor crie uma issue.