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
I'd like to be able to create jnlp slaves with minimal security privileges on the master, and ideally through http mode instead of remoting.
Matrix-based security supports granting just the rights to manage nodes. The cli has specific commands for all of the node management actions. It should be rather straight forward.
Currently though, all the actions are performed with groovy code, which means the user doing them needs the Overall/RunScripts right. As documented by Matrix-based Security, "RunScripts allows executing arbitrary code in the context of any (Jenkins internal) user, including the internal SYSTEM user."
The current approach also requires the cli be invoked in -remoting mode rather than -http mode. Remoting is deprecated as a major security vulnerability and recommended to be turned off.
Remoting is "inherently vulnerable to remote code execution bugs, even “preauthentication” exploits (by anonymous users able to physically access the Jenkins network)."
The text was updated successfully, but these errors were encountered:
I'd like to be able to create jnlp slaves with minimal security privileges on the master, and ideally through http mode instead of remoting.
Matrix-based security supports granting just the rights to manage nodes. The cli has specific commands for all of the node management actions. It should be rather straight forward.
Currently though, all the actions are performed with groovy code, which means the user doing them needs the Overall/RunScripts right. As documented by Matrix-based Security, "RunScripts allows executing arbitrary code in the context of any (Jenkins internal) user, including the internal SYSTEM user."
The current approach also requires the cli be invoked in -remoting mode rather than -http mode. Remoting is deprecated as a major security vulnerability and recommended to be turned off.
Remoting is "inherently vulnerable to remote code execution bugs, even “preauthentication” exploits (by anonymous users able to physically access the Jenkins network)."
The text was updated successfully, but these errors were encountered: