While it may be possible to create a function with a normal user, it
would be better to be able to specify the function's authentication
credentials.
> You don't need tenant admin access to create functions, you just need
> to give "functions" access to a normal user:
This user may not be an admi
You don't need tenant admin access to create functions, you just need
to give "functions" access to a normal user:
pulsar-admin namespaces grant-permission --actions
produce,consume,functions --role $MY_PRINCIPAL
--
Matteo Merli
On Fri, Feb 11, 2022 at 5:46 PM Devin Bost wrote:
>
> Thanks for
Thanks for all the feedback on this.
So, I'm looking into running functions in the Kubernetes runtime, and I'm
seeing another potential issue in terms of restricting function
authorization scope.
The function worker reads the token from the pulsar-admin call's
Authorization header when the functio
On 2022-01-25 08:57, Matteo Merli wrote:
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
Devin,
You can customize how each function authenticates with brokers by creating
a implementation of this interface:
https://github.com/apache/pulsar/blob/master/pulsar-functions/runtime/src/main/java/org/apache/pulsar/functions/auth/FunctionAuthProvider.java
and setting the class name of your
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 wh
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 th
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
per
