pulsar-commits mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From GitBox <...@apache.org>
Subject [GitHub] [pulsar] jerrypeng commented on issue #3735: Implementing authentication for Pulsar Functions
Date Fri, 15 Mar 2019 18:20:41 GMT
jerrypeng commented on issue #3735: Implementing authentication for Pulsar Functions
URL: https://github.com/apache/pulsar/pull/3735#issuecomment-473393406
 
 
   @ivankelly responding to your comments
   
   > First of all, service accounts are not needed, you can attached the secret directly
to the stateful set. In fact, thats exactly what you are doing. service accounts are for pods
to authenticate with k8s services. We're not doing that, and we don't need to do that for
this implementation. It may be needed for vault at a later stage, but let's not make assumptions
about how that'll be used until we have concretely worked out the flow for that.
   
   let me experiment with not having a service account and see if that works
   
   > Secondly, i don't think we need an interface for attaching the secret to the stateful
set. Whatever the auth data is that we are passing in, we should assume it is secret, so if
there is auth data, the k8s runtime should attach that as a secret. Then it is up to configureAuthenticationConfig
to know how to do something with that authData. So we should move the attachment of the secret
volume and the mount into the k8s runtime itself.
   
   I don't believe that is the correct design choice because now the runtime is making assumptions
on what the data in FunctionAuthData is.  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?  I could have implemented another version of a Kubernetes
Function Authentication Provider that puts the actual token in the data field of FunctionAuthData
and set it explicitly as a env variable in the pod spec.  While that approach might not be
secure, I would like implementations to have that flexibility and not to pigeon hole implementation
to a certain workflow.

----------------------------------------------------------------
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:
users@infra.apache.org


With regards,
Apache Git Services

Mime
View raw message