Hello, Follow up question to <this>.. So it seem...
# general
d
Hello, Follow up question to this.. So it seems pretty clear to me, that when using mTLS auth, pulsar will not challenge a client to re-auth when a cert becomes expired. Not ideal, but something we could live with. What seems problematic though, is the following: 1. client auths with mTLS 2. cert expires there-after (but again, client stays authenticated. Again, we could live with this aspect) 3. broker restarts 4. client attempts to recorrect. INDEFINITELY My test case uses a basic CLI client (with all default config), and I get the below recurring logging: (where the pertinent logging is
Will try again
).
INFO  org.apache.pulsar.client.impl.ClientCnx - [id: 0x5cf0bd1e, L:/172.19.0.4:52208 ! R:pulsar-broker/172.19.0.3:6651] Disconnected
WARN  org.apache.pulsar.client.impl.ConnectionPool - [[id: 0x5cf0bd1e, L:/172.19.0.4:52208 ! R:pulsar-broker/172.19.0.3:6651]] Connection handshake failed: org.apache.pulsar.client.api.PulsarClientException: Connection already closed
WARN  org.apache.pulsar.client.impl.ConnectionHandler - [<persistent://foo/bar/in2>] [my-sub] Error connecting to broker: org.apache.pulsar.client.api.PulsarClientException: Connection already closed
WARN  org.apache.pulsar.client.impl.ConnectionHandler - [<persistent://foo/bar/in2>] [my-sub] Could not get connection to broker: org.apache.pulsar.client.api.PulsarClientException: Connection already closed -- Will try again in 54.958 s
I appreciate the cert should be rotated before expiring, but this seems a basic error scenario that should be handled better. And as per the docs - the broker [SHOULD] disconnect the client (and the
PulsarClientException
should imo be (eventually) thrown and not continually caught. This is what happens for example, when creating the initial connection with an already expired cert).
Any insights on using certs, etc. in relation to my 2 threads much appreciated, thanks
l
Very valuable comments and feedback. Would you have a chance to start driving improvements in this area?
4. client attempts to recorrect. INDEFINITELY
This was recently reported as https://github.com/apache/pulsar/issues/22026 For cerficate and token revocation there's https://github.com/apache/pulsar/issues/8525 which has been closed as stale. Please create a new issue to track the gap that you have.
Well it's possible that #8525 is actually about token key rotation where we have OIDC as the solution in Pulsar 3.0.
Please create a new GH issue
Contributions are more than welcome for making progress in resolving the issues.
d
Thanks for the feedback Lari. Ill get some Github issues opened
👍 1