Add new `/api/_version_/fleet/device/{token}/desktop` endpoint

[lukeheath]

Goal

For a customer with concerns about the information disclosed by the Fleet Desktop APIs, provide an endpoint that can be excepted from their SSO and return the minimal set of information for Fleet Desktop to function.

Related

• #6680 (epic)
• #6946 (agent)

Tasks

1

• [ ] Add new GET /api/version/fleet/device/{token}/desktop API endpoint

This API returns only the minimal set of information required to render the Fleet Desktop application. Example:

{"failing_policies_count": 3}

Note that the endpoint explicitly does not include any identifying information about the host, so even if an attacker were to get access to a device token, they would not be able to identify which device the information corresponds to (unless they also have access to the device itself, or can get around the SSO). In the future, more information may be added to the endpoint to support Fleet Desktop functionality and we will take care not to introduce identifying information about the host.

[lukeheath]

@mna When you are online would you please take a look at the specs on this ticket and let me know if you have any questions or concerns. If all looks good, please add a point estimate to the ticket. Thanks!

[mna]

@lukeheath The description says "from their SSO", but this is an endpoint authenticated with the Fleet Desktop device token, right? The same one that can access the GET /api/_version_/fleet/device/{token} endpoint that returns the whole host information?

If so, this is not a big change, as long as we're ok with a leak of the token making it possible to view the whole host information by using it to access the other token-authenticated endpoints (the risk will be mitigated by the token rotation). I'll estimate it like this, let me know if I'm misunderstanding.

[lukeheath]

@mna Thanks for the call outs!

@noahtalerman Regarding this line:

provide an endpoint that can be excepted from their SSO

We're not 100% sure what this means. Does it mean the endpoint should not require password or SSO authentication? Per Martin's message above, the /device/{token} endpoint is authenticated by the provided token only and does not require password or SSO.

Also to echo Martin's concern, if we create a /device/{token}/desktop endpoint for desktop to use, that same token can be used to access the /device/{token} endpoint, which will provide the full device information. Is that acceptable?

[noahtalerman]

@zhumo can you please help address the above questions and concerns. Because you're the DRI for the parent epic, I think you might have more context here...

[zhumo]

Hey @lukeheath @mna. Thanks for pointing that out. Definitely this word "excepted" is not clear what it means.

Basically, even though our system does not require SSO authentication (and as of right now, fleet desktop does not accommodate SSO), some of our users want to put all of the API behind their SSO, so that they can protect all the detailed device info in /device/{token}. The solution we came up with is to have this minimal api endpoint, /device/{token}/desktop that shares only as much info as Fleet Desktop needs to populate itself. Our users can then put the /device/{token} behind their wall, but leave /device/{token}/desktop outside the wall to be used generally.

Essentially, all we need to do is provide these two API endpoints. Users who care can wall up one endpoint. Users who don't care can leave both exposed.

@zwass did I get that right? Any comments or additions?

[mna]

@zhumo Allright, I think I understand with that clarification (thank you!), so to rephrase how I understand it: all the Fleet API would be only allowed behind their SSO (so any non-SSO API endpoint would be blocked), and they would specifically allow this new minimal Fleet Desktop endpoint as an exception. Even if the fleet desktop token leaks, the endpoint that gives all the hosts' information would not be reachable. (I'm probably hand-wavy on some details as I'm not an SSO expert.)

So basically, this ticket is quite straightforward: add this new endpoint with a minimal response payload, authenticated via the fleet desktop token as usual (i.e. same as for other "device auth token" endpoints), and customers that decide to do so may add it as an exception at minimal risk. (I suppose that Fleet Desktop will have to be configured somehow to use that minimal endpoint instead of the full-featured one, but that's not a question for the current ticket).

/cc @lukeheath

[zhumo]

@mna You got it! That's correct.

FYI Fleet Desktop will not be configurable to use the minimal endpoint or something else. It'll just use it going forward. That work is captured here: https://github.com/fleetdm/fleet/issues/6946. Not relevant for us here, but just noting since you asked!

[juan-fdz-hawa]

Just to make sure I'm on the same page here. Fleet Desktop only uses two end-points AFAIK: /fleet/device/<token>/transparency and /fleet/device/<token>/policies (the 'rest' are used by Orbit), so the scope of this issue is to add a new endpoint /api/_version_/fleet/device/{token}/desktop with the combined payload of /policies and /transparency?

Thanks

[lukeheath]

@juan-fdz-hawa Thanks for checking. For security purposes, this is going to be a minimal endpoint. The entire response body will be:

{"failing_policies_count": 3}

(or however many policies are failing for that host)

It occurs to me now that we may need to include the results from the /transparency endpoint, as well, in order to meet Mo's criteria above to provide everything needed to render the Fleet Desktop menu icon:

The solution we came up with is to have this minimal api endpoint, /device/{token}/desktop that shares only as much info as Fleet Desktop needs to populate itself.

@zhumo Should we expand the response body to include the transparency page URL? That is not hardcoded because it can be configured in the settings.

[zhumo]

@lukeheath yes please.

[lukeheath]

@juan-fdz-hawa I'm trying to get the payload for the GET api/_version_/fleet/device/{token}/desktop/transparency endpoint, but it looks like that endpoint redirects to the actual transparency page. Would you please look at the code and confirm that's the case? If it's just a redirect, then we don't need to worry about serving the URL.

[xpkoala]

@juan-fdz-hawa I'm still not able to access the transparency page using api/latest/fleet/device/<key>/desktop/transparency. Is this expected to be returning output at the moment?

[juan-fdz-hawa]

@juan-fdz-hawa I'm still not able to access the transparency page using api/latest/fleet/device/<key>/desktop/transparency. Is this expected to be returning output at the moment?

Hi, that endpoint returns a redirect and no output at all. There's a small typo in the URL you are using, it should be api/latest/fleet/device/<token>/transparency

[xpkoala]

Thank you for the clarification!

[juan-fdz-hawa]

Sounds good.

On Thu, 1 Sep 2022 at 11:10 AM Luke Heath @.***> wrote:

@juan-fdz-hawa https://github.com/juan-fdz-hawa I'm trying to get the payload for the GET api/version/fleet/device/{token}/desktop/transparency endpoint, but it looks like that endpoint redirects to the actual transparency page. Would you please look at the code and confirm that's the case? If it's just a redirect, then we don't need to worry about serving the URL.

— Reply to this email directly, view it on GitHub https://github.com/fleetdm/fleet/issues/7084#issuecomment-1234417011, or unsubscribe https://github.com/notifications/unsubscribe-auth/AB5LGZXAKYLIYEP3DEECZ3DV4DBPVANCNFSM55WWISDQ . You are receiving this because you were mentioned.Message ID: @.***>

--

Juan Fernandez

Software Engineer

fleetdm.com http://www.fleetdm.com | @.*** https://twitter.com/fleetctl