Illumio MCP Server

Servidor MCP Illumio

📚 Site de documentação — instalação, primeiros passos, fluxos de trabalho, referência completa de ferramentas e implantação central.

Um servidor MCP (Model Context Protocol) 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 rótulos, análise de fluxo 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, rótulos, listas de IP, serviços e conjuntos de regras
• Análise de tráfego em toda a janela — resumos agregam todos os fluxos que o PCE retorna, não apenas os primeiros 500, e relatam quanto existe vs. quanto é exibido
• Agregação em qualquer rótulo — app/env por padrão, ou unidade de negócios, escopo de conformidade, função+localização; quaisquer dimensões que seu PCE definir
• Descoberta de Shadow-AI / egresso — qual processo fala com qual provedor, com atribuição de RDAP e faixas publicadas pelo fornecedor, atualizadas semanalmente no CI
• Política qualificada por processo — "apenas este binário pode acessar aquele aplicativo", via serviços de egresso do Windows e referências de serviço em regras
• Ringfencing automatizado — analise o tráfego e crie políticas de segmentação aplicativo-a-aplicativo com um único comando
• Aplicação seletiva — adicione regras de negação para aplicativos em modo seletivo com opções configuráveis de consumidor
• Identificação de serviços de infraestrutura — descubra quais aplicativos 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 — crie, atualize e exclua regras de negação (incluindo negação por override para emergências)
• Regras editáveis no local — update-sec-rule / delete-sec-rule em vez de reconstruir um conjunto de regras
• Monitoramento de eventos — consulte eventos do PCE com filtros de severidade e tipo
• Verificações de saúde do PCE — verifique conectividade e credenciais
• Informa quando algo mudou — get-server-changelog relata mudanças de comportamento a uma sessão cuja lista de ferramentas em cache está desatualizada

Pré-requisitos

• Python 3.12 ou 3.13 (veja requires-python em pyproject.toml)
• 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 executa sobre HTTP usando o transporte MCP Streamable HTTP (revisão de especificação 2025-03-26) e valida tokens de portador 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 especificação (Claude Desktop, ChatGPT, MCP Inspector) segue automaticamente para executar o fluxo de código PKCE contra o AS configurado.

Executando sem autenticação (apenas desenvolvimento)

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 (Fase 3a retorna o mesmo que healthz; Fase 3b/c adicionará alcance de PCE + JWKS)

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

O servidor HTTP suporta duas maneiras 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 ambiente (mesmo 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ê quer atribuição de auditoria no lado do PCE para identificar o humano
• Os usuários estão dispostos a fornecer sua própria chave de API do PCE uma vez
• Você pode tolerar a proliferação de chaves PCE por usuário (o PCE tem limites)

Escolha compartilhado quando:

• O PCE limita chaves de API por usuário de forma muito agressiva para o modo por usuário
• Você quer onboarding sem fricção (sem etapa /setup)
• Você aceita depender apenas do log de auditoria do MCP para atribuição em nível humano
• Você opera a conta de serviço do PCE e a rotaciona 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 função + 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 armazenado em um keystore SQLite criptografado. Logs de auditoria no lado do PCE atribuem corretamente por humano; revogar um usuário é uma única chamada de ferramenta.

Ambiente 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 próximo ao banco de dados. Perda do KEK = perda total das credenciais armazenadas (intencional, fail-closed). Para produção, obtenha MCP_KEK de 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 que as credenciais sejam 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 função (Fase 3c)

O servidor mapeia os grupos 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 ambiente (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 ferramenta 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

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 como 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.

Ambiente 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.

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

Autenticação escalonada (opcional, recomendada para produção)

Defina MCP_CONFIRM_FRESH_AUTH_SECONDS=300 para exigir que a declaração 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. Requer que o IdP emita auth_time (Entra e Okta ambos fazem para fluxos de login OIDC).

Ferramentas

Gerenciamento de Workloads

• get-workloads — Recupera workloads com filtragem opcional por nome, hostname, IP, rótulos e máximo de resultados
• create-workload — Cria um workload não gerenciado com nome, endereços IP e rótulos
• update-workload — Atualiza as propriedades de um workload existente
• delete-workload — Remove um workload do PCE

Operações de Rótulos

• get-labels — Recupera rótulos com filtragem opcional por chave, valor e máximo de resultados
• create-label — Cria um novo rótulo com par chave-valor
• update-label — Atualiza um rótulo existente
• delete-label — Remove um rótulo

Gerenciamento de Conjuntos de Regras e Regras

• get-rulesets — Obtém conjuntos de regras com filtragem opcional por nome, descrição e status de habilitação
• create-ruleset — Cria um novo conjunto de regras com escopos
• update-ruleset — Atualiza propriedades do conjunto de regras
• delete-ruleset — Remove um conjunto de regras
• create-deny-rule — Cria uma regra de negação (negação regular ou override) em um conjunto de regras
• update-deny-rule — Atualiza uma regra de negação existente
• delete-deny-rule — Remove uma regra de negação

Gerenciamento de Listas de IP

• get-iplists — Obtém listas de IP com filtragem opcional por nome, descrição, FQDN e máximo de resultados
• create-iplist — Cria uma nova lista de IP
• update-iplist — Atualiza uma lista de IP existente
• delete-iplist — Remove uma lista de IP

Gerenciamento de Serviços

• get-services — Obtém serviços com filtragem opcional por nome, porta, protocolo e máximo de resultados
• create-service — Cria uma nova definição de serviço
• update-service — Atualiza um serviço existente
• delete-service — Remove um serviço

Análise de Tráfego

• get-traffic-flows — Obtém 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 — Obtém resumos agregados de tráfego agrupados por aplicativo, ambiente, porta e protocolo

Ringfencing Automatizado

• create-ringfence — Criação automatizada de políticas de segmentação app-a-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 — todas as 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. Acelera o enforcement em comparação ao modo de enforcement total.
  • Variantes de negação de consumidor (parâmetro deny_consumer):
    • any (padrão) — lista de IPs Any (0.0.0.0/0) como consumidor, nega apenas no destino. Mais seguro.
    • ams — All Workloads como consumidor, negação aplicada a todas as workloads gerenciadas. 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 versus quantos precisam de novas regras.
  • Parâmetro skip_allowed — definido 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 mesclagem — detecta rulesets e regras existentes, nunca cria duplicatas
  • Suporte a dry-run — pré-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-a-app e usa pontuação de padrão duplo para reconhecer dois tipos de infraestrutura:

  Infraestrutura provedora (AD, DNS, banco de dados compartilhado) — consumida por muitos apps, alto grau de entrada, baixo grau de saída. Infraestrutura consumidora (monitoramento, backup, envio de logs) — conecta-se a muitos apps, alto grau de saída, baixo grau de entrada.

  Duas pontuações são calculadas por app, e a maior vence:

  Pontuação	Métrica de grau (40%)	Direcionalidade (30%)	Intermediação (25%)	Volume (5%)
  Provedor	Grau de entrada	Razão de consumo (entrada/total)	Centralidade de intermediação	Volume de conexões
  Consumidor	Grau de saída	Razão de produção (saída/total)	Centralidade de intermediação	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 não produtivos (staging, dev, etc.) recebem uma penalidade de 50% na pontuação, pois serviços de infraestrutura normalmente vivem em produção.

  Os apps são classificados em níveis:

  • Infraestrutura principal (pontuação >= 75) — monitoramento, AD, SIEM, DNS. Política estes primeiro.
  • Serviço compartilhado (pontuação >= 50) — bancos de dados compartilhados, filas de mensagens. Política estes em segundo lugar.
  • Aplicação padrão (pontuação < 50) — apps de negócios normais.

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

  Por que isso importa: Serviços de infraestrutura são consumidos por muitos apps OU conectam-se a muitos apps. Se você fizer ringfence em apps sem permitir serviços de infraestrutura primeiro, você quebra dependências. Esta ferramenta informa o que priorizar na política.

Ciclo de Vida de Políticas

• provision-policy — Provisione 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 — Compare política de rascunho vs ativa para pré-visualizar o que mudaria no provisionamento. Mostra rulesets, regras, listas de IPs e serviços criados, atualizados e excluídos.

Prontidão para Enforcement

• enforcement-readiness — Avalie se um app está pronto para enforcement. Analisa fluxos de tráfego, cobertura de política existente, modos de enforcement e status de ringfence. Retorna uma pontuação de prontidão (0-100) com recomendações acionáveis:
  • Cobertura de política (40 pontos) — qual porcentagem do tráfego é coberta por regras
  • Ringfence existe (20 pontos) — um ruleset de ringfence foi criado
  • Modo de enforcement (20 pontos) — as workloads estão em full/selective/visibility_only
  • Nenhum tráfego bloqueado (10 pontos) — sem bloqueios não intencionais
  • Todos os apps remotos cobertos (10 pontos) — sem tráfego de apps remotos descoberto

Operações em Lote

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

Status de Enforcement de Workloads

• get-workload-enforcement-status — Obtenha o status do modo de enforcement nas workloads, agrupado por app e ambiente. Mostra contagens por modo (idle, visibility_only, selective, full) e identifica apps com estados de enforcement mistos — um problema comum durante implantações.

Cobertura de Política

• get-policy-coverage-report — Gere um relatório de cobertura de política para um app mostrando qual tráfego é coberto por regras existentes versus o que seria bloqueado. Divide por entrada/saída, identifica serviços e apps remotos descobertos e fornece uma porcentagem geral de cobertura.
• find-unmanaged-traffic — Encontre tráfego envolvendo workloads não gerenciadas ou endereços IP. São fontes/destinos sem rótulos de app/ambiente, representando pontos cegos de política. Filtra por direção (entrada/saída/ambos) e contagem de conexões.

Análise de Segurança

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

Monitoramento de Eventos

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

Teste de Conexão

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

Testes

O projeto inclui uma suíte abrangente de testes de integração que roda 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 completo de CRUD para workloads, rótulos, listas de IPs, serviços, rulesets e regras de negação
• Consultas e resumos de fluxos de tráfego
• Criação de ringfence (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 por níveis)
• Tratamento de erros para recursos ausentes

Ordem de Processamento de Regras do Illumio

Entender o processamento de regras é essencial para ringfencing:

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

No enforcement seletivo, o padrão é permitir tudo, então uma regra de negação é necessária para tornar o ringfence eficaz. Apps 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 Aplicação

Visão detalhada dos padrões de comunicação e dependências da aplicação

Análise dos padrões de tráfego entre diferentes níveis de aplicação

Insights de Infraestrutura

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

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

Avaliação de Segurança

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

Descobertas de avaliação de segurança para vulnerabilidades de alto risco

Descobertas de avaliação de conformidade PCI

Descobertas de avaliação de conformidade SWIFT

Planejamento de Remediação

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

Etapas detalhadas para implementação da remediação de segurança

Gerenciamento de Políticas

Interface de gerenciamento para listas de IPs

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

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

Gerenciamento de Workloads

Análise detalhada de workloads e métricas

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

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 em padrões de tráfego

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

Planejamento de Projetos

Cronograma de implementação do projeto e marcos

Prompts Disponíveis

Ringfence de Aplicação

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

Argumentos obrigatórios:

• application_name: Nome da aplicação para fazer ringfence
• application_environment: Ambiente da aplicação para fazer ringfence

Recursos:

• Cria regras para comunicação entre níveis dentro da aplicação
• Usa fluxos de tráfego para identificar conexões externas necessárias
• Implementa restrições de tráfego de entrada com base nas aplicações 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 aplicações remotas

Analisar Tráfego de Aplicação

O prompt analyze-application-traffic fornece análise detalhada dos padrões de tráfego e conectividade da aplicação.

Argumentos obrigatórios:

• application_name: Nome da aplicação para analisar
• application_environment: Ambiente da aplicação para analisar

Recursos de análise:

• Ordena o tráfego por fluxos de entrada e saída
• Agrupa por combinações de aplicação/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 aplicação
• Determina exposição à internet
• Exibe rótulos de papel, aplicação e ambiente do Illumio

Como usar 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 Submit 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 compartilhamento automatizado de contexto entre sistemas Illumio e o Claude para análise de tráfego de aplicações e tarefas de ringfencing.

Docker

A aplicação está disponível como um contêiner Docker no GitHub Container Registry.

Baixe 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

Execute 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 (por exemplo, ~/tmp)
• Ajustar os caminhos de acordo com o seu sistema

Executar de Forma Independente

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

Em seguida, 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 obter detalhes.

Suporte

Para suporte, por favor crie uma issue.