pulsar-commits mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From GitBox <...@apache.org>
Subject [GitHub] [pulsar] ivankelly commented on issue #3735: Implementing authentication for Pulsar Functions
Date Fri, 15 Mar 2019 18:33:48 GMT
ivankelly commented on issue #3735: Implementing authentication for Pulsar Functions
URL: https://github.com/apache/pulsar/pull/3735#issuecomment-473397683
   > I don't believe that is the correct design choice because now the runtime is making
assumptions on what the data in FunctionAuthData is. 
   What you are doing now in the case of KubernetesFunctionAuthProvider is premature generalization.
We only have one use case for it, and that's very clear in what methods are in the interface.
Something for vault with dynamic tokens (i think i figured out the workload for this btw)
would need something very different. 
   Generalization for this interface doesn't make sense even. The AuthProvider interface is
a way for the runtime to allow common rest code code to pass information to the common instance
code. But between these two points, everything is k8s specific. So we should treat it as such.
   > The current implementation KubernetesSecretsTokenAuthProvider stores the name of the
secret (pointer to it) in the data field of FunctionAuthData. That is an workflow establish
in KubernetesSecretsTokenAuthProvider because we cache the name via cacheAuthData in the function
metadata topic. How can we make that assumption for another FunctionAuthProvider impl?
   We can make this assumption for all k8s based auth providers, because secrets is the way
to pass around sensitive information in k8s.

This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
For queries about this service, please contact Infrastructure at:

With regards,
Apache Git Services

View raw message