Supporting manual configuration of SSL Client Certs
See original GitHub issueHello all, this is somewhat related to #304
I am trying to build a custom orchestration/spawner/launcher system for deploying a distributed cluster. Ideally this system would manage session security, to prevent arbitrary clients from connecting to a scheduler. (We’re interested in this from the perspective of a multi-user host.)
Because this is all based on Tornado, it would be very convenient to be able to just use ssl_options and communicate SSL Client Certificates before launching anything in distributed. However this doesn’t work for the Client object, as this keyword isn’t exposed. It looks like ssl_options would need to be propagated to the Client somehow from this line up. (And maybe for Scheduler and Worker as well, I haven’t read the those implementations very closely yet)
Based on reading issues/blogs/etc it looks like managing security isn’t an immediate (or even necessarily future) goal of distributed/dask, but would it be acceptable to expose a little more of Tornado’s framework to permit programmatic management of SSL for more custom deployments? Ideally distributed could just pass some kwargs around and not consider the problem further.
If you’re amenable to the idea, I would be happy to work towards a PR (given a little API guidance).
Edit: I see that there is an existing PR #537 that sort of addresses this, but it looks like it may have stalled out a little, and it doesn’t seem to have a way to pass the ssl_options into TCPClient.connect in the same way that would be natural for the TCPServer objects.
Issue Analytics
- State:
- Created 7 years ago
- Comments:10 (5 by maintainers)

Top Related StackOverflow Question
Definitely amenable to a PR helping dask.distributed to pass through Tornado keywords 😃
I can think of two options:
SSLContextparameter (and only that)Either way, I am busy refactoring the I/O layer, so it’s not a good idea to start work on this immediately.