Title
#kolide
killahquam

killahquam

01/15/2020, 9:45 PM
anyone exposing fleet to the outside, if so how are you separating the admin portal from the clients
zwass

zwass

01/15/2020, 10:05 PM
Some folks front Fleet with a reverse proxy that only exposes the osquery endpoints to the outside network.
10:07 PM
And some folks just rely on the auth mechanisms built into Fleet.
10:13 PM
You want to publicly expose the
/api/v1/osquery/*
endpoints for agents to connect from public networks. Then you can expose all other endpoints only internally.
10:14 PM
IIRC there's been some discussion on doing this in this channel in the past.
killahquam

killahquam

01/15/2020, 10:14 PM
ok
c

cbarcenas

01/16/2020, 12:19 AM
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
12:21 AM
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
zwass

zwass

01/16/2020, 12:27 AM
@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
c

cbarcenas

01/16/2020, 12:29 AM
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
zwass

zwass

01/16/2020, 12:29 AM
Yeah please update. IIRC that's what the setting is used for and it may solve your issue.
c

cbarcenas

01/16/2020, 1:08 AM
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
server_url_prefix
CLI arg &
KOLIDE_SERVER_URL_PREFIX
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
zwass

zwass

01/16/2020, 2:10 AM
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.
2:11 AM
It looks to me that the URL is only used for SSO and emails.
c

cbarcenas

01/22/2020, 1:30 AM
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 https://github.com/kolide/fleet/pull/2188
zwass

zwass

01/22/2020, 11:27 PM
Awesome thank you!