aertunmanual

Connectors, log sources and feeds

Read other tools through their APIs, map their logs, and take what they push.

In the consoleFeeds

Connectors

A connector reads one tool through its API, over only the endpoints its manifest declares, with a credential sealed under aertun's keyring. With no keyring, no credential can be stored.

aertun vault enable
aertun connect catalogue
aertun connect add okta --org example
aertun connect check okta
AERTUN_CONNECT_SECRET=... aertun connect secret okta
aertun connect run okta --save

A region is chosen from the connector's own list, never typed as a hostname, so adding a connector cannot point a credential at another machine. The catalogue says which credential each needs and the least it should be allowed to do.

Shipped connectors: Okta, Microsoft Entra ID, GitHub, EVM smart contracts through a Blockscout explorer, KnowBe4, ManageEngine Endpoint Central, ManageEngine MDM Plus and Vanta. aertun connect probe shows the shape of a response, never its values.

Collection

aertun collect run
aertun collect file aws/cloudtrail trail.json
aertun collect auto 15m

Logs are mapped to one shape from AWS CloudTrail, Microsoft Entra ID, Microsoft Azure, Google Workspace, Google Cloud, Okta, Duo, CrowdStrike Falcon, Jamf Pro, GitHub, Kubernetes, Cloudflare, Salesforce, Slack, Snowflake, Linux auditd and EVM chains. aertun source add adds a mapping of your own, checked against a sample, and aertun telemetry check says whether what it produces can be used at all.

Feeds pushed to aertun

aertun inbound add ssf corp-idp
aertun inbound add okta okta-hooks
aertun inbound add webhook ci
aertun inbound status NAME

A feed's endpoint is /feeds/NAME on the console. Shared Signals (SSF, CAEP, RISC) are verified against the transmitter's keys; webhooks against their secret. What arrives is stored like anything collected, and put to the automations as a signal.