You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
I noticed that the microservices hard-code the notion of using SASL PLAIN authentication, with a username of 'token', if an API key is provided (and optionally, the certificate to use to verify the server).
It appears this is sufficient for connecting to Event Streams. However, we might want to be more flexible if (for example) connecting to a Kafka created by Strimzi, which does not allow the use of PLAIN authentication (they support either mutual TLS, or SCRAM-SHA-512, which is effectively username and password).
This would require that the sasl.mechanism and username are configurable. I haven't looked at mutual TLS yet, but I imagine this would require injection of a client certificate instead of a username and password.
The text was updated successfully, but these errors were encountered:
I noticed that the microservices hard-code the notion of using SASL PLAIN authentication, with a username of 'token', if an API key is provided (and optionally, the certificate to use to verify the server).
It appears this is sufficient for connecting to Event Streams. However, we might want to be more flexible if (for example) connecting to a Kafka created by Strimzi, which does not allow the use of PLAIN authentication (they support either mutual TLS, or SCRAM-SHA-512, which is effectively username and password).
This would require that the sasl.mechanism and username are configurable. I haven't looked at mutual TLS yet, but I imagine this would require injection of a client certificate instead of a username and password.
The text was updated successfully, but these errors were encountered: