You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Our current XGBoost integration will not work out of the box if the user chooses to enable internode security (encrypted node-to-node connections). In order to make xgboost work in such a setting, the user has to opt out of the secure connections for native xgboost connections. This is because we currently have very little control over how these connections are made and how the data is sent.
The purpose of this task is to investigate how can we include XGBoost connections into our security model.
The text was updated successfully, but these errors were encountered:
karel.nechvile commented: In the advance of increased security requirements, the trend is also followed by XGBoost.
There is an ongoing activity to implement "Federated Learning" within XGBoost code base and its motivation,
goals and design choices are described here: [https://github.com/dmlc/xgboost/issues/7778|https://github.com/dmlc/xgboost/issues/7778|smart-link]
What's important to us (H2O) is that communication between workers and a trusted aggregator is performed in a secured way.
The initial steps were already merged into master branch in the form of a separate plugin
" Initial support for federated learning #7831" ([https://github.com/dmlc/xgboost/pull/7831|https://github.com/dmlc/xgboost/pull/7831)])
There is also related activity to clean up the communication interface (in progress at the time
of this writing), see Common interface for collective communication #8057
([https://github.com/dmlc/xgboost/pull/8057|https://github.com/dmlc/xgboost/pull/8057).]).
From the point of H2O view (considering secured communication), it's probably advisable to upgrade
H2O-xgboost to latest version and be prepared to use/adapt the (secured) communication framework
when it gets available as part of a standard XGBoost release.
Our current XGBoost integration will not work out of the box if the user chooses to enable internode security (encrypted node-to-node connections). In order to make xgboost work in such a setting, the user has to opt out of the secure connections for native xgboost connections. This is because we currently have very little control over how these connections are made and how the data is sent.
The purpose of this task is to investigate how can we include XGBoost connections into our security model.
The text was updated successfully, but these errors were encountered: