Entity relationships
Entity relationships represent the connections between entities — for example, user-1 communicates_with host-1. The entity store stores these connections as a fixed set of relationship keys on each entity record, under the schema entity.relationships.<key>.ids. Relationships feed entity analytics views, including the entity graph in the entity details flyout. Relationships are populated only when the entity store is enabled and populated in the active space.
The relationship model is the foundation for representing how entities interact across your environment. A clear mapping between integrations, fields, and relationship keys helps you understand:
- Which fields a third-party integration must emit for its data to participate in a given relationship.
- Which relationships exist and how they are populated.
Entity relationships are produced by maintainers — background tasks that scan ingested events from supported integrations and write the result into the entity store.
Each maintainer scans a specific integration's index pattern for events that match an ES|QL filter, identifies an actor (a user) and a target (a user, host, or service), computes the target's entity unique identifier (EUID), and writes the relationship onto the actor entity record under entity.relationships.<key>.ids.
For an event to be picked up by a maintainer, it must meet the following conditions:
- Land in the integration's index pattern (
logs-<integration>-<namespace>). - Carry the actor identity field used by the maintainer (typically
user.name,user.email, or an integration-specific principal field). - Match the maintainer's ES|QL
WHEREclause for that integration. - Carry a resolvable target identity (for example,
host.id,host.target.entity.id, oruser.target.email).
The following sections describe each supported relationship key, the integrations that populate it, and the criteria an event must match. To populate a relationship, ingest events into one of the listed integration indices with the required actor and target identity fields.
These relationships are bucketed by event count over a 30-day window. A COUNT(*) >= 4 results in accesses_frequently; otherwise, the relationship is accesses_infrequently.
| Integration | Index pattern | Target type | ES|QL filter applied |
|---|---|---|---|
| Elastic Defend | logs-endpoint.events.security-<ns> |
host | event.action == "log_on" AND process.Ext.session_info.logon_type IN ("RemoteInteractive","Interactive","Network") AND event.outcome == "success" |
| AWS CloudTrail | logs-aws.cloudtrail-<ns> |
host | event.module == "aws" AND event.action IN ("StartSession","SendSSHPublicKey") AND event.outcome == "success" |
| System Auth | logs-system.auth-<ns> |
host | event.category IN ("authentication","session") AND event.action == "ssh_login" AND event.outcome == "success" |
| System Security | logs-system.security-<ns> |
host | event.action IN ("logged-in","logged-in-explicit") AND event.code IN ("4624","4648") AND winlog.logon.type IN ("Interactive","RemoteInteractive","CachedInteractive") AND event.outcome == "success" (excludes built-in system accounts) |
To populate entity.relationships.accesses_frequently.ids or entity.relationships.accesses_infrequently.ids for a user, ingest events into one of the supported integration indices with the actor identity (user.name or user.id) and a target host identity (host.id or host.name), and ensure they match the ES|QL filter.
This relationship captures when a user interacts with a target user or host — based on activity such as identity provider events, cloud API calls, and device management logs from the supported integrations.
| Integration | Index pattern | Target type | Actor field | Target field | ES|QL filter applied |
|---|---|---|---|---|---|
| Okta | logs-okta.system-<ns> |
user | user.name |
user.target.email (→ user:<email>@okta) |
event.action IN (<Okta user/group/app lifecycle actions>) AND user.target.email IS NOT NULL |
| Jamf Pro | logs-jamf_pro.events-<ns> |
host | user.name |
standard host EUID | user.name IS NOT NULL |
| AWS CloudTrail | logs-aws.cloudtrail-<ns> |
host | user.name |
host.target.entity.id (→ host:<id>) |
aws.cloudtrail.user_identity.type IN ("IAMUser","AssumedRole","Root","FederatedUser","IdentityCenterUser") AND host.target.entity.id IS NOT NULL |
| Azure Audit Logs | logs-azure.auditlogs-<ns> |
user / host | azure.auditlogs.properties.initiated_by.user.userPrincipalName (→ user:<upn>@entra_id) |
target_resources.0.user_principal_name (User) or target_resources.0.display_name (Device) |
actor UPN present AND target is a User with UPN or a Device with display name |
To populate entity.relationships.communicates_with.ids for a user, ingest events into one of the supported integration indices that match the filter and carry both actor and target identity fields.