The only recommended way to run a multi-tenant Pulsar functions clusters is to run it with Kubernetes runtime.
In thread or process runtime, there is no reliable way to restrict the access to the credentials of each function instance (since it needs to be readable by the same unix user), or for what it matters, to restrict the resources that this function has access to (eg: cpu, memory, network, disk..). -- Matteo Merli <matteo.me...@gmail.com> On Mon, Jan 24, 2022 at 11:54 PM Niclas Hedhman <nic...@hedhman.org> wrote: > > > This sounds quite important, and I would like to hear from the devs if > this is correct or something is misunderstood. I am about to recommend > (or not) a critical multi-tenant system, so would like to get the full > picture. > > Thanks > Niclas > > On 2022-01-21 15:51, Devin Bost wrote: > > 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
