Show tags on `crowdstrike_falcon` table (or on another new related table)

[iansltx]

This would spit out the output of falconctl -g --tags on Linux, either comma-separated for multiple tags or maybe a new table with rows for each tag rather than forcing crowdstrike_falcon to have multiple rows for this one attribute.

Posting here because this is probably a better spot to add this work vs. the falconctl_options table that Fleet maintains (see fleetdm/fleet#32239), given that that table uses the old Kolide-style API that exposes some rather thorny implementation details ("is not set" being returned as column values). So instead of breaking BC with that table on our side, maybe we can add compat here and point folks to the new table here for a cleaner querying experience.

If folks like the idea/agree on a design one way or the other (@jc0b?), I can probably do the impl work.

[jc0b]

Sorry for the slowness on getting around to reading this. I feel like having a row per tag is fine in the table (kind of like the plist table already does for subkeys within a key), just because you can then do exact searches for stuff like "get me all the serials that have this tag set" (instead of using % or other matching strategies to grab them from a comma separated list).

That being said, parity between macOS and Linux would be preferred, and you can't get tags from falconctl info on macOS afaik, so you'd have to build another exec call to go and get that on macOS.

[iansltx]

Got it. Maybe a new table then? falconctl runs quickly enough that even if someone needed to join this info it's not massive overhead to do so.

[jc0b]

If you're ok to return a row per tag then I'm happy to roll it into this table. I can look at the macOS side (and do some testing next week) if that's easier for you. If we agree on the new columns then I'm happy to help make this table more feature rich :)

[iansltx]

Hm, if you're up for sketching out the shape of the table in the form of the macOS work, I can follow along on the Linux side, and honestly I feel a little more comfortable following an existing pattern in this case. That also probably lines up with availability on my side, as this is probably something I'd next have a window for late next week.

[jc0b]

Hey, i've had to kick this back a bit as I'm busy (both at work and at home) in the run up to the winter break. I'm also not in a position at the moment to see what the grouping tag output looks like on the Mac side, although I'll see if this is something I can fix. Will let you know.

I'm also wondering whether it does make sense to do a row per-tag, or whether this would be confusing to admins. On the one had, I think it's easier to craft a query to get machines with a specific tag, but on the other hand it means you may get multiple results per-machine for something like SELECT agent_id FROM crowdstrike_falcon;, unless you're thinking to also use GROUP BY agent_id (which might not be so intuitive).

[iansltx]

Yep, the multiple rows per machine in an aggregation use case felt like an API break to me in a way that just adding a column wouldn't be. On the other hand, forcing someone to string-split multiple tags is a pain (this is what we do with our fleetd-bundled table FWIW). So this kind of comes back to the question of whether tacking tags onto the existing table is helpful on balance to folks using this. Maybe not.