Can you give me information about what exactly is checked and when this warning is actually displayed? I have this message only in the connectors-bundle container.
I’m not 100% sure, but I think it’s a warning that you send credentials like an authentication token with confidential user information in a plain http request.
On the wire, you can see the values of the token (They are usually Base64 encoded).
You should send those values over an encrypted wire like a https connection.
Hi @Ingo_Richtsmeier,
the problem is, that this is basically a internal kubernetes connection between the connectors and the operate component. So it’s possible to add a tls encryption, but anyway it shouldn’t flood the whole log file with a warning every second. Is there a way to disable it?
Hey @lukas-beumer - I’ve been doing some digging on this, and Ingo is definitely correct: messages are being sent over HTTP rather than HTTPS, which means that it’s possible to sniff the token and perform a man-in-the-middle attack. However, as you rightly pointed out, this communication is happening within your cluster, which greatly minimizes that risk.
One immediate workaround is to adjust the log levels. I’ve asked around here at Camunda to see what else I can find, and whether there’s a way to disable just this one warning or not. I’ll let you know what I learn!
Unfortunately, this probably does not work as desired. In this case, the flooding of the logs only affects “camunda/connectors” containers. Here, however, the same component is probably used.
I can try it on the container only with an environment variable, which I have adapted to the pattern as follows:
Unfortunately this didn’t work for me; just in case, I tried a few different formats of the variable name and none seemed to affect the output. I’m going to keep looking and asking around!
I spoke too soon - I think I found the correct configuration. @lukas-beumer, try adding this environment variable to your Connector container configuration:
Works like a charm! In the connectors bundle container there’s a start.sh loading some values. Seems JAVA_OPTS must be used, but your parameter is working.
connectors@camunda-platform-connectors-5b8bd88f77-5r9fw:/$ cat start.sh
#!/bin/bash
JAVA_OPTS="${JAVA_OPTS}"
# Explicitly set trust store location
if [[ -n "${JAVAX_NET_SSL_TRUSTSTORE}" ]]; then
JAVA_OPTS="${JAVA_OPTS} -Djavax.net.ssl.trustStore=${JAVAX_NET_SSL_TRUSTSTORE}"
fi
# Explicitly set trust store password
if [[ -n "${JAVAX_NET_SSL_TRUSTSTOREPASSWORD}" ]]; then
JAVA_OPTS="${JAVA_OPTS} -Djavax.net.ssl.trustStorePassword=${JAVAX_NET_SSL_TRUSTSTOREPASSWORD}"
fi
if [[ -n ${DEBUG_JVM_PRINT_JAVA_OPTS} ]]; then
echo "Applied JVM options: $JAVA_OPTS"
fi
exec java ${JAVA_OPTS} -cp "/opt/app/*:/opt/custom/*" "io.camunda.connector.runtime.app.ConnectorRuntimeApplication"
connectors@camunda-platform-connectors-5b8bd88f77-5r9fw:/$ ps aux
USER PID %CPU %MEM VSZ RSS TTY STAT START TIME COMMAND
connect+ 1 21.3 0.8 6030604 279104 ? Ssl 05:49 0:27 java -Dlogging.level.io.camunda.zeebe.client.impl.ZeebeCallCredentials=ERROR -Djavax.net.ssl.trustStore=/cert/keystore.jks -cp /opt/app/*:/opt/custom/* io.camunda.connector.runtime.app.ConnectorRuntimeApplication
Glad to hear it @lukas-beumer! It was working in my local environment when I used JAVA_TOOL_OPTIONS but I agree that it’s confusing. I’ll work with the engineering team to get some better clarity around this option and how best to use it.
