[
https://issues.apache.org/jira/browse/KAFKA-12732?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Wayland Goodliffe updated KAFKA-12732:
--------------------------------------
Description:
I'm fairly sure that I've found an obscure configuration bug with mirrormaker
when using kerberos. Luckily there is an easy workaround.
I have tested the old mirrormaker in kafka v1.0.0, as well as mirrormaker 2 in
v2.8.0 (both legacy mode and otherwise) - so I think there's a good chance this
affects all versions.
The set up is as follows:
* consumer and producer both use
** security.protocol=SASL_SSL
** sasl.mechanism=GSSAPI
* consumer and producer are in the same realm, but have different
sasl.kerberos.service.name
** e.g. kafka-source and kafka-target
* you specify the service names via sasl.kerberos.service.name (rather than
serviceName in the jaas.conf)
** either in mm2.properties source.sasl.kerberos.service.name and
target.sasl.kerberos.service.name
** or for legacy mode in consumer.config and producer.config
Then
* mirrormaker uses the wrong service name in the second adminclient connection
when trying to validate the response ticket.
** note that it reports the correct values when it logs the client config, so
this is likely due to some hidden issue deeper in kerberos code.
* For example, in my case with 2.8.0, it would try to validate
kafka-source/target.host@REALM instead of validating
kafka-target/target.host@REALM
* The resultant exception was
KrbException: Server not found in Kerberos database (7) - LOOKING_UP_SERVER
** due to kafka-source not being defined for target.host
Workaround
* ensure you specify separate jaas.conf for consumer/producer via
sasl.jaas.config properties (instead of via -Djava.security.auth.login.config)
* Use the jaas.conf field serviceName to specify the correct values for the
brokers.
was:
I'm fairly sure that I've found an obscure configuration bug with mirrormaker
when using kerberos. Luckily there is an easy workaround.
I have tested the old mirrormaker in kafka v1.0.0, as well as mirrormaker 2 in
v2.8.0 (both legacy mode and otherwise) - so I think there's a good chance this
affects all versions.
The set up is as follows:
* consumer and producer both use
** security.protocol=SASL_SSL
** sasl.mechanism=GSSAPI
* consumer and producer are in the same realm, but have different
sasl.kerberos.service.name
** e.g. kafka-source and kafka-target
* you specify the service names via sasl.kerberos.service.name (rather than
serviceName in the jaas.conf)
** either in mm2.properties source.sasl.kerberos.service.name and
target.sasl.kerberos.service.name
** or for legacy mode in consumer.config and producer.config
Then
* mirrormaker uses the wrong service name in the second adminclient connection
when trying to validate the response ticket.
** note that it reports the correct values when it logs the client config, so
this is likely due to some hidden issue deeper in kerberos code.
* For example, in my case with 2.8.0, it would try to validate
kafka-source/target.host@REALM instead of validating
kafka-target/target.host@REALM
* The resultant exception was
KrbException: Server not found in Kerberos database (7) - LOOKING_UP_SERVERdue
to kafka-source not being defined for target.host
Workaround
* ensure you specify separate jaas.conf for consumer/producer via
sasl.jaas.config properties (instead of via -Djava.security.auth.login.config)
* Use the jaas.conf field serviceName to specify the correct values for the
brokers.
> Possible Kerberos configuration bug in mirrormaker
> --------------------------------------------------
>
> Key: KAFKA-12732
> URL: https://issues.apache.org/jira/browse/KAFKA-12732
> Project: Kafka
> Issue Type: Bug
> Components: mirrormaker
> Affects Versions: 1.0.0, 2.8.0
> Reporter: Wayland Goodliffe
> Priority: Minor
>
> I'm fairly sure that I've found an obscure configuration bug with mirrormaker
> when using kerberos. Luckily there is an easy workaround.
> I have tested the old mirrormaker in kafka v1.0.0, as well as mirrormaker 2
> in v2.8.0 (both legacy mode and otherwise) - so I think there's a good chance
> this affects all versions.
> The set up is as follows:
> * consumer and producer both use
> ** security.protocol=SASL_SSL
> ** sasl.mechanism=GSSAPI
> * consumer and producer are in the same realm, but have different
> sasl.kerberos.service.name
> ** e.g. kafka-source and kafka-target
> * you specify the service names via sasl.kerberos.service.name (rather than
> serviceName in the jaas.conf)
> ** either in mm2.properties source.sasl.kerberos.service.name and
> target.sasl.kerberos.service.name
> ** or for legacy mode in consumer.config and producer.config
> Then
> * mirrormaker uses the wrong service name in the second adminclient
> connection when trying to validate the response ticket.
> ** note that it reports the correct values when it logs the client config,
> so this is likely due to some hidden issue deeper in kerberos code.
> * For example, in my case with 2.8.0, it would try to validate
> kafka-source/target.host@REALM instead of validating
> kafka-target/target.host@REALM
> * The resultant exception was
> KrbException: Server not found in Kerberos database (7) - LOOKING_UP_SERVER
> ** due to kafka-source not being defined for target.host
> Workaround
> * ensure you specify separate jaas.conf for consumer/producer via
> sasl.jaas.config properties (instead of via -Djava.security.auth.login.config)
> * Use the jaas.conf field serviceName to specify the correct values for the
> brokers.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
