I discovered that all functions running in process mode inherit the same role from the token specified in the functions_worker.yml file. So, that means that all functions in process mode have the same authorization scope, which must be broad enough to ensure that all functions have the required permission to operate. Architecturally, this design limits the ability to enable self-service/multi-tenant management of process-mode functions because it means that functions in one tenant automatically have permission to access topics in all other tenants. Even if a custom PulsarAuthorizationProvider is used, there's no current way to distinguish roles between functions in process mode because they all share the same token. In the code path where authorization is checked ( https://github.com/apache/pulsar/blob/adcbe0f118ece0999b8603f37010194b44c241b4/pulsar-broker-common/src/main/java/org/apache/pulsar/broker/authorization/PulsarAuthorizationProvider.java#L90), there's no way to see which function is originating the request. The original principal used for the authorization check ( https://github.com/apache/pulsar/blob/3e6fedf9b69758c13d92c6ff75a7bd779038543a/pulsar-broker/src/main/java/org/apache/pulsar/broker/rest/TopicsBase.java#L758) is derived from the role ( https://github.com/apache/pulsar/blob/cba8800de1013d0e8ac81f43ecb040a55978c358/pulsar-proxy/src/main/java/org/apache/pulsar/proxy/server/AdminProxyHandler.java#L369), so during the authorization check, it doesn't appear that there's any other information about who is initiating the request that could be used. (It appears that there's no way for us to securely know who the requester is except via their token.)
This brings me to wondering what the vision is for functions in process mode. Are they intended to only be managed by an operator with administrative access to the cluster? If there's an interest in supporting multi-tenant permission scoping for process mode functions, what's the right way to do it? Devin G. Bost
