---
title: Kolide Integration for Elastic
description: The Kolide integration for Elastic collects device-trust and endpoint-compliance logs from Kolide (by 1Password). It ingests authentication sessions,...
url: https://docs-v3-preview.elastic.dev/elastic/integration-docs/tree/main/reference/kolide
products:
- Elastic integrations
applies_to:
- Serverless Observability projects: Preview
- Serverless Security projects: Preview
- Elastic Stack: Preview since 9.1
---
# Kolide Integration for Elastic
| | |
|-------------------------------------------------------------------------------------------------------------------------------|-------------------------------------------------------------------|
| **Version** | 0.1.2 : Preview ([View all](#changelog)) |
| **Subscription level**[What's this?](https://www.elastic.co/subscriptions) | Basic |
| **Developed by**[What's this?](https://docs-v3-preview.elastic.dev/elastic/integration-docs/tree/main/reference/developed-by) | Elastic |
| **Ingestion method(s)** | API, AWS S3, Webhook |
| **Minimum Kibana version(s)** | 9.1.08.19.0 |
To use pre-release integrations, go to the **Integrations** page in Kibana, scroll down, and toggle on the _Display beta integrations_ option.
## Overview
The Kolide integration for Elastic collects device-trust and endpoint-compliance logs from [Kolide](https://www.kolide.com/) (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.
### Compatibility
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.
### How it works
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.
## What data does this integration collect?
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](https://www.elastic.co/docs/manage-data/ingest/transform-enrich/data-enrichment) 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.
### Supported use cases
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.
## What do I need to use this integration?
- 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.
## How do I deploy this integration?
### Agent-based deployment
Elastic Agent must be installed. For more details, check the Elastic Agent [installation instructions](https://www.elastic.co/guide/en/fleet/current/elastic-agent-installation.html). You can install only one Elastic Agent per host.
### Set up steps in Kolide
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://: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.
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.
#### Vendor resources
- [Kolide Webhooks documentation](https://www.kolide.com/docs/developers/webhooks)
- [Kolide REST API reference](https://kolideapi.readme.io/reference)
- [Kolide Log Pipeline documentation](https://www.kolide.com/docs/admins/log-pipeline/overview)
### Set up steps in Kibana
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.
### Validation
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.
## Troubleshooting
- 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.
## Performance and scaling
For more information on architectures that can be used for scaling this integration, check the [Ingest Architectures](https://www.elastic.co/docs/manage-data/ingest/ingest-reference-architectures) documentation.
### Choosing a transport per data stream
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.
## Reference
### Inputs used
These inputs can be used with this integration:
## SetupSet up an Amazon S3
To create an Amazon S3 bucket, follow [these steps](https://docs.aws.amazon.com/AmazonS3/latest/userguide/create-bucket-overview.html).
- 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.
### Collecting logs from S3 bucketWhen 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.
To access SQS and S3, these [specific AWS permissions](https://www.elastic.co/guide/en/beats/filebeat/current/filebeat-input-aws-s3.html#_aws_permissions_2) 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
## SetupFor more details about the CEL input settings, check the [Filebeat documentation](https://www.elastic.co/guide/en/beats/filebeat/current/filebeat-input-cel.html).
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
### Collecting logs from CELTo 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.
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)
## SetupFor more details about the HTTP Endpoint input settings, check the [Filebeat documentation](https://www.elastic.co/docs/reference/beats/filebeat/filebeat-input-http_endpoint).
### Collecting logs from HTTP EndpointTo 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.
### API usage
These Kolide REST API endpoints are used by this integration:
- `GET /auth_logs`
- `GET /issues`
- `GET /devices`
- `GET /audit_logs`
### Vendor documentation links
- [Kolide documentation](https://www.kolide.com/docs)
- [Kolide Webhooks](https://www.kolide.com/docs/developers/webhooks)
- [Kolide REST API reference](https://kolideapi.readme.io/reference)
- [Kolide Log Pipeline](https://www.kolide.com/docs/admins/log-pipeline/overview)
### Data streams
#### webhook
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.
##### webhook 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 |
#### auth
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.
##### auth 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 |
##### auth sample event
```json
{
"@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"
}
}
```
#### issues
The `issues` data stream provides Kolide posture-check failures and resolutions for devices.
##### issues 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 |
##### issues sample event
```json
{
"@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"
]
}
```
#### device
The `device` data stream provides Kolide device inventory records and device-trust status changes.
##### device 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 |
##### device sample event
```json
{
"@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"
}
}
```
#### audit
The `audit` data stream provides the Kolide administrative audit log of console actions.
##### audit 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](http://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 |
##### audit sample event
```json
{
"@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"
}
}
```
#### device_check
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`.
##### device_check 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 |
##### device_check sample event
```json
{
"@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"
]
}
```
### Data streams using ILM policies
## Screenshots
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.
## Changelog
| Version | Details | Minimum Kibana version |
|-----------|-----------------------------------------------------------------------------------------------------------------------------------------------------------|------------------------|
| **0.1.2** | **Bug fix** ([View pull request](https://github.com/elastic/integrations/pull/19960))Standardize HTTP Endpoint capitalization in README file | 9.1.08.19.0 |
| **0.1.1** | **Bug fix** ([View pull request](https://github.com/elastic/integrations/pull/19890))Fix the cursor handling for the audit, auth and issues data streams. | 9.1.08.19.0 |
| **0.1.0** | **Enhancement** ([View pull request](https://github.com/elastic/integrations/pull/19806))Initial release of the Kolide integration. | 9.1.08.19.0 |