[WFLY-14987] Use Elytron SSLContext to connect to secure Kafka #411
Conversation
kabir
force-pushed
the
WFLY-14987-reactive-messaging-sslcontext
branch
from
ff83ad2 to
a4ff52c
Compare
microprofile/WFLY-14987_reactive_messaging-ssl-context-kafka-connector.adoc
Outdated
Show resolved
Hide resolved
microprofile/WFLY-14987_reactive_messaging-ssl-context-kafka-connector.adoc
Outdated
Show resolved
Hide resolved
microprofile/WFLY-14987_reactive_messaging-ssl-context-kafka-connector.adoc
Show resolved
Hide resolved
kabir
force-pushed
the
WFLY-14987-reactive-messaging-sslcontext
branch
2 times, most recently
from
0f294e1 to
266875b
Compare
|
|
||
| These properties are used by the Apache Kafka client as input for creating a `javax.net.ssl.SSLContext`, which in turn is used to create a `javax.net.ssl.SSLEngine` for the secure connection. | ||
|
|
||
| This RFE proposes that in addition to the above approach to configure the `SSLContext`, we also provide the ability to set up an `SSLContext` via the `/subsystem=elytron/client-ssl-context=*` management resources in WildFly and to have a custom property to make the Kafka client connection use such an SSLContext. |
There was a problem hiding this comment.
Do I understand correctly that this is happening in WildFly integration and not in Smallrye MP Reactive messaging implementation? In other words Smallrye implementation does not depend on Elytron. And in other words this feature is cant be used somewhere else, e.g. Quarkus.
There was a problem hiding this comment.
Yes, this is all in WildFly
| == Test Plan | ||
| At the moment, it looks like the tests for this will need to reside in QE's testsuite. | ||
|
|
||
| The issue is that we are currently using the Spring embedded Kafka test utility for testing the Kafka integration which does not have the required hooks. testcontainers.org is also popular but requires users have a running version of Docker on their machines, which is not the case for our CI. |
There was a problem hiding this comment.
Hi @kabir, btw - reasons for not introducing testcontainers.org into WF TS due to lack of docker in CI is being broken by this PR https://github.com/wildfly/wildfly/pull/14604/files#diff-f1df13354db56727fb043478c855f938dcf79cd9b288c542c4b0262399d52cdeR76. So we shall probably reevaluate this reasoning :)
There was a problem hiding this comment.
@jstourac although the test added by the PR fails :) I presume that is the one needing test containers, but haven't checked :)
|
|
||
| The issue is that we are currently using the Spring embedded Kafka test utility for testing the Kafka integration which does not have the required hooks. testcontainers.org is also popular but requires users have a running version of Docker on their machines, which is not the case for our CI. | ||
|
|
||
| I looked into forking the Spring utility, but noticed that the system property needed to set up JAAS (`-Djava.security.auth.login.config`) is read at JVM boot. Also, Zookeeper and Kafka need a separate config file for JAAS, and that config file must be specified on JVM startup via a system property. Hence enhancing the embedded Kafka used by the current WildFly tests does not look practical at the moment without writing a lot of process wrappers and starting them as external processes. |
There was a problem hiding this comment.
Would it be possible to leverage Configuration.html#setConfiguration(javax.security.auth.login.Configuration), as we do on several places in WF already?
There was a problem hiding this comment.
Now I am thinking. Why we are bothering with JAAS here, when RFE is about SSL, which does not relate to SASL authentication.
Would it be possible to write test in WF TS, when we do not care about authentication (JAAS) but just about SSL?
There was a problem hiding this comment.
JAAS is needed for the integration with RHOSAK, but perhaps that can be tested as part of one of the other RFEs now that you mention it.
The SSL context then I guess is needed to reference the truststore to accept the certificate.
I would need to look into this Configuration thing you mention, since it is new to me. I have created https://issues.redhat.com/browse/WFLY-15283 to add the test (if possible)
There was a problem hiding this comment.
The SSL Context test PR is here wildfly/wildfly#14665. Re JAAS, there is no special handling of that on our side, we just pass properties on to SmallRye Reactive Messaging
|
In general can we keep in mind, this proposal has been open for two months and code freeze is now one day away. |
| user_admin="admin-secret"; | ||
| }; | ||
| Client { | ||
| org.apache.zookeeper.server.auth.DigestLoginModule required |
There was a problem hiding this comment.
I just want to double check,that mixing DigestLoginModule and PlainLoginModule is what is expected here. Sounds to me strange Plain and Digest should work together, but I definitely do not see deep into it.
There was a problem hiding this comment.
@mchoma I am not a security expert and it has been so long since I looked into this. However, from my notes I found I was inspired by https://docs.vmware.com/en/VMware-Smart-Assurance/10.1.0/sa-ui-installation-config-guide-10.1.0/GUID-DF659094-60D3-4E1B-8D63-3DE3ED8B0EDF.html so I think it is correct. I think possibly the Plain stuff is for Zookeeper/Kafka communication and Digest is for clients and Kafka communication.
There was a problem hiding this comment.
Yes, I assumed it is something like that. Just wanted to make sure.
kabir
force-pushed
the
WFLY-14987-reactive-messaging-sslcontext
branch
from
266875b to
5791c65
Compare
kabir
force-pushed
the
WFLY-14987-reactive-messaging-sslcontext
branch
from
5791c65 to
6b8fa1c
Compare
|
Just placing on hold so we can merge with the backport. |
https://issues.redhat.com/browse/WFLY-14987