METRON-1291: Kafka produce REST endpoint does not work in a Kerberized cluster #826
Conversation
| producerConfig.put("value.serializer", "org.apache.kafka.common.serialization.StringSerializer"); | ||
| producerConfig.put("request.required.acks", 1); | ||
| if (environment.getProperty(MetronRestConstants.KERBEROS_ENABLED_SPRING_PROPERTY, Boolean.class, false)) { | ||
| producerConfig.put("security.protocol", "SASL_PLAINTEXT"); |
There was a problem hiding this comment.
Shouldn't we pull this from the KAFKA_SECURITY_PROTOCOL environment variable? Looks like it's being set in metron-deployment/packaging/ambari/metron-mpack/src/main/resources/common-services/METRON/CURRENT/package/templates/metron.j2
There was a problem hiding this comment.
Is the KAFKA_SECURITY_PROTOCOL env variable guaranteed to be available on the the host where REST is installed? Either way I don't have a problem with making the Kafka security protocol configurable vs hard-coded. I would propose we manage it like the other REST properties though and put it in metron-deployment/packaging/ambari/metron-mpack/src/main/resources/common-services/METRON/CURRENT/package/templates/metron.j2 to ensure it's always available to REST. Would it make sense to remove the "kerberos.enabled" spring property in this case?
There was a problem hiding this comment.
Well, if metron.j2 were not available as environment variables for REST, how does metron-rest.sh get the spring profile to use (the METRON_SPRING_PROFILES_ACTIVE variable)?
There was a problem hiding this comment.
metron.j2 is always available to REST. KAFKA_SECURITY_PROTOCOL env variable may or may not be depending on if a Kafka Broker or Client is located on the same host (am I wrong?).
There was a problem hiding this comment.
KAFKA_SECURITY_PROTOCOL is carried through by metron.j2 (KAFKA_SECURITY_PROTOCOL="{{kafka_security_protocol}}"). Given that, we should be fine to use it here, I believe.
There was a problem hiding this comment.
I submitted a PR against your branch with my proposed solution to this. It fixes the issue for both the producer and consumer configs. If you choose to accept it, you can do it without my attribution.
There was a problem hiding this comment.
Thanks @cestella. Turns out this setting was already available so it was a simple change. I also added the default ("SASL_PLAINTEXT") to application.yml and adjusted the unit test.
|
The latest commit address the issue of making the Kafka security protocol configurable. I tested this in full dev after enabling Kerberos. |
|
+1 by inspection, great job. |
… cluster (merrimanr) closes apache#826
3 participants
Contributor Comments
This PR adds Kerberos support to the http://node1:8082/swagger-ui.html#!/kafka-controller/produceUsingPOST endpoint. This can be verified in full dev by enabling Kerberos and using that endpoint to produce a message. The same message should be returned with a call to the http://node1:8082/swagger-ui.html#!/kafka-controller/getSampleUsingGET endpoint (using the same topic).
I also added a unit test for the KafkaConfig class.
Pull Request Checklist
Thank you for submitting a contribution to Apache Metron.
Please refer to our Development Guidelines for the complete guide to follow for contributions.
Please refer also to our Build Verification Guidelines for complete smoke testing guides.
In order to streamline the review of the contribution we ask you follow these guidelines and ask you to double check the following:
For all changes:
For code changes:
Have you included steps to reproduce the behavior or problem that is being changed or addressed?
Have you included steps or a guide to how the change may be verified and tested manually?
Have you ensured that the full suite of tests and checks have been executed in the root metron folder via:
Have you written or updated unit tests and or integration tests to verify your changes?
If adding new dependencies to the code, are these dependencies licensed in a way that is compatible for inclusion under ASF 2.0?
Have you verified the basic functionality of the build by building and running locally with Vagrant full-dev environment or the equivalent?
For documentation related changes:
Have you ensured that format looks appropriate for the output in which it is rendered by building and verifying the site-book? If not then run the following commands and the verify changes via
site-book/target/site/index.html:Note:
Please ensure that once the PR is submitted, you check travis-ci for build issues and submit an update to your PR as soon as possible.
It is also recommended that travis-ci is set up for your personal repository such that your branches are built there before submitting a pull request.