Self-paced-training tutorial: Chapter 6: Security #3205
Conversation
chesterxgchen
force-pushed
the
self-paced-training4
branch
2 times, most recently
from
d0b439e to
fea866b
Compare
chesterxgchen
assigned chesterxgchen, holgerroth, ZiyueXu77 and nvidianz and unassigned chesterxgchen
chesterxgchen
force-pushed
the
self-paced-training4
branch
from
8cb89a4 to
1ec4152
Compare
chesterxgchen
requested review from
IsaacYangSLA,
holgerroth,
yanchengnv,
ZiyueXu77,
nvidianz and
YuanTingHsieh
chesterxgchen
force-pushed
the
self-paced-training4
branch
from
1ec4152 to
3826169
Compare
| "\n", | ||
| "Federated Computing System requires robust security mechanisms to ensure that only legitimate and trusted participants contribute, while also protecting communication channels and enforcing authorization policies. Below are the critical security components of an FL system. \n", | ||
| "\n", | ||
| "This area is concerned with these two trust issues:\n", |
There was a problem hiding this comment.
Do we need this sentence?
| "\n", | ||
| "* **Authentication**\n", | ||
| "\n", | ||
| "ensures communicating parties have enough confidence about each other’s identities: everyone is who they claim to be.\n", |
There was a problem hiding this comment.
Should the first letter be capital?
| "\n", | ||
| "* **Authorization** \n", | ||
| "\n", | ||
| "ensures that the user can only do what he/she is authorized to do.\n", |
There was a problem hiding this comment.
Should the first letter be capital?
| "Due to the distributed nature of federated computing system, additional authentications and authorization are needed for each participate organizations. \n", | ||
| "\n", | ||
| "You can find out how NVIDIA FLARE instrumented these via event-based Federated Authentication and authorization\n", |
There was a problem hiding this comment.
Suggest to explain how NVFlare has instrumented all these components AFTER explaining all "critical security components/issues/concerns" in an FL system.
| "\n", | ||
| "* **Privacy Protection**: \n", | ||
| "\n", | ||
| "another aspect of security is privacy protection. We have introduced different privacy enhancement technologies (PETs) in [Chapter 5](../../chapter-5_Privacy_In_Federated_Learning/05.0_introduction/introduction.ipynb), here ware going to explore what's privacy protection mechanism at the organization level. \n", |
There was a problem hiding this comment.
could we explain what is "privacy protection"?
There was a problem hiding this comment.
hereware -> "in this chapter, we are"
| "\n", | ||
| "### Centralized vs. Federated Authorization\n", | ||
| "\n", | ||
| "Instead of relying a centralized (FL Server) to authorizate and authenticate the user, NVFLARE now uses federated authorization where each organization defines and enforces its own authorization policy:\n", |
There was a problem hiding this comment.
"Instead of relying on a centralized FL Server to authorize and authenticate users, NVFLARE uses federated authorization, where each organization defines and enforces its own authorization policy:"
| "\n", | ||
| "Each organization defines its policy in its own authorization.json (in the local folder of the workspace). This locally defined policy is loaded by FL Clients owned by the organization, The policy is also enforced by these FL Clients.\n", | ||
| "\n", | ||
| "This decentralized authorization has an added benefit: since each organization takes care of its own authorization, there will be no need to update the policy of any other participants (FL Server or Clients) when a new orgs or clients are added.\n", |
There was a problem hiding this comment.
suggest:
"This federated authorization has an added benefit: since each organization manages its own authorization, there is no need to update the policy of any other participants (FL Server or Clients) when new organizations or clients are added."
| "Since each organization defines its own policy, there will be no need to centrally define all orgs and users. The policy configuration for an org is simply a matrix of role/right permissions. Each role/right combination in the permission matrix answers this question: what kind of users of this role can have this right?\n", | ||
| "\n", | ||
| "To answer this question, the role/right combination defines one or more conditions, and the user must meet one of these conditions to have the right. The set of conditions is called a control.\n", |
There was a problem hiding this comment.
"Since each organization defines its own policy, there is no need to centrally define all organizations and users. The policy configuration for an organization is simply a matrix of role/right permissions. Each role/right combination in the permission matrix answers this question: What kind of users in this role are granted this right?
To answer this question, the role/right combination defines one or more conditions, and the user must meet at least one of these conditions to have the right. The set of conditions is called a "control."
| "\n", | ||
| "* Admin commands are grouped into categories. For example, commands like abort_job, delete_job, start_app are in manage_job category; all shell commands are put into the shell_commands category. Each category is also a right.\n", | ||
| "\n", | ||
| "* BYOC is defined as a right so that some users are allowed to submit jobs with BYOC whereas some are not.\n", |
There was a problem hiding this comment.
suggest adding the explanation of BYOC here if we want to talk about the right
| Overview | ||
| -------- | ||
|
|
||
| The purpose of this example is to demonstrate following features of NVFlare, |
There was a problem hiding this comment.
the following features
| @@ -0,0 +1,11 @@ | |||
| { | |||
| "name": "iob_1", | |||
| "source": [ | ||
| "# Site-specific security and privacy policies\n", | ||
| "\n", | ||
| "NVIDIA FLARE offers a set of security mechansim to control the user access for different opertions based on their roles. These control not limited to centralized server control, but also at each site. Such site-specific level of security is done via security policies which we call federated polices. Probably should called site-specific security & privacy polices.\n", |
There was a problem hiding this comment.
suggest:
"NVIDIA FLARE offers a set of security mechanisms to control user access for different operations based on their roles. These controls are not limited to centralized server control but also apply at each site. This site-specific level of security is managed through security policies, which we refer to as federated policies."
If we really want, we need to rename all federated policies -> federated security and privacy policies throughout our documentation
| "\n", | ||
| "NVIDIA FLARE offers a set of security mechansim to control the user access for different opertions based on their roles. These control not limited to centralized server control, but also at each site. Such site-specific level of security is done via security policies which we call federated polices. Probably should called site-specific security & privacy polices.\n", | ||
| "\n", | ||
| "[FLARE's Security documentation](https://nvflare.readthedocs.io/en/2.4/user_guide/security/identity_security.html) has details regarding\n", |
There was a problem hiding this comment.
link should use main, need to check this is true across all our links
| "\n", | ||
| "Now we are ready to discuss the examples for federated site policy. The purpose of this example is to demonstrate following features of NVFlare,\n", | ||
| "\n", | ||
| "1. Show secure admin client and authentication\n", |
There was a problem hiding this comment.
admin client -> Flare Console if we want to be consistent across all tutorials
| "\n", | ||
| "Site\n", | ||
| "____\n", | ||
| "* :code:`server`: NVFlare server\n", |
There was a problem hiding this comment.
FL server owned by org c?
| "\n", | ||
| "In this example, we will copy \"custom\" folder and \n", | ||
| "\n", | ||
| "use python code ```edit_site_local_resources.py``` to create \"resources.json\" to the at site local directory\n", |
There was a problem hiding this comment.
"to the at" -> "in the"
| "!cp -r security/server/* /tmp/nvflare/poc/example_project/prod_00/server/local/.\n", | ||
| "!python edit_site_local_resources.py server /tmp/nvflare/poc/example_project/prod_00" |
There was a problem hiding this comment.
I think it is clearer to just create a "resources.json" that contains this security_handler.
then in here we do "cp" instead of running this python script.
| "source": [ | ||
| "# Connection and Message Security\n", | ||
| "\n", | ||
| "Currently Flare's message security comes from mutual TLS: server and client authenticate each other when making direct connections. This means that only clients that have the right startup kits can make a connection to the server.\n", |
There was a problem hiding this comment.
Is this true? the main branch is 2.6, so it does not necessary mTLS?
| "\n", | ||
| "Since the connectivity solution may expose the server to the internet and allow any one to connect to the server, it is important to ensure that messages sent to the server are explicitly authenticated.\n", | ||
| "\n", | ||
| "Flare 2.5 and above support explicit message authentication: messages received by the server must have an auth token, and the token must be validated successfully to prove that it was issued by the server.\n", |
There was a problem hiding this comment.
Do we need to emphasize this here?
If we want, we could in the beginning (chapter 0) saying this tutorial is written for 2.5+
| "\n", | ||
| "### Setup KeyCloak\n", | ||
| "\n", | ||
| "Before we start, we need to download and start the KeyCloa service. To do that, we create a [dockerfile](./examples/custom_client_side_auth_system_integration/keycloak-setup/dockerfile) and [docker-compose](./examples/custom_client_side_auth_system_integration/keycloak-setup/docker-compose.yml) file\n", |
There was a problem hiding this comment.
KeyCloa->KeyCloak,
maybe need to provide some background to what is KeyCloak
Description
Chapter 6: Related to the Security aspect of NVFLARE
I completed most of the sections except the following
* Message serialization -- FOBs
* Unsafe components
* Audit log
There are few issues encountered
* Federated Policy -- original example using provision, I could follow the same approach, but I was hoping to use POC mode to simplify the process, but there are some issues (bugs) related to the nvflare poc -i project.yml
* some strange error when running jobs -- but not in others machine
But I think the first few sections can merged in, I will finish the remaining section after 1-week
Types of changes
./runtest.sh.