Use Fleet label membership as a filter within osquery queries and policies

[kitzy]

• Gong snippet: https://us-65885.app.gong.io/call?id=4915634408966772027&highlights=%5B%7B%22type%22%3A%22SHARE%22%2C%22from%22%3A1121%2C%22to%22%3A1297%7D%5D

Interpretation

How do you interpret the customer's words?
The customer wants to write a single osquery policy that combines Fleet-managed data (label membership, host vitals like group or IdP attributes) with live device telemetry. Their specific use case is scoping compliance checks or software enforcement to hosts that are both members of a particular Fleet label and satisfy a telemetry condition — without having to maintain a separate label for every possible combination of criteria.

What's Fleet missing?
Today, Fleet labels and host vitals (e.g., IdP-assigned group, department, "added to Fleet" timestamp) live in Fleet's database and are used to target policies — but they are not exposed as queryable tables within osquery SQL itself. An IT admin cannot write SQL that references a host's Fleet label membership or IdP group membership inside a policy query. The only workaround is to pre-create a dedicated label that encodes both criteria in a single dynamic query, which becomes unwieldy at scale.

What does the customer's ideal workflow look like?

1. IT admin writes a policy with SQL that references both device telemetry (e.g., installed app version, CPU architecture) and Fleet-managed metadata (e.g., label membership or an IdP-assigned host vital).
2. Fleet evaluates the policy only against hosts where both conditions are true — without the admin needing to create a separate intersection label first.
3. The result is a cleaner, more maintainable policy library where scoping logic lives inside the policy SQL rather than requiring upstream label management.