protocol should default to tls if security is set

[riedel]

If there is nothing that speaks against that I would file a PR for this.

Should I only do this if encryption is required by the security object?

Another question: does it make sense to add a feature to automatically generate certificates for worker, scheduler and client in the jobque case?

Currently you will get an runtime error:
RuntimeError: encryption required by Dask configuration, refusing communication from/to 'tcp://'

(Actually I then accidentially set tls via the scheduler options which made things worse: the workers silently failed to connect)

[guillaumeeb]

I've never looked into Security into Dask, but what you propose makes sense, especially if encryption option is set in security object.

Another question: does it make sense to add a feature to automatically generate certificates for worker, scheduler and client in the jobque case?

If it's simple enough yes I guess, I don't know if there are other solutions to obtain certificates when IPs are kind of random, or at least can vary on a high range.

[jacobtomlinson]

We did this in dask/dask-cloudprovider#222 for the cloud VM based cluster managers.

It took a little work to remove some of the hard coded assumptions we had made around protocol and there was a little effort to handle the certificate generation correctly. But now by default certificates are generated by default and updated into the Dask config dynamically. In dask-cloudprovider we serlialize and ship the in memory config to the workers and scheduler so everything works nicely on that end.

One issue we did run into was there is a limit on AWS on how much config we can pass, and certs fills that up quickly!

[guillaumeeb]

@riedel, feel free to propose a PR for this!

[riedel]

#519 fixes this, however the PR is not as minimal as I wanted.

[guillaumeeb]

But now by default certificates are generated by default and updated into the Dask config dynamically. In dask-cloudprovider we serlialize and ship the in memory config to the workers and scheduler so everything works nicely on that end.

@jacobtomlinson if you have time to look at #519, and also explain a bit more the part of serializing and shipping the in memory config to the workers. I think this is the hard part for dak-jobqueue currently, so @riedel used a workaround by writing the in memory security keys to a file... I'm not really fond of this solution.

[riedel]

I commented on why I did this in #520, because one could actually close this issue by only supporting file certificates in the first place. TL;DR: I think using dask.config.set alternatively could have an bigger impact than creating some tempfiles, but maybe I am not completely getting the trick here.

[jacobtomlinson]

I think only supporting file certificates in dask-jobqueue would be reasonable. In places like dask-cloudprovider we are limited to passing the certs in the Dask config because we can't guarantee there will be a shared filesystem. But for HPC I think most cases there will be one.