Filter OS by platforms

[RachelElysia]

Goal

User story
As a vuln engineer,
I want to filter operating systems by platform
so that I can check which macOS/Windows/Linux/ChromeOS/iPadOS/iOS hosts have vulnerabilities.

Context

• Requestor(s): @RachelElysia
• Product designer: @randy-fleet

Changes

Product

• UI changes: Figma
• API changes: No API changes, GET /api/v1/fleet/os_versions already has platform param.
• CLI (fleetctl) usage changes: No changes
• YAML changes: No changes
• Fleet's agent (fleetd) changes: No changes
• Activity changes: No changes
• Permissions changes: No changes. Same permissions as "View all software": https://fleetdm.com/guides/role-based-access#user-permissions
• Changes to paid features or tiers: Available in Fleet Free and Fleet Premium
• Once shipped, requester has been notified

Engineering

• Feature guide changes: No changes needed
• Database schema migrations: No changes needed
• Load testing: No need

ℹ️  Please read this issue carefully and understand it. Pay special attention to UI wireframes, especially "dev notes".

QA

Risk assessment

• Requires load testing: No
• Risk level: Low

Manual testing steps

1. Add hosts across various platforms, including at least two Linux hosts across multiple distros
2. Go to the Software > OS table
3. Filter by operating system type, including testing "Linux"
4. Ensure other filters/pagination still work

Testing notes

Confirmation

1. Engineer (@iansltx): Added comment to user story confirming successful completion of QA.
2. QA (@xpkoala): Added comment to user story confirming successful completion of QA.

[noahtalerman]

Thanks for tracking this @RachelElysia!

(Anyone on our FE team should be capable of the fullstack work to add API filtering and UI changes)

What's your rough estimate on the amount of work for one engineer? (frontend + backend work) 3 points? 5 points?

I think this is a good one to take in the upcoming design sprint so that we can build it if we have capacity next sprint.

I believe I've heard folks at customer-rialto requesting this. cc @zayhanlon

[RachelElysia]

@noahtalerman fullstack 5?

[noahtalerman]

Hey @RachelElysia heads up that this story didn't make the 3 week drafting => estimation timeline so it's been dropped (deprioritized)

If you think we should consider prioritizing this please bring it back to feature fest. Thanks!

[marko-lisica]

Hey @georgekarrv and @sharon-fdm Not sure which team will be working on this one so I assigned both of you. It's small UI change.

[sharon-fdm]

@marko-lisica, NP. we can take it.

[iansltx]

So, we have an issue with this as-spec'd.

The vulnerabilities by OS version endpoint platform filtering handled Linuxes as e.g. amzn and ubuntu rather than as generic "linux" (and this is how platform is returned as well). This means that filtering by platform=linux without API modifications will return zero results (platform filtering doesn't support multiple entries, so we can't work around client-side by passing the list of Linux platforms defined in HOST_LINUX_PLATFORMS in platform.ts). While we use this endpoint elsewhere, the only platform filtering we do elsewhere is for Windows/macOS (Linux is filtered by a built-in label elsewhere from what I can tell) so we haven't run into this issue head-on.

With that said, we don't actually support OS version vulnerability scanning for platforms other than windows/darwin (and we note that these platforms are not supported in the UI), so if the desired functionality is for checking vulnerabilities, All/Windows/macOS would be sufficient by virtue of us not supporting any other platform at the OS level at this point. Then we can add other OSes to the filter later as we expand OS support, and Linux just won't show up because we check kernel/package versions rather than overall OS version for vulnerability scanning there, and likely won't change this.

@RachelElysia @randy-fleet is this an acceptable scope change (which keeps these changes limited to the frontend), or do we need to do one of the following:

1. Support selecting Linux in the API for platform on the OS versions endpoint (either by providing multiple platforms in the query or having a pseudo-platform "linux" that passes all known Linux platforms in)
2. Add and prioritize an issue for supporting more OSes than Windows/macOS in OS-based vulnerability scanning

[RachelElysia]

Personally, I think we should add ios, ipados, and chrome now even if it doesn't have vuln scanning.

Going to defer to product/design about how to go about the UI when the current API does not have Linux as an option

[iansltx]

Quick estimate for building/testing getting linux as a pseudo-platform for OS version: 2pt, with 99.99% of the work on the backend (I have "linux" commented on the frontend now). All of the work would be in the hosts datastore file, inside the OSVersions function.

[iansltx]

Per design review, we're expanding scope on this to include adding a linux platform option on the API, which will allow this on the frontend. Bumping estimate to 5 to account for this (incl. docs updates).

Given priority of #20404, putting dev on this on hold until the endpoint for that is done. This should still make it into 4.57.0, but will be closer to the cut.

[sharon-fdm]

@iansltx, this will probably be 4.58.0. right?
Should we remove the milestone if so?

[iansltx]

As mentioned in standup, this one's low-risk, so while this is absolutely going to land after the cut, there's some chance of being cherry-picked in. If we want to make the decision now to punt this to 4.58.0, that's fine as well.

Alternatively, we could run with this as-is without Linux support (in which case this can be merged as-is, as the PR for this has already been arppoved) and patch in Linux support in 4.57.1. But patching into 4.57.1 implies that lack of Linux support is a bug, which implies that we'd be introducing an unreleased bug if we merge this, so we probably don't want to do that?

[noahtalerman]

Hey @zayhanlon we didn't have room for this one in the current engineering sprint.

I pulled it off the drafting board.

Please let me know if you think we should weigh it in the next engineering sprint. If not, please bring this one back through to feature fest. Thanks!

[zayhanlon]

@noahtalerman its lower in the customers priority list in comparison with other items we're working on so i'll evaluate before the next FF

[iansltx]

Self-QA'd ~18 days ago. QA'd by @xpkoala yesterday.

[noahtalerman]

Hey @zayhanlon heads up, this user story shipped in Fleet 4.59.

[fleet-release]

Filter, sort, explore,
In clouds of data, truth soars,
Secure more, fear less lore.