You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@pulsar.apache.org by Devin Bost <de...@gmail.com> on 2022/02/12 01:45:44 UTC
Re: Architecture of function authorization for process mode
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 function is created (
https://github.com/apache/pulsar/blob/8496afc58bdd27c47cde8a9ba3c76b80ab796320/pulsar-functions/worker/src/main/java/org/apache/pulsar/functions/worker/rest/api/FunctionsImpl.java#L207)
and saves it as the Kubernetes secret (
https://github.com/apache/pulsar/blob/1ea381d02bf2c817547b4759b0dbf57366fd1358/pul[…]e/pulsar/functions/auth/KubernetesSecretsTokenAuthProvider.java
<https://github.com/apache/pulsar/blob/1ea381d02bf2c817547b4759b0dbf57366fd1358/pulsar-functions/runtime/src/main/java/org/apache/pulsar/functions/auth/KubernetesSecretsTokenAuthProvider.java#L100>).
When the function starts, it uses that secret for broker authentication.
The problem is that the pulsar-admin create action requires the token to
have a subject that matches an adminRole specified on that tenant (
https://github.com/apache/pulsar/blob/7576a6594233f3ac9e20028db12ec731bd485a68/pulsar-functions/worker/src/main/java/org/apache/pulsar/functions/worker/rest/api/ComponentImpl.java#L1472).
So, the role used to create the function must be an admin on the tenant,
but that role is then inherited and assigned to the function that's
created. So, every function in the Kubernetes runtime would at least have
admin privilege within its tenant.
Is my understanding correct? Is there a way around this?
Devin G. Bost
On Tue, Jan 25, 2022 at 4:42 PM Niclas Hedhman <ni...@hedhman.org> wrote:
> 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 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..).
>
> Thank you, that helps a lot.
>
> Niclas
>
Re: Architecture of function authorization for process mode
Posted by Michael Marshall <mm...@apache.org>.
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 admin, but it will necessarily have auth
credentials capable of creating additional functions. While it's
possible to block the function creation at the network level, I think
we need a better solution.
I haven't looked closely, but we could update the function creation
logic so that it takes the name of an existing k8s secret containing
auth params. Then, the KubernetesRuntime will mount the secret into
the function. This design makes it so the Pulsar app never has to have
access to the secret's data while also letting the data have an
arbitrary format.
Using the creator's token does not work well for OAuth2.0 clients
using short lived tokens. Making it possible to configure the function
with arbitrary auth params would make it possible to use the OAuth2.0
client credentials flow in functions.
Thanks,
Michael
On Fri, Feb 11, 2022 at 7:52 PM Matteo Merli <ma...@gmail.com> wrote:
>
> 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
> <ma...@gmail.com>
> On Fri, Feb 11, 2022 at 5:46 PM Devin Bost <de...@gmail.com> wrote:
> >
> > 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 function is created (
> > https://github.com/apache/pulsar/blob/8496afc58bdd27c47cde8a9ba3c76b80ab796320/pulsar-functions/worker/src/main/java/org/apache/pulsar/functions/worker/rest/api/FunctionsImpl.java#L207)
> > and saves it as the Kubernetes secret (
> > https://github.com/apache/pulsar/blob/1ea381d02bf2c817547b4759b0dbf57366fd1358/pul[…]e/pulsar/functions/auth/KubernetesSecretsTokenAuthProvider.java
> > <https://github.com/apache/pulsar/blob/1ea381d02bf2c817547b4759b0dbf57366fd1358/pulsar-functions/runtime/src/main/java/org/apache/pulsar/functions/auth/KubernetesSecretsTokenAuthProvider.java#L100>).
> > When the function starts, it uses that secret for broker authentication.
> > The problem is that the pulsar-admin create action requires the token to
> > have a subject that matches an adminRole specified on that tenant (
> > https://github.com/apache/pulsar/blob/7576a6594233f3ac9e20028db12ec731bd485a68/pulsar-functions/worker/src/main/java/org/apache/pulsar/functions/worker/rest/api/ComponentImpl.java#L1472).
> > So, the role used to create the function must be an admin on the tenant,
> > but that role is then inherited and assigned to the function that's
> > created. So, every function in the Kubernetes runtime would at least have
> > admin privilege within its tenant.
> >
> > Is my understanding correct? Is there a way around this?
> >
> > Devin G. Bost
> >
> >
> > On Tue, Jan 25, 2022 at 4:42 PM Niclas Hedhman <ni...@hedhman.org> wrote:
> >
> > > 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 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..).
> > >
> > > Thank you, that helps a lot.
> > >
> > > Niclas
> > >
Re: Architecture of function authorization for process mode
Posted by Matteo Merli <ma...@gmail.com>.
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
<ma...@gmail.com>
On Fri, Feb 11, 2022 at 5:46 PM Devin Bost <de...@gmail.com> wrote:
>
> 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 function is created (
> https://github.com/apache/pulsar/blob/8496afc58bdd27c47cde8a9ba3c76b80ab796320/pulsar-functions/worker/src/main/java/org/apache/pulsar/functions/worker/rest/api/FunctionsImpl.java#L207)
> and saves it as the Kubernetes secret (
> https://github.com/apache/pulsar/blob/1ea381d02bf2c817547b4759b0dbf57366fd1358/pul[…]e/pulsar/functions/auth/KubernetesSecretsTokenAuthProvider.java
> <https://github.com/apache/pulsar/blob/1ea381d02bf2c817547b4759b0dbf57366fd1358/pulsar-functions/runtime/src/main/java/org/apache/pulsar/functions/auth/KubernetesSecretsTokenAuthProvider.java#L100>).
> When the function starts, it uses that secret for broker authentication.
> The problem is that the pulsar-admin create action requires the token to
> have a subject that matches an adminRole specified on that tenant (
> https://github.com/apache/pulsar/blob/7576a6594233f3ac9e20028db12ec731bd485a68/pulsar-functions/worker/src/main/java/org/apache/pulsar/functions/worker/rest/api/ComponentImpl.java#L1472).
> So, the role used to create the function must be an admin on the tenant,
> but that role is then inherited and assigned to the function that's
> created. So, every function in the Kubernetes runtime would at least have
> admin privilege within its tenant.
>
> Is my understanding correct? Is there a way around this?
>
> Devin G. Bost
>
>
> On Tue, Jan 25, 2022 at 4:42 PM Niclas Hedhman <ni...@hedhman.org> wrote:
>
> > 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 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..).
> >
> > Thank you, that helps a lot.
> >
> > Niclas
> >