Support Pod's Kubernetes ServiceAccount for authenticating to the pulsar cluster

[zzzz465]

when the pulsar is installed on the Kubernetes cluster, it can use Kubernetes service account for authenticating.
ServiceAccount can be created by injecting and Secret, and they're different from each other.

{
  "header": {
    "alg": "RS256",
    "kid": "<kid>"
  },
  "payload": {
    "iss": "kubernetes/serviceaccount",
    "kubernetes.io/serviceaccount/namespace": "test-pulsar-resources",
    "kubernetes.io/serviceaccount/secret.name": "pulsar-connection-secret",
    "kubernetes.io/serviceaccount/service-account.name": "default",
    "kubernetes.io/serviceaccount/service-account.uid": "3df0c728-6810-4162-b9c7-ab9308cbe60c",
    "sub": "system:serviceaccount:test-pulsar-resources:default"
  },
  "signature": "<sig>"
}

this is decoded ServiceAccount jwt token that is created using Secret. As you see, there's a missing aud claim, and iss claim is different unlike ServiceAccount injected to pod. (the other have publically accessable issuer URL)

missing aud claim makes 401 authentication error, and since there's no way to make kubernetes to add aud claim to jwt, nor pass aud claim check on apache pulsar.

so for a workaround, I suggest pulsar resource operator use its ServiceAccount token for authenticating.

[martin31821]

I'll take a shot at implementing this and create a PR.

It would be best to extend the PulsarConnection CRD to also accept a ServiceAccount, then use the TokenRequest API of kubernetes to obtain a short-lived token and use that token to connect to pulsar.

It would then be the users responsibility to ensure that the resources-operator has the proper RBAC rules in place.