Add minion id to all fileserver events sent to request server and optionally sign the payload as well.
Currently there is no possibility to determine on master which minion requested particular fileserver operation (file list, file request, etc.), which makes it impossible to implement any minion-based permissions level onto fileserver.
Implementing this RFC would make it possible to implement custom fileservers that support various layers of security, allowing to restrict access for particular minions to environments/files and achieving some level of fileserver multitenancy.
Proposed design is to add id
key to all fileserver-related payloads in RemoteClient
, optionally allowing to also sign the messages similarly as it's done via minion_sign_messages (either reusing same configuration option or introducing new one).
After master can receive minion identity and signature, custom fileserver modules can be implemented or existing modules can be extended with the functionality (out of scope for this RFC).
To actually propagate that load data to custom fileserver, appropriate changes need to be done to Fileserver because not all methods propagate full load to underlying modules (envs, find_file). To avoid issue when all existing fileserver modules would have to be refactored to support new function arguments, similar usage of _argspec
can be used as for envs
method.
Include id/signature automatically to everything going through channel.send
so every function in RemoteFuncs/AESFuncs can verify minion validity. This would however either require necessary validations for every master request - for some calls this would be unnecessary and others are already validating this via tok key, or just sending unnecessary data to masters.
Reuse minion_sign_messages
configuration option or introduce new option such as minion_sign_fileserver_messages
?
When this gets introduced, every fileserver payload will be larger by minion id and signature, increasing traffic slightly. Also additional load can be introduced to minions when payload signature is computed (only applicable if enabled).
As there will be no default processing for the id/signature, no additional load should be placed on masters and existing functionality should be preserved.