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: [email protected] With regards, Apache Git Services
