On 17.05.2013 17:12, Jeff Darcy wrote: Hi Jeff and thanks for the info,
(2) We use SSL only for encryption and authentication, not authorization. While you do need an authenticated identity to connect, we don't really care what that identity is and once you've connected we don't use it for any further access-control checks (there is a patch to do so).
Understood. What would happen if one peer is SSL enabled (i.e. has all the bits in place) and one is not (i.e. has a missing key); would the transfer/process go back to non-SSL or just die with some errors?
Any chance the SSL feature could be managed through glusterd? Just as glusterd is responsible for vol files across the deployment and so on, it should also be able to generate and maintain key/ca files.
(3) SSL is only for the data connections (glusterfs<->glusterfsd) and is explicitly disabled for control connections (glusterd<->anything). (4) Turning on SSL also turns on transport multi-threading (because otherwise performance would be awful as other work gets blocked behind encryption in a single polling thread). This is usually a performance benefit even without SSL, and some people do turn it on just for that, but it's less fully tested and supported than the usual threading model.
Any way to turn on just multi-threading, without SSL?
All that said, I'd be glad to have more people using SSL, and to hear about their experiences (including bug reports). Long term, I think secure connections are going to be an absolute requirement in a significant number (if not a majority) of deployments, so the more mileage we get on it sooner the better.
Yes, it could sure have its use cases, such as securing traffic going through some "public" VLANs (the case with many "cloud" deployments).
-- Sent from the Delta quadrant using Borg technology! Nux! www.nux.ro
