Open
Description
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.
Metadata
Metadata
Assignees
Labels
No labels