anyone exposing fleet to the outside, if so how ar...
# kolide
anyone exposing fleet to the outside, if so how are you separating the admin portal from the clients
Some folks front Fleet with a reverse proxy that only exposes the osquery endpoints to the outside network.
👍 1
And some folks just rely on the auth mechanisms built into Fleet.
You want to publicly expose the
endpoints for agents to connect from public networks. Then you can expose all other endpoints only internally.
IIRC there's been some discussion on doing this in this channel in the past.
I set this up at Robinhood: front the public APIs with a public load balancer that employs path whitelisting. However it was challenging to get this to work cleanly with our network topo, and in particular Fleet is a bit wonky when sending provisioning emails because it’s configured to think its base URL is our public (rather than private) DNS which is only valid when you need to talk to the public APIs. Similar challenges when we attempted to turn on SAML. Currently we just ask onboarding security engineers to manually edit the account activation URL to substitute the right internal domain lol
I think it makes for a good feature request: maybe separate the notion of a “public” domain/base url which is used for osquery agent purposes vs a “private” base url which is used for console link generation, used in emails, SAML endpoints etc
@cbarcenas Does it break anything if you set the "private" URL in the app settings? That should get Fleet to generate emails, etc. using that URL
On mobile now, and it’s been a few months since I’ve looked at this, but I’ll revisit and get back as soon as im back at my computer
Yeah please update. IIRC that's what the setting is used for and it may solve your issue.
Update: I probably can't test this at this exact moment, but I did review the available configuration parameters 1. In the web UI there is the "Fleet App URL" config option which carries the warning
*Note:* Please ensure the URL you choose is accessible to all endpoints that need to communicate with Fleet, otherwise they will not be able to correctly register.
2. There is the
CLI arg &
envvar, but these refer to URI prefixes, not domains I think the reason we originally chose to use our public domain/URL in the "Fleet App URL" field was because enrollment was breaking in some way
I'm looking through the code (and my memory) and I don't believe there is any reason that the "Fleet App URL" would need to be accessible to the osquery agents. Please give it a try when you get a chance and we can update that UI element if it turns out to work.
It looks to me that the URL is only used for SSO and emails.
Just checking in here -- we successfully changed the URL without any apparent breakage of the osquery agents. Just some empirical evidence to support @zwass’s analysis above :) I've submitted a PR to remove the misleading warning from the Fleet onboarding and configuration pages
Awesome thank you!