Loading

Kolide Integration for Elastic
Version 0.1.1 (View all)
Subscription level
What's this?		 Basic
Developed by
What's this?		 Elastic
Ingestion method(s) API, AWS S3, Webhook
Minimum Kibana version(s) 9.1.0
8.19.0
The Kolide integration v0.1.1 is in technical preview

To use pre-release integrations, go to the Integrations page in Kibana, scroll down, and toggle on the Display beta integrations option.

The Kolide integration for Elastic collects device-trust and endpoint-compliance logs from Kolide (by 1Password). It ingests authentication sessions, posture issues, device inventory and trust-status changes, and administrative audit events, normalizes them to the Elastic Common Schema (ECS), and makes them available for search, visualization, and detection in Elastic.

This integration works with the current Kolide Device Trust platform ("Kolide K2") and its public REST API (version 2026-04-07) and webhooks. It does not cover the legacy open-source Kolide Fleet (osquery) product.

The integration supports three collection methods that you can choose between (and combine) when configuring it:

  • Webhooks (HTTP endpoint): Kolide pushes events in near real time to an HTTP endpoint exposed by the Elastic Agent. This is the recommended method for low-latency device-compliance data. Each delivery is signed with an HMAC-SHA256 signature for verification.
  • REST API (polling): the Elastic Agent periodically polls the Kolide REST API and collects new records using cursor-based pagination and a timestamp filter. This is useful for backfill and for fuller resource records.
  • AWS S3 (Kolide Log Pipeline): Kolide's Log Pipeline writes objects to a customer-owned S3 bucket under per-type key prefixes (defaults: kolide/auth_logs/, kolide/audit_logs/, kolide/check_runs/); the Elastic Agent reads each prefix with an aws-s3 input (SQS notifications or direct bucket polling). The auth and audit data streams can read their respective prefixes, and the dedicated device_check data stream reads kolide/check_runs/. S3 is the most complete source for check-run history — it includes passing, inapplicable, and unknown check results in addition to failures. Raw osquery results objects are not ingested.

The Kolide integration collects the following data streams:

  • webhook: single webhook ingress that receives all Kolide webhook event types on one endpoint and routes each event to the correct data stream automatically.
  • auth: SSO authentication sessions (auth_logs.success, auth_logs.failure; API GET /auth_logs).
  • issues: device posture-check failures and resolutions (issues.new, issues.resolved; API GET /issues).
  • device: device inventory and trust-status changes (devices.created, devices.registered, devices.destroyed, device_trust.status_changed; API GET /devices).
  • audit: administrative audit log of console actions (audit_log.recorded; API GET /audit_logs; Log Pipeline S3 kolide/audit_logs/).
  • device_check: device check-run results from the Log Pipeline (S3 kolide/check_runs/), covering every run — passing, failing, inapplicable, and unknown. This complements the failure-focused issues data stream.

The auth and audit data streams additionally support the Log Pipeline via an aws-s3 input that reads the kolide/auth_logs/ and kolide/audit_logs/ prefixes.

Note on event.outcome for posture data: For the device_check and issues data streams, event.outcome reflects the device posture result, not the success of event processing. A check run with status passing (or a resolved issue) maps to event.outcome: success, failing (or an open issue) maps to event.outcome: failure, and inapplicable or unknown check statuses map to event.outcome: unknown. The raw posture state is also preserved in kolide.device_check.status for device_check.

Note on host correlation for device_check: Check-run results identify the device only by its numeric Kolide device ID, mapped to host.id. The payload carries no hostname, so host.name is not set on this data stream. Correlate check runs with the device, auth, and issues data streams using the shared host.id. If you need host.name directly on check-run documents, enrich them at ingest time with an Elasticsearch enrich policy that maps host.id to host.name from the device data stream. This requires the device data stream to be enabled and the enrich policy to be executed and periodically refreshed so new or renamed devices resolve.

Monitoring device-trust posture, investigating SSO authentication outcomes alongside device compliance state, tracking device enrollment and blocking transitions, and auditing administrative changes in Kolide — all correlated with the rest of your security data in Elastic via ECS.

  • Elastic Agent installed on a host that can receive Kolide webhooks (a publicly reachable HTTPS endpoint), reach https://api.kolide.com, or read from your AWS S3 bucket or SQS queue.
  • A Kolide tenant with Full Access administrator privileges to create API keys, webhook endpoints, or Log Pipeline destinations.

Elastic Agent must be installed. For more details, check the Elastic Agent installation instructions. You can install only one Elastic Agent per host.

As a Full Access administrator, sign in to Kolide and choose one or more collection methods:

For webhooks:

  1. Go to Settings → Developers → Webhooks and add one new endpoint.
  2. Provide a publicly reachable HTTPS URL pointing at the Elastic Agent's listening address, port, and path (for example, https://<agent-host>:9550/kolide/webhook).
  3. Subscribe the endpoint to all event types — the integration routes each event to the correct data stream automatically.
  4. Copy the endpoint signing secret (shown once) — you will provide it to the integration as the HMAC key.

For the REST API:

  1. Go to Settings → Developers → API Keys and create a new key (read access is sufficient).
  2. Copy the API key (shown once); it has the form k2sk_v1_....

For the AWS S3 Log Pipeline:

  1. In Kolide, go to Log Destinations and add a new Amazon S3 Bucket destination.
  2. Choose STS (recommended): create an IAM role in your own AWS account whose trust policy allows Kolide's AWS account (516897320088) to assume it, gated by the External ID that Kolide displays. Grant the role s3:GetBucketLocation, s3:GetObject, and s3:PutObject on the bucket so Kolide can write logs.
  3. Select the log types to deliver (authentication logs, audit logs, and check results) and, optionally, customize the object key template.
  4. On the read side, the Elastic Agent uses your own AWS credentials (not Kolide's role). For SQS mode, configure an S3 event notification (s3:ObjectCreated:*) to an SQS queue and grant the reader s3:GetObject plus sqs:ReceiveMessage, sqs:DeleteMessage, and sqs:GetQueueAttributes. For direct polling, grant s3:GetObject and s3:ListBucket. Add kms:Decrypt if the bucket uses SSE-KMS.
Note

Kolide sends webhooks from dynamic AWS us-east-1 IP addresses, so IP allow-listing is not a reliable control — rely on the HMAC signature instead.

  1. In Kibana, go to Management → Integrations and search for Kolide.
  2. Add the integration.
  3. For webhooks: enable the webhook data stream (HTTP endpoint input). Set the listen address, port, and URL path, and provide the HMAC signing secret (and optionally the X-Kolide-Webhook-Identifier value). All Kolide event types are received on this single endpoint and routed automatically.
  4. For the REST API: enable whichever data streams you want to poll (auth, issues, device, audit), select the CEL input, provide the API URL (https://api.kolide.com), the API key, and adjust the polling interval and initial lookback as needed.
  5. For AWS S3 (Log Pipeline): provide your AWS credentials once on the integration, then enable the aws-s3 input on the data streams you want — auth, audit, or device_check. Each defaults to its Kolide prefix (kolide/auth_logs/, kolide/audit_logs/, kolide/check_runs/). For each, set either an SQS queue URL (SQS mode) or a bucket ARN (polling mode). In SQS mode, use a separate queue per prefix (filter S3 notifications by prefix); in polling mode each stream lists only its own prefix. Adjust the bucket list prefix if your Kolide destination uses a custom key template.

After setup, generate or wait for activity in Kolide (for example, sign in via SSO to produce an auth log). In Kibana, open Discover and confirm documents are arriving in the logs-kolide.* data streams.

  • No data via webhooks: Confirm the Kolide endpoint URL matches the Agent's listen address, port, and path, that the endpoint is publicly reachable over HTTPS, and that the HMAC signing secret matches.
  • Webhook signature failures: Ensure the configured HMAC key equals the Kolide endpoint signing secret; Kolide signs the raw request body with HMAC-SHA256 and sends the lowercase hex digest in the Authorization header with no prefix.
  • No data via the REST API: Verify the API key is valid (a 401 indicates a turned-off feature or bad token, and a 403 indicates the key lacks permission) and that the host can reach https://api.kolide.com.
  • No data via AWS S3: Confirm the Elastic Agent credentials can s3:ListBucket and s3:GetObject on the bucket (and sqs:ReceiveMessage in SQS mode), that the bucket list prefix matches your Kolide object key template, and that SQS notifications are filtered to the correct prefix. Kolide writes to kolide/auth_logs/, kolide/audit_logs/, and kolide/check_runs/ by default; osquery results/ objects are not ingested.

For more information on architectures that can be used for scaling this integration, check the Ingest Architectures documentation.

Kolide's Log Pipeline writes one log per S3 object rather than batching, so the AWS S3/SQS input makes a separate fetch for every document. For high-volume streams this is fine, but for small, sparse streams it adds many network round-trips and can make large backlogs slow to drain. To keep latency low and avoid contention on a shared S3 queue, consider matching the transport to the stream:

  • audit and auth: prefer the REST API (CEL) or webhook inputs. These streams are typically small and sparse, and the API/webhook paths deliver them quickly without per-object S3 fetches.
  • device_check (check runs): use the AWS S3 input. This stream is large, so S3 is the better fit, and keeping it on S3 keeps the small, important streams off the same queue.

This split keeps the small streams responsive while still using S3 for the bulk data.

If you do consume large streams over S3/SQS, you can increase throughput by running multiple Elastic Agents (or scaling out workers) so SQS messages are processed concurrently. Note the one-object-per-log behavior is a Kolide-side limitation. The guidance above is a workaround until it is addressed upstream.

These inputs can be used with this integration:

aws-s3

Set up an Amazon S3 To create an Amazon S3 bucket, follow these steps.

  • You can set the parameter "Bucket List Prefix" according to the requirement.

  • AWS S3 polling mode: Writes data to S3, and Elastic Agent polls the S3 bucket by listing its contents and reading new files.

  • AWS S3 SQS mode: Writes data to S3; S3 sends a notification of a new object to SQS; the Elastic Agent receives the notification from SQS and then reads the S3 object. Multiple agents can be used in this mode.

When log collection from an S3 bucket is enabled, you can access logs from S3 objects referenced by S3 notification events received through an SQS queue or by directly polling the list of S3 objects within the bucket.

The use of SQS notification is preferred: polling list of S3 objects is expensive in terms of performance and costs and should be used only when no SQS notification can be attached to the S3 buckets. This input integration also supports S3 notification from SNS to SQS, or from EventBridge to SQS.

To enable the SQS notification method, set the queue_url configuration value. To enable the S3 bucket list polling method, configure both the bucket_arn and number_of_workers values. Note that queue_url and bucket_arn cannot be set simultaneously, and at least one of these values must be specified. The number_of_workers parameter is the primary way to control ingestion throughput for both S3 polling and SQS modes. This parameter determines how many parallel workers process S3 objects simultaneously.

Note

To access SQS and S3, these specific AWS permissions are required.

To collect logs via AWS S3, configure the following parameters:

  • Collect logs via S3 Bucket toggled on
  • Access Key ID
  • Secret Access Key
  • Bucket ARN or Access Point ARN
  • Session Token

Alternatively, to collect logs via AWS SQS, configure the following parameters:

  • Collect logs via S3 Bucket toggled off
  • Queue URL
  • Secret Access Key
  • Access Key ID
  • Session Token
cel

For more details about the CEL input settings, check the Filebeat documentation.

Before configuring the CEL input, make sure you have:

  • Network connectivity to the target API endpoint
  • Valid authentication credentials (API keys, tokens, or certificates as required)
  • Appropriate permissions to read from the target data source

To configure the CEL input, you must specify the request.url value pointing to the API endpoint. The interval parameter controls how frequently requests are made and is the primary way to balance data freshness with API rate limits and costs. Authentication is often configured through the request.headers section using the appropriate method for the service.

Note

To access the API service, make sure you have the necessary API credentials and that the Filebeat instance can reach the endpoint URL. Some services may require IP whitelisting or VPN access.

To collect logs via API endpoint, configure the following parameters:

  • API Endpoint URL
  • API credentials (tokens, keys, or username/password)
  • Request interval (how often to fetch data)
http_endpoint

For more details about the Http endpoint input settings, check the Filebeat documentation.

To collect logs via Http Endpoint, select Collect logs via Http Endpoint and configure the following parameters:

  • Listen Address: Bind address for the HTTP listener. Use 0.0.0.0 to listen on all interfaces.
  • Listen port: Bind port for the listener.

These Kolide REST API endpoints are used by this integration:

  • GET /auth_logs
  • GET /issues
  • GET /devices
  • GET /audit_logs

The webhook data stream is the single ingress point for all Kolide webhook events. It listens on one HTTP endpoint and uses the ingest reroute processor to redirect each event to the appropriate target data stream (auth, issues, device, or audit) based on the Kolide event type. No documents are stored in the webhook data stream itself.

Exported fields
Field Description Type
@timestamp Event timestamp. date
data_stream.dataset Data stream dataset. constant_keyword
data_stream.namespace Data stream namespace. constant_keyword
data_stream.type Data stream type. constant_keyword
ecs.version ECS version this event conforms to. ecs.version is a required field and must exist in all events. When querying across multiple indices -- which may conform to slightly different ECS versions -- this field lets integrations adjust to the schema version of the events. keyword
error.message Error message. match_only_text
event.dataset Event dataset. constant_keyword
event.kind This is one of four ECS Categorization Fields, and indicates the highest level in the ECS category hierarchy. event.kind gives high-level information about what type of information the event contains, without being specific to the contents of the event. For example, values of this field distinguish alert events from metric events. The value of this field can be used to inform how these kinds of events should be handled. They may warrant different retention, different access control, it may also help understand whether the data is coming in at a regular interval or not. keyword
event.module Event module. constant_keyword
input.type Type of filebeat input. keyword
json Working object used to hold the raw Kolide webhook envelope fields before the event is routed to the appropriate data stream. Contains event (event type string), id (ULID), timestamp, and data (event payload). Cleaned up by the target data stream pipeline after routing. flattened
log.offset Log offset. long
tags List of keywords used to tag each event. keyword

The auth data stream provides Kolide SSO authentication sessions, including the device-trust posture at sign-in, the client IP and geolocation, and the sub-events of the session.

Exported fields
Field Description Type
@timestamp Event timestamp. date
aws.s3.bucket.arn The AWS S3 bucket ARN. keyword
aws.s3.bucket.name The AWS S3 bucket name. keyword
aws.s3.object.key The AWS S3 object key. keyword
data_stream.dataset Data stream dataset. constant_keyword
data_stream.namespace Data stream namespace. constant_keyword
data_stream.type Data stream type. constant_keyword
ecs.version ECS version this event conforms to. ecs.version is a required field and must exist in all events. When querying across multiple indices -- which may conform to slightly different ECS versions -- this field lets integrations adjust to the schema version of the events. keyword
error.message Error message. match_only_text
event.action The action captured by the event. This describes the information in the event. It is more specific than event.category. Examples are group-add, process-started, file-created. The value is normally defined by the implementer. keyword
event.category This is one of four ECS Categorization Fields, and indicates the second level in the ECS category hierarchy. event.category represents the "big buckets" of ECS categories. For example, filtering on event.category:process yields all events relating to process activity. This field is closely related to event.type, which is used as a subcategory. This field is an array. This will allow proper categorization of some events that fall in multiple categories. keyword
event.dataset Event dataset. constant_keyword
event.id Unique ID to describe the event. keyword
event.kind This is one of four ECS Categorization Fields, and indicates the highest level in the ECS category hierarchy. event.kind gives high-level information about what type of information the event contains, without being specific to the contents of the event. For example, values of this field distinguish alert events from metric events. The value of this field can be used to inform how these kinds of events should be handled. They may warrant different retention, different access control, it may also help understand whether the data is coming in at a regular interval or not. keyword
event.module Event module. constant_keyword
event.original Raw text message of entire event. Used to demonstrate log integrity or where the full log message (before splitting it up in multiple parts) may be required, e.g. for reindex. This field is not indexed and doc_values are disabled. It cannot be searched, but it can be retrieved from _source. If users wish to override this and index this field, please see Field data types in the Elasticsearch Reference. keyword
event.outcome This is one of four ECS Categorization Fields, and indicates the lowest level in the ECS category hierarchy. event.outcome simply denotes whether the event represents a success or a failure from the perspective of the entity that produced the event. Note that when a single transaction is described in multiple events, each event may populate different values of event.outcome, according to their perspective. Also note that in the case of a compound event (a single event that contains multiple logical events), this field should be populated with the value that best captures the overall success or failure from the perspective of the event producer. Further note that not all events will have an associated outcome. For example, this field is generally not populated for metric events, events with event.type:info, or any events for which an outcome does not make logical sense. keyword
event.start event.start contains the date when the event started or when the activity was first observed. date
event.type This is one of four ECS Categorization Fields, and indicates the third level in the ECS category hierarchy. event.type represents a categorization "sub-bucket" that, when used along with the event.category field values, enables filtering events down to a level appropriate for single visualization. This field is an array. This will allow proper categorization of some events that fall in multiple event types. keyword
host.hostname Hostname of the host. It normally contains what the hostname command returns on the host machine. keyword
host.id Unique host id. As hostname is not always unique, use values that are meaningful in your environment. Example: The current usage of beat.name. keyword
host.name Name of the host. It can contain what hostname returns on Unix systems, the fully qualified domain name (FQDN), or a name specified by the user. The recommended value is the lowercase FQDN of the host. keyword
input.type Type of filebeat input. keyword
kolide.auth.agent_version Version of the Kolide agent (launcher) reported during the session. From API agent_version or webhook launcher_version. keyword
kolide.auth.downloaded_packages Names of packages downloaded to the device during the authentication session. keyword
kolide.auth.initial_status Device trust posture at the start of the session. One of: all_good, will_block, blocked, unknown. keyword
kolide.auth.issues_displayed.blocking_status Blocking status of the issue. One of: blocked, will_block. keyword
kolide.auth.issues_displayed.id Canonical identifier of the displayed issue. keyword
kolide.auth.issues_displayed.link API URL of the issue. keyword
kolide.auth.issues_displayed.title Short description of the displayed issue. keyword
kolide.auth.okta.app_instance_id Okta app instance identifier from the SAML request. keyword
kolide.auth.okta.app_name Okta app name from the SAML request. keyword
kolide.auth.result Outcome of the authentication as reported by the API. One of: Success, Fail. keyword
kolide.auth.session_id Identifier of the authentication session. Shared across all sub-events split from the same session so they can be correlated. From the API/webhook record id. keyword
kolide.auth.url API URL of the full auth_log record (webhook only). keyword
log.offset Log offset. long
message For log events the message field contains the log message, optimized for viewing in a log viewer. For structured logs without an original message field, other fields can be concatenated to form a human-readable summary of the event. If multiple messages exist, they can be combined into one message. match_only_text
related.hosts All hostnames or other host identifiers seen on your event. Example identifiers include FQDNs, domain names, workstation names, or aliases. keyword
related.ip All of the IPs seen on your event. ip
related.user All the user names or other user identifiers seen on the event. keyword
source.as.number Unique number allocated to the autonomous system. The autonomous system number (ASN) uniquely identifies each network on the Internet. long
source.as.organization.name Organization name. keyword
source.as.organization.name.text Multi-field of source.as.organization.name. match_only_text
source.geo.city_name City name. keyword
source.geo.continent_name Name of the continent. keyword
source.geo.country_iso_code Country ISO code. keyword
source.geo.country_name Country name. keyword
source.geo.location.lat Longitude and latitude. geo_point
source.geo.location.lon Longitude and latitude. geo_point
source.geo.region_iso_code Region ISO code. keyword
source.geo.region_name Region name. keyword
source.ip IP address of the source (IPv4 or IPv6). ip
tags List of keywords used to tag each event. keyword
user.email User email address. keyword
user.id Unique identifier of the user. keyword
user.name Short name or login of the user. keyword
user.name.text Multi-field of user.name. match_only_text
user_agent.device.name Name of the device. keyword
user_agent.name Name of the user agent. keyword
user_agent.original Unparsed user_agent string. keyword
user_agent.original.text Multi-field of user_agent.original. match_only_text
user_agent.os.full Operating system name, including the version or code name. keyword
user_agent.os.full.text Multi-field of user_agent.os.full. match_only_text
user_agent.os.name Operating system name, without the version. keyword
user_agent.os.name.text Multi-field of user_agent.os.name. match_only_text
user_agent.os.version Operating system version as a raw string. keyword
user_agent.version Version of the user agent. keyword
Example 
{
    "@timestamp": "2024-03-11T21:28:17.000Z",
    "agent": {
        "ephemeral_id": "a7e8f0c3-3f3c-4df1-a711-dca5f997077c",
        "id": "d9df3829-c2e0-4721-8242-1cf13796bbc4",
        "name": "elastic-agent-47734",
        "type": "filebeat",
        "version": "9.4.1"
    },
    "data_stream": {
        "dataset": "kolide.auth",
        "namespace": "93060",
        "type": "logs"
    },
    "ecs": {
        "version": "9.3.0"
    },
    "elastic_agent": {
        "id": "d9df3829-c2e0-4721-8242-1cf13796bbc4",
        "snapshot": false,
        "version": "9.4.1"
    },
    "event": {
        "action": "sign_in_attempt",
        "agent_id_status": "verified",
        "category": [
            "authentication",
            "session"
        ],
        "dataset": "kolide.auth",
        "id": "3374648:sign_in_attempt:2024-03-11T21:28:17Z",
        "ingested": "2026-06-17T18:36:02Z",
        "kind": "event",
        "module": "kolide",
        "original": "{\"agent_version\":\"1.4.0\",\"browser_name\":\"Chrome\",\"browser_user_agent\":\"Mozilla/5.0 (Macintosh; Intel Mac OS X 10_15_7) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/122.0.0.0 Safari/537.36\",\"city\":\"New York\",\"country\":\"United States\",\"device_info\":{\"identifier\":\"1\",\"link\":\"https://api.example.com/devices/1\"},\"events\":[{\"event_description\":\"The end-user was redirected to Kolide via a valid SAML request\",\"event_type\":\"sign_in_attempt\",\"timestamp\":\"2024-03-11T21:28:17Z\"},{\"event_description\":\"The end-user clicked Continue to Sign In\",\"event_type\":\"sign_in_success\",\"timestamp\":\"2024-03-11T21:28:19Z\"}],\"id\":\"3374648\",\"initial_status\":\"all_good\",\"ip_address\":\"198.51.100.23\",\"issues_displayed\":[{\"blocking_status\":\"will_block\",\"id\":\"9999\",\"link\":\"https://api.example.com/issues/9999\",\"title\":\"macOS Firewall is Disabled\"}],\"okta_app_instance_id\":\"0oa1example2instance3\",\"okta_app_name\":\"Example Corp SSO\",\"person_email\":\"user@example.com\",\"person_info\":{\"identifier\":\"3\",\"link\":\"https://api.example.com/people/3\"},\"person_name\":\"Alice Johnson\",\"result\":\"Success\",\"session_timestamp\":\"2024-03-11T21:28:17Z\",\"sub_event_description\":\"The end-user was redirected to Kolide via a valid SAML request\",\"sub_event_type\":\"sign_in_attempt\",\"timestamp\":\"2024-03-11T21:28:17Z\"}",
        "outcome": "success",
        "start": "2024-03-11T21:28:17.000Z",
        "type": [
            "start",
            "info"
        ]
    },
    "host": {
        "id": "1"
    },
    "input": {
        "type": "cel"
    },
    "kolide": {
        "auth": {
            "agent_version": "1.4.0",
            "initial_status": "all_good",
            "issues_displayed": [
                {
                    "blocking_status": "will_block",
                    "id": "9999",
                    "link": "https://api.example.com/issues/9999",
                    "title": "macOS Firewall is Disabled"
                }
            ],
            "okta": {
                "app_instance_id": "0oa1example2instance3",
                "app_name": "Example Corp SSO"
            },
            "result": "Success",
            "session_id": "3374648"
        }
    },
    "message": "The end-user was redirected to Kolide via a valid SAML request",
    "related": {
        "ip": [
            "198.51.100.23"
        ],
        "user": [
            "Alice Johnson",
            "user@example.com"
        ]
    },
    "source": {
        "as": {
            "number": 64501,
            "organization": {
                "name": "Documentation ASN"
            }
        },
        "geo": {
            "city_name": "Amsterdam",
            "continent_name": "Europe",
            "country_iso_code": "NL",
            "country_name": "Netherlands",
            "location": {
                "lat": 52.37403995823115,
                "lon": 4.889689916744828
            },
            "region_iso_code": "NL-NH",
            "region_name": "North Holland"
        },
        "ip": "198.51.100.23"
    },
    "tags": [
        "preserve_original_event",
        "forwarded",
        "kolide-auth"
    ],
    "user": {
        "email": "user@example.com",
        "id": "3",
        "name": "Alice Johnson"
    },
    "user_agent": {
        "device": {
            "name": "Mac"
        },
        "name": "Chrome",
        "original": "Mozilla/5.0 (Macintosh; Intel Mac OS X 10_15_7) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/122.0.0.0 Safari/537.36",
        "os": {
            "full": "Mac OS X 10.15.7",
            "name": "Mac OS X",
            "version": "10.15.7"
        },
        "version": "122.0.0.0"
    }
}

The issues data stream provides Kolide posture-check failures and resolutions for devices.

Exported fields
Field Description Type
@timestamp Event timestamp. date
data_stream.dataset Data stream dataset. constant_keyword
data_stream.namespace Data stream namespace. constant_keyword
data_stream.type Data stream type. constant_keyword
ecs.version ECS version this event conforms to. ecs.version is a required field and must exist in all events. When querying across multiple indices -- which may conform to slightly different ECS versions -- this field lets integrations adjust to the schema version of the events. keyword
error.message Error message. match_only_text
event.action The action captured by the event. This describes the information in the event. It is more specific than event.category. Examples are group-add, process-started, file-created. The value is normally defined by the implementer. keyword
event.category This is one of four ECS Categorization Fields, and indicates the second level in the ECS category hierarchy. event.category represents the "big buckets" of ECS categories. For example, filtering on event.category:process yields all events relating to process activity. This field is closely related to event.type, which is used as a subcategory. This field is an array. This will allow proper categorization of some events that fall in multiple categories. keyword
event.dataset Event dataset. constant_keyword
event.end event.end contains the date when the event ended or when the activity was last observed. date
event.id Unique ID to describe the event. keyword
event.kind This is one of four ECS Categorization Fields, and indicates the highest level in the ECS category hierarchy. event.kind gives high-level information about what type of information the event contains, without being specific to the contents of the event. For example, values of this field distinguish alert events from metric events. The value of this field can be used to inform how these kinds of events should be handled. They may warrant different retention, different access control, it may also help understand whether the data is coming in at a regular interval or not. keyword
event.module Event module. constant_keyword
event.original Raw text message of entire event. Used to demonstrate log integrity or where the full log message (before splitting it up in multiple parts) may be required, e.g. for reindex. This field is not indexed and doc_values are disabled. It cannot be searched, but it can be retrieved from _source. If users wish to override this and index this field, please see Field data types in the Elasticsearch Reference. keyword
event.outcome This is one of four ECS Categorization Fields, and indicates the lowest level in the ECS category hierarchy. event.outcome simply denotes whether the event represents a success or a failure from the perspective of the entity that produced the event. Note that when a single transaction is described in multiple events, each event may populate different values of event.outcome, according to their perspective. Also note that in the case of a compound event (a single event that contains multiple logical events), this field should be populated with the value that best captures the overall success or failure from the perspective of the event producer. Further note that not all events will have an associated outcome. For example, this field is generally not populated for metric events, events with event.type:info, or any events for which an outcome does not make logical sense. keyword
event.start event.start contains the date when the event started or when the activity was first observed. date
event.type This is one of four ECS Categorization Fields, and indicates the third level in the ECS category hierarchy. event.type represents a categorization "sub-bucket" that, when used along with the event.category field values, enables filtering events down to a level appropriate for single visualization. This field is an array. This will allow proper categorization of some events that fall in multiple event types. keyword
file.device Device that is the source of the file. keyword
file.hash.md5 MD5 hash. keyword
file.hash.sha256 SHA256 hash. keyword
file.path Full path to the file, including the file name. It should include the drive letter, when appropriate. keyword
file.path.text Multi-field of file.path. match_only_text
host.hostname Hostname of the host. It normally contains what the hostname command returns on the host machine. keyword
host.id Unique host id. As hostname is not always unique, use values that are meaningful in your environment. Example: The current usage of beat.name. keyword
host.name Name of the host. It can contain what hostname returns on Unix systems, the fully qualified domain name (FQDN), or a name specified by the user. The recommended value is the lowercase FQDN of the host. keyword
input.type Type of filebeat input. keyword
kolide.issues.blocks_device_at Timestamp at which the issue will begin blocking the device (API only). date
kolide.issues.check.id Identifier of the failing check (webhook check_id). keyword
kolide.issues.check.tags Tags associated with the check (webhook only). keyword
kolide.issues.check_information.link API URL of the check record. keyword
kolide.issues.detected_at Timestamp at which the issue was first detected (API only). date
kolide.issues.detected_version Version of the software detected on the device (for example, Chrome, OS). keyword
kolide.issues.device_information.link API URL of the device record. keyword
kolide.issues.exempted Whether the issue has been exempted from blocking the device (API only). boolean
kolide.issues.expected_version Minimum or newest version required for compliance. keyword
kolide.issues.id Canonical identifier of the issue. From API id or webhook issue_id. keyword
kolide.issues.issue_key The key that identifies what kind of issue this is, for example bundle_id (API only). keyword
kolide.issues.issue_value The value associated with the issue key, for example the offending bundle identifier (API only). keyword
kolide.issues.last_rechecked_at Timestamp at which the issue was last rechecked (API only). date
kolide.issues.resolved_at Timestamp at which the issue was resolved, if any (API only). date
kolide.issues.ssh_key_type SSH key algorithm type (for example, ssh-ed25519, ssh-rsa). keyword
kolide.issues.title Short human-readable description of the issue. Can be null on issues.new webhooks. keyword
kolide.issues.value Structured details about why the device failed the check; the shape varies by check (API only). flattened
log.offset Log offset. long
message For log events the message field contains the log message, optimized for viewing in a log viewer. For structured logs without an original message field, other fields can be concatenated to form a human-readable summary of the event. If multiple messages exist, they can be combined into one message. match_only_text
package.version Package version keyword
related.hosts All hostnames or other host identifiers seen on your event. Example identifiers include FQDNs, domain names, workstation names, or aliases. keyword
related.user All the user names or other user identifiers seen on the event. keyword
rule.category A categorization value keyword used by the entity using the rule for detection of this event. keyword
rule.id A rule ID that is unique within the scope of an agent, observer, or other entity using the rule for detection of this event. keyword
rule.name The name of the rule or signature generating the event. keyword
rule.reference Reference URL to additional information about the rule used to generate this event. The URL can point to the vendor's documentation about the rule. If that's not available, it can also be a link to a more general page describing this type of alert. keyword
tags List of keywords used to tag each event. keyword
user.name Short name or login of the user. keyword
user.name.text Multi-field of user.name. match_only_text
Example 
{
    "@timestamp": "2023-10-28T20:50:15.000Z",
    "agent": {
        "ephemeral_id": "7429995a-4016-41dc-9ca9-92589f75758b",
        "id": "583c03ad-a4d1-45e8-b155-49c05bac1c14",
        "name": "elastic-agent-31084",
        "type": "filebeat",
        "version": "8.19.0"
    },
    "data_stream": {
        "dataset": "kolide.issues",
        "namespace": "94759",
        "type": "logs"
    },
    "ecs": {
        "version": "9.4.0"
    },
    "elastic_agent": {
        "id": "583c03ad-a4d1-45e8-b155-49c05bac1c14",
        "snapshot": false,
        "version": "8.19.0"
    },
    "event": {
        "action": "issue",
        "agent_id_status": "verified",
        "category": [
            "configuration"
        ],
        "dataset": "kolide.issues",
        "id": "9999",
        "ingested": "2026-06-26T19:47:03Z",
        "kind": "event",
        "original": "{\"blocks_device_at\":\"2023-11-04T20:50:15Z\",\"check_information\":{\"identifier\":\"71\",\"link\":\"https://api.example.com/checks/71\"},\"detected_at\":\"2023-10-28T20:50:15Z\",\"device_information\":{\"identifier\":\"1\",\"link\":\"https://api.example.com/devices/1\"},\"exempted\":false,\"id\":\"9999\",\"issue_key\":\"bundle_id\",\"issue_value\":\"com.example.app\",\"last_rechecked_at\":\"2023-10-28T21:00:58Z\",\"resolved_at\":null,\"title\":\"macOS Firewall is Disabled\",\"value\":{\"firewall_enabled\":false}}",
        "outcome": "failure",
        "start": "2023-10-28T20:50:15.000Z",
        "type": [
            "creation"
        ]
    },
    "host": {
        "id": "1"
    },
    "input": {
        "type": "cel"
    },
    "kolide": {
        "issues": {
            "blocks_device_at": "2023-11-04T20:50:15.000Z",
            "check_information": {
                "link": "https://api.example.com/checks/71"
            },
            "detected_at": "2023-10-28T20:50:15.000Z",
            "device_information": {
                "link": "https://api.example.com/devices/1"
            },
            "exempted": false,
            "id": "9999",
            "issue_key": "bundle_id",
            "issue_value": "com.example.app",
            "last_rechecked_at": "2023-10-28T21:00:58.000Z",
            "title": "macOS Firewall is Disabled",
            "value": {
                "firewall_enabled": false
            }
        }
    },
    "message": "macOS Firewall is Disabled",
    "rule": {
        "id": "71",
        "name": "macOS Firewall is Disabled",
        "reference": "https://api.example.com/checks/71"
    },
    "tags": [
        "preserve_original_event",
        "forwarded",
        "kolide-issues"
    ]
}

The device data stream provides Kolide device inventory records and device-trust status changes.

Exported fields
Field Description Type
@timestamp Event timestamp. date
data_stream.dataset Data stream dataset. constant_keyword
data_stream.namespace Data stream namespace. constant_keyword
data_stream.type Data stream type. constant_keyword
ecs.version ECS version this event conforms to. ecs.version is a required field and must exist in all events. When querying across multiple indices -- which may conform to slightly different ECS versions -- this field lets integrations adjust to the schema version of the events. keyword
error.message Error message. match_only_text
event.action The action captured by the event. This describes the information in the event. It is more specific than event.category. Examples are group-add, process-started, file-created. The value is normally defined by the implementer. keyword
event.category This is one of four ECS Categorization Fields, and indicates the second level in the ECS category hierarchy. event.category represents the "big buckets" of ECS categories. For example, filtering on event.category:process yields all events relating to process activity. This field is closely related to event.type, which is used as a subcategory. This field is an array. This will allow proper categorization of some events that fall in multiple categories. keyword
event.dataset Event dataset. constant_keyword
event.id Unique ID to describe the event. keyword
event.kind This is one of four ECS Categorization Fields, and indicates the highest level in the ECS category hierarchy. event.kind gives high-level information about what type of information the event contains, without being specific to the contents of the event. For example, values of this field distinguish alert events from metric events. The value of this field can be used to inform how these kinds of events should be handled. They may warrant different retention, different access control, it may also help understand whether the data is coming in at a regular interval or not. keyword
event.module Event module. constant_keyword
event.original Raw text message of entire event. Used to demonstrate log integrity or where the full log message (before splitting it up in multiple parts) may be required, e.g. for reindex. This field is not indexed and doc_values are disabled. It cannot be searched, but it can be retrieved from _source. If users wish to override this and index this field, please see Field data types in the Elasticsearch Reference. keyword
event.outcome This is one of four ECS Categorization Fields, and indicates the lowest level in the ECS category hierarchy. event.outcome simply denotes whether the event represents a success or a failure from the perspective of the entity that produced the event. Note that when a single transaction is described in multiple events, each event may populate different values of event.outcome, according to their perspective. Also note that in the case of a compound event (a single event that contains multiple logical events), this field should be populated with the value that best captures the overall success or failure from the perspective of the event producer. Further note that not all events will have an associated outcome. For example, this field is generally not populated for metric events, events with event.type:info, or any events for which an outcome does not make logical sense. keyword
event.start event.start contains the date when the event started or when the activity was first observed. date
event.type This is one of four ECS Categorization Fields, and indicates the third level in the ECS category hierarchy. event.type represents a categorization "sub-bucket" that, when used along with the event.category field values, enables filtering events down to a level appropriate for single visualization. This field is an array. This will allow proper categorization of some events that fall in multiple event types. keyword
host.hostname Hostname of the host. It normally contains what the hostname command returns on the host machine. keyword
host.id Unique host id. As hostname is not always unique, use values that are meaningful in your environment. Example: The current usage of beat.name. keyword
host.name Name of the host. It can contain what hostname returns on Unix systems, the fully qualified domain name (FQDN), or a name specified by the user. The recommended value is the lowercase FQDN of the host. keyword
host.os.full Operating system name, including the version or code name. keyword
host.os.full.text Multi-field of host.os.full. match_only_text
host.os.name Operating system name, without the version. keyword
host.os.name.text Multi-field of host.os.name. match_only_text
host.os.platform Operating system platform (such centos, ubuntu, windows). keyword
host.os.type Use the os.type field to categorize the operating system into one of the broad commercial families. If the OS you're dealing with is not listed as an expected value, the field should not be populated. Please let us know by opening an issue with ECS, to propose its addition. keyword
host.os.version Operating system version as a raw string. keyword
host.type Type of host. For Cloud providers this can be the machine type like t2.medium. If vm, this could be the container, for example, or other information meaningful in your environment. keyword
input.type Type of filebeat input. keyword
kolide.device.auth_configuration.authentication_mode Authentication mode, for example only_registered_owner or any_registered_person. keyword
kolide.device.auth_configuration.device_id Identifier of the device the configuration applies to. keyword
kolide.device.auth_configuration.person_groups Person groups permitted to authenticate the device. flattened
kolide.device.auth_state Raw authentication state of the device reported by the API, for example Good or Blocked (API only). keyword
kolide.device.device_status Raw device status reported by the device_trust.status_changed webhook, for example blocked (webhook only). keyword
kolide.device.device_url API URL of the device record (webhook only). keyword
kolide.device.form_factor Form factor of the device, for example Computer. keyword
kolide.device.hardware_model Hardware model identifier, for example MacBookPro18,1. keyword
kolide.device.hardware_uuid Hardware UUID of the device. keyword
kolide.device.last_authenticated_at Timestamp at which the device last authenticated. date
kolide.device.last_seen_at Timestamp at which the device was last seen. date
kolide.device.note Free-form note associated with the device. text
kolide.device.product_image_url URL of the product image for the device hardware. keyword
kolide.device.registered_at Timestamp at which the device was registered. date
kolide.device.registered_owner_info.identifier Identifier of the registered owner. keyword
kolide.device.registered_owner_info.location API URL of the registered owner resource. keyword
kolide.device.serial Hardware serial number of the device. keyword
kolide.device.status Normalized (lowercase) device status, derived from the webhook device_status or the API auth_state. keyword
kolide.device.type Type of device, one of Mac, Linux, Windows, iOS, or Android. keyword
kolide.device.will_block_at Timestamp at which the device will be blocked, if any. date
log.offset Log offset. long
related.hosts All hostnames or other host identifiers seen on your event. Example identifiers include FQDNs, domain names, workstation names, or aliases. keyword
related.user All the user names or other user identifiers seen on the event. keyword
tags List of keywords used to tag each event. keyword
user.email User email address. keyword
user.id Unique identifier of the user. keyword
user.name Short name or login of the user. keyword
user.name.text Multi-field of user.name. match_only_text
Example 
{
    "@timestamp": "2026-06-26T19:45:06.028069753Z",
    "agent": {
        "ephemeral_id": "cd0d58a1-1d21-45e2-accf-77d9d46080b3",
        "id": "c5bb2007-c7a7-44cb-a399-4679caac8c22",
        "name": "elastic-agent-37867",
        "type": "filebeat",
        "version": "8.19.0"
    },
    "data_stream": {
        "dataset": "kolide.device",
        "namespace": "47456",
        "type": "logs"
    },
    "ecs": {
        "version": "9.4.0"
    },
    "elastic_agent": {
        "id": "c5bb2007-c7a7-44cb-a399-4679caac8c22",
        "snapshot": false,
        "version": "8.19.0"
    },
    "event": {
        "action": "device",
        "agent_id_status": "verified",
        "category": [
            "host"
        ],
        "dataset": "kolide.device",
        "ingested": "2026-06-26T19:45:06Z",
        "kind": "state",
        "original": "{\"auth_configuration\":{\"authentication_mode\":\"only_registered_owner\",\"device_id\":\"1\",\"person_groups\":[]},\"auth_state\":\"Good\",\"device_type\":\"Mac\",\"form_factor\":\"Computer\",\"hardware_model\":\"MacBookPro18,1\",\"hardware_uuid\":\"00000000-0000-0000-0000-000000000000\",\"id\":\"1\",\"last_authenticated_at\":\"2024-03-11T21:28:17Z\",\"last_seen_at\":\"2024-03-11T21:30:00Z\",\"name\":\"Alices-MacBook-Pro\",\"note\":\"Loaner device\",\"operating_system\":\"macOS 14.4.1\",\"product_image_url\":\"https://example.com/images/macbookpro.png\",\"registered_at\":\"2023-10-28T20:12:14Z\",\"registered_owner_info\":{\"identifier\":\"1\",\"link\":\"https://api.example.com/people/1\"},\"serial\":\"C02EXAMPLE123\",\"will_block_at\":null}",
        "start": "2023-10-28T20:12:14.000Z",
        "type": [
            "info"
        ]
    },
    "host": {
        "hostname": "Alices-MacBook-Pro",
        "id": "1",
        "name": "Alices-MacBook-Pro",
        "os": {
            "full": "macOS 14.4.1",
            "name": "macOS",
            "platform": "mac",
            "type": "macos",
            "version": "14.4.1"
        },
        "type": "desktop"
    },
    "input": {
        "type": "cel"
    },
    "kolide": {
        "device": {
            "auth_configuration": {
                "authentication_mode": "only_registered_owner",
                "device_id": "1"
            },
            "auth_state": "Good",
            "form_factor": "Computer",
            "hardware_model": "MacBookPro18,1",
            "hardware_uuid": "00000000-0000-0000-0000-000000000000",
            "last_authenticated_at": "2024-03-11T21:28:17.000Z",
            "last_seen_at": "2024-03-11T21:30:00.000Z",
            "note": "Loaner device",
            "product_image_url": "https://example.com/images/macbookpro.png",
            "registered_at": "2023-10-28T20:12:14.000Z",
            "registered_owner_info": {
                "identifier": "1",
                "location": "https://api.example.com/people/1"
            },
            "serial": "C02EXAMPLE123",
            "status": "good",
            "type": "Mac"
        }
    },
    "related": {
        "hosts": [
            "Alices-MacBook-Pro"
        ]
    },
    "tags": [
        "preserve_original_event",
        "forwarded",
        "kolide-device"
    ],
    "user": {
        "id": "1"
    }
}

The audit data stream provides the Kolide administrative audit log of console actions.

Exported fields
Field Description Type
@timestamp Event timestamp. date
aws.s3.bucket.arn The AWS S3 bucket ARN. keyword
aws.s3.bucket.name The AWS S3 bucket name. keyword
aws.s3.object.key The AWS S3 object key. keyword
data_stream.dataset Data stream dataset. constant_keyword
data_stream.namespace Data stream namespace. constant_keyword
data_stream.type Data stream type. constant_keyword
ecs.version ECS version this event conforms to. ecs.version is a required field and must exist in all events. When querying across multiple indices -- which may conform to slightly different ECS versions -- this field lets integrations adjust to the schema version of the events. keyword
error.message Error message. match_only_text
event.action The action captured by the event. This describes the information in the event. It is more specific than event.category. Examples are group-add, process-started, file-created. The value is normally defined by the implementer. keyword
event.category This is one of four ECS Categorization Fields, and indicates the second level in the ECS category hierarchy. event.category represents the "big buckets" of ECS categories. For example, filtering on event.category:process yields all events relating to process activity. This field is closely related to event.type, which is used as a subcategory. This field is an array. This will allow proper categorization of some events that fall in multiple categories. keyword
event.dataset Event dataset. constant_keyword
event.id Unique ID to describe the event. keyword
event.kind This is one of four ECS Categorization Fields, and indicates the highest level in the ECS category hierarchy. event.kind gives high-level information about what type of information the event contains, without being specific to the contents of the event. For example, values of this field distinguish alert events from metric events. The value of this field can be used to inform how these kinds of events should be handled. They may warrant different retention, different access control, it may also help understand whether the data is coming in at a regular interval or not. keyword
event.module Event module. constant_keyword
event.original Raw text message of entire event. Used to demonstrate log integrity or where the full log message (before splitting it up in multiple parts) may be required, e.g. for reindex. This field is not indexed and doc_values are disabled. It cannot be searched, but it can be retrieved from _source. If users wish to override this and index this field, please see Field data types in the Elasticsearch Reference. keyword
event.outcome This is one of four ECS Categorization Fields, and indicates the lowest level in the ECS category hierarchy. event.outcome simply denotes whether the event represents a success or a failure from the perspective of the entity that produced the event. Note that when a single transaction is described in multiple events, each event may populate different values of event.outcome, according to their perspective. Also note that in the case of a compound event (a single event that contains multiple logical events), this field should be populated with the value that best captures the overall success or failure from the perspective of the event producer. Further note that not all events will have an associated outcome. For example, this field is generally not populated for metric events, events with event.type:info, or any events for which an outcome does not make logical sense. keyword
event.type This is one of four ECS Categorization Fields, and indicates the third level in the ECS category hierarchy. event.type represents a categorization "sub-bucket" that, when used along with the event.category field values, enables filtering events down to a level appropriate for single visualization. This field is an array. This will allow proper categorization of some events that fall in multiple event types. keyword
host.hostname Hostname of the host. It normally contains what the hostname command returns on the host machine. keyword
host.name Name of the host. It can contain what hostname returns on Unix systems, the fully qualified domain name (FQDN), or a name specified by the user. The recommended value is the lowercase FQDN of the host. keyword
input.type Type of filebeat input. keyword
kolide.audit.actor_automated True when the action was performed by a non-human actor (actor_type is ApiKey or System); false for human actors. Useful for filtering automated activity. boolean
kolide.audit.actor_type Type of actor that performed the audited action, one of User, ApiKey, or System. keyword
kolide.audit.change.field Name of the setting that was changed. keyword
kolide.audit.change.from Previous value of the setting. keyword
kolide.audit.change.groups_from Previous set of allowed groups for a device registration auth mode change. keyword
kolide.audit.change.groups_to New set of allowed groups for a device registration auth mode change. keyword
kolide.audit.change.to New value of the setting. keyword
kolide.audit.expires_at Expiry date for an exemption, as a human-readable string from the audit log. keyword
kolide.audit.reason Human-provided reason for an exemption, approval, or denial. keyword
kolide.audit.target.api_key_name Name or label of the API key that was revealed or created. keyword
kolide.audit.target.app_name Name of the managed web application affected by the action. keyword
kolide.audit.target.campaign_id Identifier of the live query campaign affected by the action. keyword
kolide.audit.target.check_names Names of the checks set as required for device registration. keyword
kolide.audit.target.config_type Type of the configuration that was updated. keyword
kolide.audit.target.count Count of members or people associated with the audited object. long
kolide.audit.target.destination_name Name of the log pipeline destination affected by the action. keyword
kolide.audit.target.destination_type Type of the log pipeline destination (for example Amazon S3, Splunk HEC). keyword
kolide.audit.target.device_id Numeric identifier of the device affected by the action. keyword
kolide.audit.target.device_serial Serial number of the device affected by the action. keyword
kolide.audit.target.feature Name of the feature whose restriction was changed for a user. keyword
kolide.audit.target.fim_category Name of the osquery FIM (file integrity monitoring) category affected by the action. keyword
kolide.audit.target.group_name Name of the device group affected by the action. keyword
kolide.audit.target.idp_url URL or hostname of the identity provider. keyword
kolide.audit.target.issue_id Numeric identifier of the issue affected by the action. keyword
kolide.audit.target.logger_name Name of the device property logger added or removed. keyword
kolide.audit.target.okta_event Name of the Okta event hook received (for example saml_idp_factor_setup). keyword
kolide.audit.target.org_id Numeric identifier of the organization. keyword
kolide.audit.target.org_name Display name of the organization. keyword
kolide.audit.target.osquery_name Name of the osquery decorator affected by the action. keyword
kolide.audit.target.pack_name Name of the osquery pack affected by the action. keyword
kolide.audit.target.platform Device platform referenced by a device registration configuration change (for example macOS, Windows). keyword
kolide.audit.target.prev_status Previous status of a reopened device registration or exemption request (for example denied or approved). keyword
kolide.audit.target.provider_name Name of the device management provider. keyword
kolide.audit.target.query_name Name of the osquery discovery or pack query affected by the action. keyword
kolide.audit.target.tables Osquery tables referenced by a live query campaign. keyword
kolide.audit.target.webhook_url URL of the webhook affected by a developer webhook action. keyword
log.offset Log offset. long
message For log events the message field contains the log message, optimized for viewing in a log viewer. For structured logs without an original message field, other fields can be concatenated to form a human-readable summary of the event. If multiple messages exist, they can be combined into one message. match_only_text
related.hosts All hostnames or other host identifiers seen on your event. Example identifiers include FQDNs, domain names, workstation names, or aliases. keyword
related.ip All of the IPs seen on your event. ip
related.user All the user names or other user identifiers seen on the event. keyword
rule.name The name of the rule or signature generating the event. keyword
source.as.number Unique number allocated to the autonomous system. The autonomous system number (ASN) uniquely identifies each network on the Internet. long
source.as.organization.name Organization name. keyword
source.as.organization.name.text Multi-field of source.as.organization.name. match_only_text
source.geo.city_name City name. keyword
source.geo.continent_name Name of the continent. keyword
source.geo.country_iso_code Country ISO code. keyword
source.geo.country_name Country name. keyword
source.geo.location.lat Longitude and latitude. geo_point
source.geo.location.lon Longitude and latitude. geo_point
source.geo.region_iso_code Region ISO code. keyword
source.geo.region_name Region name. keyword
source.ip IP address of the source (IPv4 or IPv6). ip
tags List of keywords used to tag each event. keyword
url.domain Domain of the url, such as "www.elastic.co". In some cases a URL may refer to an IP and/or port directly, without a domain name. In this case, the IP address would go to the domain field. If the URL contains a literal IPv6 address enclosed by [ and ] (IETF RFC 2732), the [ and ] characters should also be captured in the domain field. keyword
user.email User email address. keyword
user.name Short name or login of the user. keyword
user.name.text Multi-field of user.name. match_only_text
user.target.email User email address. keyword
user.target.name Short name or login of the user. keyword
user.target.name.text Multi-field of user.target.name. match_only_text
Example 
{
    "@timestamp": "2024-03-11T21:28:17.000Z",
    "agent": {
        "ephemeral_id": "f734b99d-fd67-4981-bb45-59ca1024a4bf",
        "id": "ce1af407-b9ee-42ff-9448-8cd015c5ac91",
        "name": "elastic-agent-94474",
        "type": "filebeat",
        "version": "9.4.1"
    },
    "data_stream": {
        "dataset": "kolide.audit",
        "namespace": "14195",
        "type": "logs"
    },
    "ecs": {
        "version": "9.3.0"
    },
    "elastic_agent": {
        "id": "ce1af407-b9ee-42ff-9448-8cd015c5ac91",
        "snapshot": false,
        "version": "9.4.1"
    },
    "event": {
        "action": "audit_log",
        "agent_id_status": "verified",
        "category": [
            "iam",
            "configuration"
        ],
        "dataset": "kolide.audit",
        "id": "01JA67B1DYJCKJ1J73T0F5EWGR",
        "ingested": "2026-06-17T18:35:10Z",
        "kind": "event",
        "module": "kolide",
        "original": "{\"actor_info\":{\"actor_email\":\"alice@example.com\",\"actor_name\":\"Alice Johnson\",\"actor_type\":\"User\"},\"actor_name\":\"Alice Johnson\",\"description\":\"Enabled check 'iTerm2 - Require Secure Keyboard Entry to Be Enabled'\",\"id\":\"01JA67B1DYJCKJ1J73T0F5EWGR\",\"timestamp\":\"2024-03-11T21:28:17Z\"}",
        "type": [
            "change"
        ]
    },
    "input": {
        "type": "cel"
    },
    "kolide": {
        "audit": {
            "actor_type": "User"
        }
    },
    "message": "Enabled check 'iTerm2 - Require Secure Keyboard Entry to Be Enabled'",
    "related": {
        "user": [
            "Alice Johnson",
            "alice@example.com"
        ]
    },
    "rule": {
        "name": "iTerm2 - Require Secure Keyboard Entry to Be Enabled"
    },
    "tags": [
        "preserve_original_event",
        "forwarded",
        "kolide-audit"
    ],
    "user": {
        "email": "alice@example.com",
        "name": "Alice Johnson"
    }
}

The device_check data stream provides Kolide device check-run results delivered through the Log Pipeline (S3). Unlike the issues data stream, which tracks the failure lifecycle, this stream records every check run — passing, failing, inapplicable, and unknown.

Exported fields
Field Description Type
@timestamp Event timestamp. date
aws.s3.bucket.arn The AWS S3 bucket ARN. keyword
aws.s3.bucket.name The AWS S3 bucket name. keyword
aws.s3.object.key The AWS S3 object key. keyword
data_stream.dataset Data stream dataset. constant_keyword
data_stream.namespace Data stream namespace. constant_keyword
data_stream.type Data stream type. constant_keyword
ecs.version ECS version this event conforms to. ecs.version is a required field and must exist in all events. When querying across multiple indices -- which may conform to slightly different ECS versions -- this field lets integrations adjust to the schema version of the events. keyword
error.message Error message. match_only_text
event.action The action captured by the event. This describes the information in the event. It is more specific than event.category. Examples are group-add, process-started, file-created. The value is normally defined by the implementer. keyword
event.category This is one of four ECS Categorization Fields, and indicates the second level in the ECS category hierarchy. event.category represents the "big buckets" of ECS categories. For example, filtering on event.category:process yields all events relating to process activity. This field is closely related to event.type, which is used as a subcategory. This field is an array. This will allow proper categorization of some events that fall in multiple categories. keyword
event.dataset Event dataset. constant_keyword
event.id Unique ID to describe the event. keyword
event.kind This is one of four ECS Categorization Fields, and indicates the highest level in the ECS category hierarchy. event.kind gives high-level information about what type of information the event contains, without being specific to the contents of the event. For example, values of this field distinguish alert events from metric events. The value of this field can be used to inform how these kinds of events should be handled. They may warrant different retention, different access control, it may also help understand whether the data is coming in at a regular interval or not. keyword
event.module Event module. constant_keyword
event.original Raw text message of entire event. Used to demonstrate log integrity or where the full log message (before splitting it up in multiple parts) may be required, e.g. for reindex. This field is not indexed and doc_values are disabled. It cannot be searched, but it can be retrieved from _source. If users wish to override this and index this field, please see Field data types in the Elasticsearch Reference. keyword
event.outcome This is one of four ECS Categorization Fields, and indicates the lowest level in the ECS category hierarchy. event.outcome simply denotes whether the event represents a success or a failure from the perspective of the entity that produced the event. Note that when a single transaction is described in multiple events, each event may populate different values of event.outcome, according to their perspective. Also note that in the case of a compound event (a single event that contains multiple logical events), this field should be populated with the value that best captures the overall success or failure from the perspective of the event producer. Further note that not all events will have an associated outcome. For example, this field is generally not populated for metric events, events with event.type:info, or any events for which an outcome does not make logical sense. keyword
event.type This is one of four ECS Categorization Fields, and indicates the third level in the ECS category hierarchy. event.type represents a categorization "sub-bucket" that, when used along with the event.category field values, enables filtering events down to a level appropriate for single visualization. This field is an array. This will allow proper categorization of some events that fall in multiple event types. keyword
host.id Unique host id. As hostname is not always unique, use values that are meaningful in your environment. Example: The current usage of beat.name. keyword
input.type Type of filebeat input. keyword
kolide.device_check.check_id Numeric identifier of the check that was run. long
kolide.device_check.check_result_data The per-check result rows produced by the run. The shape varies by check, so the array is stored as a flattened field rather than mapping each key. flattened
kolide.device_check.check_slug Slug identifying the check, for example unencrypted or macos_remote_login. keyword
kolide.device_check.device_id Numeric identifier of the device the check was run against. long
kolide.device_check.status Outcome of the check run. One of passing, failing, inapplicable, or unknown. keyword
log.offset Log offset. long
related.hosts All hostnames or other host identifiers seen on your event. Example identifiers include FQDNs, domain names, workstation names, or aliases. keyword
rule.id A rule ID that is unique within the scope of an agent, observer, or other entity using the rule for detection of this event. keyword
rule.name The name of the rule or signature generating the event. keyword
tags List of keywords used to tag each event. keyword
Example 
{
    "@timestamp": "2026-06-02T15:45:01.000Z",
    "agent": {
        "ephemeral_id": "b2c4d6e8-f0a1-4b3c-8d7e-9f0a1b2c3d4e",
        "id": "a1b2c3d4-e5f6-7890-abcd-ef1234567890",
        "name": "elastic-agent-12345",
        "type": "filebeat",
        "version": "9.4.1"
    },
    "data_stream": {
        "dataset": "kolide.device_check",
        "namespace": "48291",
        "type": "logs"
    },
    "ecs": {
        "version": "9.3.0"
    },
    "elastic_agent": {
        "id": "a1b2c3d4-e5f6-7890-abcd-ef1234567890",
        "snapshot": false,
        "version": "9.4.1"
    },
    "event": {
        "action": "check_result",
        "agent_id_status": "verified",
        "category": [
            "host"
        ],
        "dataset": "kolide.device_check",
        "id": "7386319-10-2026-06-02T15:45:01.000Z",
        "ingested": "2026-06-17T18:40:00Z",
        "kind": "state",
        "module": "kolide",
        "original": "{\"type\":\"check_result\",\"timestamp\":\"2026-06-02T15:45:01Z\",\"data\":{\"check_id\":10,\"check_slug\":\"macos_file_sharing\",\"device_id\":7386319,\"status\":\"passing\",\"check_result_data\":[{\"file_sharing\":\"0\",\"current_os_version\":\"26.4.1\",\"KOLIDE_CHECK_STATUS\":\"PASS\"}]}}",
        "outcome": "success",
        "type": [
            "info"
        ]
    },
    "host": {
        "id": "7386319"
    },
    "input": {
        "type": "aws-s3"
    },
    "kolide": {
        "device_check": {
            "check_id": 10,
            "check_result_data": [
                {
                    "KOLIDE_CHECK_STATUS": "PASS",
                    "current_os_version": "26.4.1",
                    "file_sharing": "0"
                }
            ],
            "check_slug": "macos_file_sharing",
            "device_id": 7386319,
            "status": "passing"
        }
    },
    "rule": {
        "id": "10",
        "name": "macos_file_sharing"
    },
    "tags": [
        "preserve_original_event",
        "forwarded",
        "kolide-device-check-s3"
    ]
}

This integration includes one or more Kibana dashboards that visualizes the data collected by the integration. The screenshots below illustrate how the ingested data is displayed.

Kolide Overview
Changelog
Version Details Minimum Kibana version
0.1.1 Bug fix (View pull request)
Fix the cursor handling for the audit, auth and issues data streams.		 9.1.0
8.19.0
0.1.0 Enhancement (View pull request)
Initial release of the Kolide integration.		 9.1.0
8.19.0