Enterprise Features

13.1 Enterprise Container

The enterprise Docker image is built from the --target enterprise stage of the multi-stage Dockerfile. It adds the enterprise/ package which provides secrets injection, OIDC authentication, structured audit logging, and APM auto-instrumentation — none of which affect the standard image.

docker build --target enterprise -t meshoptixiq:enterprise .

At container start, the entrypoint (enterprise/entrypoint.py) resolves secrets from the configured provider, then execvpes uvicorn with the resolved environment — no secrets are stored on disk.

13.2 OIDC Single Sign-On

Enterprise OIDC SSO delegates authentication to your identity provider (Okta, Azure AD, Google Workspace, Keycloak, etc.).

AUTH_MODE=oidc          # api_key | oidc | both
OIDC_ISSUER=https://login.microsoftonline.com/<tenant-id>/v2.0
OIDC_CLIENT_ID=<app-registration-client-id>
OIDC_CLIENT_SECRET=<secret>
OIDC_SCOPES=openid profile email groups

When AUTH_MODE=both, the API accepts either an X-API-Key header or a Bearer JWT in the Authorization header. JWKS keys are cached for one hour and refreshed automatically on key-ID mismatch.

13.3 Audit Logging Backends

Enterprise Supported audit sinks:

13.4 Observability & APM

Enterprise The enterprise entrypoint auto-detects APM agents at startup:

1. If DD_AGENT_HOST is set → Datadog ddtrace agent.
2. Else if NEW_RELIC_LICENSE_KEY is set → New Relic APM.
3. Else if OTEL_EXPORTER_OTLP_ENDPOINT is set → OpenTelemetry OTLP exporter.

Traces cover every inbound HTTP request and outbound Neo4j / PostgreSQL query, with span attributes for query name, plan tier, and device count.

13.5 Secrets Provider Integration

Enterprise Set SECRETS_PROVIDER to pull secrets at startup. The provider must return a JSON object mapping environment variable names to their values.

13.6 RBAC Policy Configuration

Pro+ Role-Based Access Control restricts which queries each user or group may execute. The policy is defined in a YAML file referenced by RBAC_POLICY_FILE, or supplied inline via RBAC_POLICY. If neither is set, all authenticated users have full access.

Policy file format

# /etc/meshoptixiq/rbac.yaml
roles:
  admin:
    allow:
      - "*"

  architect:
    allow:
      - "topology_*"
      - "blast_radius_*"
      - "path_analysis"
      - "all_devices"
      - "update_device_metadata"

  network:
    allow:
      - "topology_*"
      - "ips_in_subnet"
      - "locate_endpoint_by_ip"
      - "all_devices"
      - "devices_*"
      - "interfaces_*"

  security:
    allow:
      - "firewall_*"
      - "path_analysis"
      - "deny_rules_summary"
      - "blast_radius_*"

  analyst:
    allow:
      - "summary_*"
      - "all_devices"
      - "hygiene_*"
      - "devices_*"

  helpdesk:
    allow:
      - "locate_endpoint_by_ip"
      - "ips_in_subnet"
      - "device_neighbors"

groups:
  "network-ops-team":   network
  "security-analysts":  security
  "noc-helpdesk":       helpdesk

Pattern matching uses Python fnmatch glob syntax. A user whose OIDC groups claim matches a group entry is assigned the corresponding role. In API key mode, the resolved role is always admin.

Environment variables

Hot reload

The API polls the policy file's modification time every RBAC_RELOAD_INTERVAL seconds. In a multi-pod deployment, broadcast the reload signal via Redis:

curl -X POST http://localhost:8000/admin/rbac/reload \
  -H "X-API-Key: $MESHOPTIXIQ_API_KEY"

This resets the local policy cache and publishes a message to the meshq:rbac_reload Redis channel. All other pods subscribed to that channel will reload their policy within one polling interval.

13.7 SOAR Webhook Rules

Enterprise SOAR integration fires a webhook after audit events that match user-defined conditions. This allows external SOAR platforms (Splunk SOAR, Palo Alto XSOAR, Cortex, custom runbooks) to react to network topology queries in real time.

Configuration

SOAR_WEBHOOK_URL=https://soar.corp.example.com/api/webhooks/meshoptixiq
SOAR_WEBHOOK_TOKEN=<bearer-token>
SOAR_RULES='[
  {"name":"high-blast-radius","query":"blast_radius_*","condition":"row_count > 50"},
  {"name":"firewall-query-spike","query":"firewall_*","condition":"elapsed_ms > 5000"},
  {"name":"server-error","query":"*","condition":"status >= 500"}
]'

Rule schema

Webhook payload

{
  "rule": "high-blast-radius",
  "query": "blast_radius_from_device",
  "user": "admin",
  "timestamp": "2026-03-04T09:15:22Z",
  "elapsed_ms": 312,
  "row_count": 87,
  "status": 200,
  "params": {"hostname": "core-sw-01"}
}

The webhook is dispatched asynchronously after the API response is returned so it does not add latency to the query. Failed webhooks are logged at WARNING level and retried once after 5 seconds.

13.8 NetBox Sync Workflow

Pro+ Bidirectional synchronisation between MeshOptixIQ's graph and a NetBox IPAM/DCIM instance lets you enrich discovered devices with site, tenant, rack, and role metadata (pull), and write back discovered addresses and neighbours (push).

Configuration

NETBOX_URL=https://netbox.corp.example.com
NETBOX_TOKEN=<api-token>
NETBOX_SYNC_DIRECTION=both     # push | pull | both

Install the integrations extra: pip install 'meshoptixiq-network-discovery[integrations]' (adds httpx).

Sync directions

Running a sync

# Dry run — preview changes without writing
meshq sync --target netbox --direction pull --dry-run

# Live sync
meshq sync --target netbox --direction both

Alternatively, trigger via the API:

curl -X POST http://localhost:8000/admin/netbox/sync \
  -H "X-API-Key: $MESHOPTIXIQ_API_KEY" \
  -H "Content-Type: application/json" \
  -d '{"direction":"pull","dry_run":false}'

13.9 AI Reliability Engineering

Enterprise MeshOptixIQ Enterprise adds a suite of AI/GPU infrastructure observability and resilience features: eBPF kernel-level telemetry, NVLink + NCCL topology analysis, token-path tracing, chaos simulation, and a vendor-agnostic natural language query interface. See Chapter 14 for full configuration and API reference.

Refer to Chapter 14 for full configuration and API reference.