Audit/resolve unneccessary fleetctl transitive dependencies

[iansltx]

Goal

User story
As a user of fleetctl,
I want to avoid having unnecessary dependencies included in the fleetctl binary
so that I can minimize fleetctl size and vulnerability surface.

Original requests

Context: We're pulling crewjam/saml into fleetctl's binary because of transitive dependencies from fleetctl code. This caused a flag that's being fixed by crewjam/saml#646. But we almost certainly shouldn't be including the SAML library in fleetctl in the first place, and there are likely a number of libraries like it that we could stop building in if we cleaned up our package dependency graph.

More context in Slack

Changes

Engineering

• Move all server/service/client*.go files to a new client/ directory. For that we will need to move and export all the *Response types currently defined in server/service/ to server/fleet/ , e.g. listHostsResponse. That way any Fleet client in Go (like fleetctl and orbit) won't import server/service code which doesn't make sense at all.
• Audit module usage in fleetctl builds
• Refactor fleetctl dependency graph to remove library usage that isn't in any code path actually executed by any part of fleetctl (including GitOps), focusing on low-hanging fruit first.
• Create another ticket for anything that falls outside the timebox. Add test plan items for areas touched by the refactor.
• Test plan is finalized
• This is a premium only feature: No

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

QA

Risk assessment

• Risk level: Medium
• Risk description: Depending on what we find/what we need to refactor, while we'll have automated test coverage, we may need to smoke test significant application surface (both Fleet server and fleetctl) to ensure we don't break things by moving things around

Test plan

Make sure to go through the list and consider all events that might be related to this story, so we catch edge cases earlier.

• Replace this checkbox with a list of areas to smoke test as a result of refactors found

Testing notes

Confirmation

1. Engineer: Added comment to user story confirming successful completion of test plan.
2. QA: Added comment to user story confirming successful completion of test plan.

[lukeheath]

@iansltx Thanks for filing! I've tagged with the customer who also requested this. Should we expand this to include scanning our own binaries so that if something similar happens in the future we get notified?

Prioritizing to drafting board.

[iansltx]

@lukeheath Scanning feels like its own ticket that's orthogonal to this one. Definitely good to do though.

[iansltx]

@lukeheath Moved to estimation. Idea would be to define a timebox large enough to inventory, plus put a few points on the board for fixes (e.g. I don't expect we need SAML in fleetctl, but there may be lower-hanging fruit).