KAFKA-4589: SASL/SCRAM documentation#2369
KAFKA-4589: SASL/SCRAM documentation#2369rajinisivaram wants to merge 3 commits intoapache:trunkfrom
Conversation
|
This is currently a commit on top of the docs for |
|
Refer to this link for build results (access rights to CI server needed): |
|
Refer to this link for build results (access rights to CI server needed): |
gwenshap
left a comment
There was a problem hiding this comment.
LGTM. One minor phrasing change.
There was a problem hiding this comment.
The phrasing is a bit awkward - "We support SASL (Kerberos), and then we added SASL/PLAIN and then we added SASL/SCRAM". Almost makes it seem like the additional protocols are an afterthought and may deter usage.
Perhaps just something like this will be clearer:
We support the following mechanisms:
- SASL/KERBEROS - starting at version 0.9.0.0
- SASL/PLAIN - starting at version 0.10.0.0
- SASL/SCRAM-SHA-256 and SASL/SCRAM-SHA-512 - starting at version 0.10.2.0
There was a problem hiding this comment.
@gwenshap Thank you for the review and the suggestion. I have updated the doc.
|
Refer to this link for build results (access rights to CI server needed): |
|
Refer to this link for build results (access rights to CI server needed): |
|
Refer to this link for build results (access rights to CI server needed): |
|
Refer to this link for build results (access rights to CI server needed): |
|
+1 |
There was a problem hiding this comment.
One question about this: why did we do 2 separate mechanisms instead of a single mechanism with a config for the hashing algorithm used? It's a bit late to be asking this, but this hasn't been released yet, so there's still a bit of time. :)
There was a problem hiding this comment.
@ijuma SCRAM mechanism names are defined in RFC-5802 (https://tools.ietf.org/html/rfc5802#section-4). So we are using the standard name rather than defining our own.
There was a problem hiding this comment.
That makes sense, thanks for the explanation.
|
cc @junrao since he reviewed the main PR. |
d4c32c7 to
7d36f13
Compare
|
@ijuma I have rebased this on top of the JAAS doc. Also, in the second commit in this PR (to make it easy to undo if required), I have tried to remove duplication. Not sure if I have made it better or worse. Can you take a look, please? Thank you! |
|
Refer to this link for build results (access rights to CI server needed): |
|
Refer to this link for build results (access rights to CI server needed): |
|
Refer to this link for build results (access rights to CI server needed): |
junrao
left a comment
There was a problem hiding this comment.
@rajinisivaram : Thanks for the patch. Left a couple of comments.
| The login module describes how the clients like producer and consumer can connect to the Kafka Broker. | ||
| The following is an example configuration for a client for the SCRAM mechanisms: | ||
| <pre> | ||
| asl.jaas.config=org.apache.kafka.common.security.scram.ScramLoginModule required \ |
There was a problem hiding this comment.
missing an s at the beginning?
| <li>Kafka supports only the strong hash functions SHA-256 and SHA-512 with a minimum iteration count | ||
| of 4096. Strong hash functions combined with strong passwords and high iteration counts protect | ||
| against brute force attacks if Zookeeper security is compromised.</li> | ||
| <li>SCRAM should be used only with TLS-encryption to prevent interception of SCRAM exchanges. This |
There was a problem hiding this comment.
Hmm, does SCRAM need to be used with TLS? I thought the main advantage of SCRAM over PLAIN is that you don't need to encrypt the wire transfer since it's hard to compromise the password even if the wire transfer is intercepted.
There was a problem hiding this comment.
@junrao Thank you for the review. SCRAM is safe against replay attacks and the information obtained using interception is not sufficient to impersonate a client. Offline brute force attacks can be used with the intercepted data to try to recover the user's password, but this is mitigated with the use of strong hash functions, strong passwords etc.
If Zookeeper (the SCRAM credential store) security is compromised, then the intercepted data from a PLAINTEXT connection combined with the stored credential in Zookeeper can be used to impersonate the client. To protect against this, it is recommended that SCRAM is used with TLS. I think we should encourage the use of TLS in the docs so that anyone using PLAINTEXT with SCRAM looks more into the security considerations and understands the risks.
| a login module in <tt>KafkaClient</tt> for the selected mechanism as described in the examples | ||
| for setting up <a href="#security_sasl_kerberos_clientconfig">GSSAPI (Kerberos)</a>, | ||
| <a href="#security_sasl_plain_clientconfig">PLAIN</a> or | ||
| <a href="#security_sasl_scram_clientconfig">SCRAM</a></li>. |
|
Refer to this link for build results (access rights to CI server needed): |
|
Refer to this link for build results (access rights to CI server needed): |
|
Refer to this link for build results (access rights to CI server needed): |
|
Thanks for the patch. LGTM |
Author: Rajini Sivaram <rajinisivaram@googlemail.com> Reviewers: Ismael Juma <ismael@juma.me.uk>, Gwen Shapira <cshapi@gmail.com>, Sriharsha Chintalapani <harsha@hortonworks.com>, Jun Rao <junrao@gmail.com> Closes #2369 from rajinisivaram/KAFKA-4589 (cherry picked from commit 666abaf) Signed-off-by: Jun Rao <junrao@gmail.com>
Author: Rajini Sivaram <rajinisivaram@googlemail.com> Reviewers: Ismael Juma <ismael@juma.me.uk>, Gwen Shapira <cshapi@gmail.com>, Sriharsha Chintalapani <harsha@hortonworks.com>, Jun Rao <junrao@gmail.com> Closes apache#2369 from rajinisivaram/KAFKA-4589
No description provided.