Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Don't expose HTTP API for secure clusters #6408

Closed
wants to merge 1 commit into from

Conversation

gjoseph92
Copy link
Collaborator

Closes #6407

I'd like to come up with a better name than insecure-routes for the config, since that implies that the others are secure (I don't know if that's something we really guarantee?)

cc @Matt711 @jakirkham

  • Tests added / passed
  • Passes pre-commit run --all-files

@github-actions
Copy link
Contributor

Unit Test Results

       15 files  ±0         15 suites  ±0   6h 45m 59s ⏱️ - 17m 46s
  2 807 tests +1    2 728 ✔️ +  5    79 💤  -   1  0  - 3 
20 810 runs  +1  19 880 ✔️ +60  930 💤  - 56  0  - 3 

Results for commit 3d7ea1a. ± Comparison against base commit 9bb999d.

@jakirkham
Copy link
Member

cc @jacobtomlinson @quasiben (for awareness)

Copy link
Member

@fjetter fjetter left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I'd like to come up with a better name than insecure-routes for the config,

How about tls-required-routes?

Comment on lines +262 to +268
@gen_cluster(client=True, clean_kwargs={"threads": False}, security=tls_only_security())
async def test_api_disabled_if_secure(c, s, a, b):
async with aiohttp.ClientSession() as session:
async with session.get(
"http://localhost:%d/api/v1" % s.http_server.port
) as resp:
assert resp.status == 404
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

if there is a typo, the route is actually removed or the version number is bumped, this test would still pass.
You could parametrize over security and ensure that the route is reachable if security is disabled to make sure the test assumption is actually valid

Copy link
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The above test_api should effectively do that (I just copied that test to write this one).

I also found this testing less thorough than I'd like ideally (would be nice to have a scheduler.py unit test with a dummy route for the insecure-routes being dropped, plus this test here confirming that the API routes were dropped by default). But I noticed there's no testing in scheduler.py for HTTP routes, only these sorts of tests.

Comment on lines +58 to +59
To prevent unauthorized access, the scheduler API is disabled by default if `tls`_ is enabled.
See the ``distributed.http.insecure-routes`` :doc:`config <configuration>` setting.
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The API is disabled if tls is disabled. This sentence is the other way round, isn't it?

Copy link
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I believe the API is enabled if mTLS is disabled -> API is disabled if mTLS is enabled:

if not self.security.require_encryption:
http_server_modules.extend(
dask.config.get("distributed.scheduler.http.insecure-routes")
)

@fjetter
Copy link
Member

fjetter commented May 23, 2022

slight off-topic: Is HTTPS something that would help? Is this something we can easily do? Are there reasons why we wouldn't want to do HTTPS? (We should create a follow up ticket if the answer is yes, we want to do this)

Copy link
Member

@jacobtomlinson jacobtomlinson left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Thanks for raising this @gjoseph92. I agree that we should disable the HTTP API when mTLS is enabled. I would also be happy to just disable the HTTP API by default and make it opt-in.

I'm not especially excited about splitting HTTP routes into "secure" and "insecure" like this. It feels like we are leaking implementation details to the user here. We should definitely add some auth options to the API in the future, so then we would be left with a stray "insecure" config option that no longer makes sense.

@gjoseph92
Copy link
Collaborator Author

We should definitely add some auth options to the API in the future, so then we would be left with a stray "insecure" config option that no longer makes sense

Yeah, I was hesitant about that too.

@jacobtomlinson @Matt711 would you prefer just leaving distributed.http.scheduler.api out of the default routes for now then?

@jacobtomlinson
Copy link
Member

would you prefer just leaving distributed.http.scheduler.api out of the default routes for now then?

Yeah that's totally fine as we can still enable it in config on platforms where auth is handled outside of distributed.

Thanks for picking this up!

@gjoseph92
Copy link
Collaborator Author

Sounds good. @jacobtomlinson would someone on your side be able to pick that up today, or should I? (I'd want to see a test confirming that the API is not enabled with the default config to avoid regressions FYI.) We're hoping to get the release out today. I'll close out this PR then.

@gjoseph92 gjoseph92 closed this May 23, 2022
@gjoseph92 gjoseph92 deleted the insecure-http-api branch May 23, 2022 15:25
@jakirkham
Copy link
Member

jakirkham commented May 23, 2022

My guess is Jacob is out for the day (kind of late for him). Matt was an intern, whose last day was Friday. Think we are going to struggle to come up with someone to fix it with short notice (today). If we have some more time, that might be more doable.

Edit: NVM appears this is already being addressed here ( dask/community#245 (comment) )

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

Don't expose insecure HTTP API
4 participants