Armis Integration
ServiceRadar ingests Armis device intelligence to enrich inventory, surface unmanaged assets, and drive risk-based alerting. The integration runs through the Sync service and optionally uses the Faker generator for demos.
Prerequisites
- Armis API client credentials with read access to your tenant.
- A dedicated Sync worker or Kubernetes deployment with outbound connectivity to the Armis API.
- KV entries for API keys and pagination cursors; see the KV configuration guide for secure storage tips.
Enabling the Integration
-
Populate the Sync config with the Armis connector block:
{
"integrations": {
"armis": {
"api_url": "https://<tenant>.armis.com/api/v1",
"client_id": "${kv:secrets/armis/client_id}",
"client_secret": "${kv:secrets/armis/client_secret}",
"page_size": 500
}
}
} -
Deploy or restart the
serviceradar-sync
workload. Watchkubectl logs
forarmis_sync
messages confirming pagination progress. -
Confirm imported devices in the registry via
srql
:
in:devices source:armis sort:risk_score:desc limit:20
.
Demo and Testing
- The Armis Faker synthesizes data sets for local or CI demos. Mount the
serviceradar-faker-data
PVC to persist generated inventories. - Resetting Faker? Follow the Agents runbook to truncate Proton tables and replay canonical devices.
Alerting and Enrichment
- Sync attaches Armis risk scores and device tags; combine them with SNMP status to prioritize outages.
- Use the Service Port Map to overlay Armis risk data on topology diagrams.
- Export curated Armis datasets to third-party tools through the MCP integration.
Troubleshooting
- Authentication failures usually mean expired client secrets—rotate them in KV and redeploy Sync.
- Large tenants may hit rate limits; tune
page_size
and enable incremental sync by storing thelast_seen
cursor. - For ingestion gaps, consult the Troubleshooting Guide and cross-check Faker vs. production statistics.