Github user revans2 commented on the issue:
https://github.com/apache/storm/pull/2208
Sorry I have been out of town or I would have joined the conversation
sooner.
Yes @HeartSaVioR is correct. The code is really confusing and overly
complicated. I comes from when we were adding in security to storm. It is a
long story where we ran into several bugs/limitations in ZK itself that
prevented us from doing what we initial wanted to do. It also comes from the
really confusing way that ZK handles authentication.
ZK supports both SASL authentication which is per connection, and a special
digest authentication with can be per command and can override the connection
authentication if any. (don't confuse this special built in ZK digest
authentication with the SASL digest authentication which ZK also supports, as
they are different) SASL authentication with ZK is handled through the jaas
conf. There is a "Client" section that says how you want to authenticate with
the zookeeper servers. Using kerberos for this is the recommended way to
authenticate ZK as it very secure. STORM_ZOOKEEPER_AUTH_SCHEME allows you to
use the built in ZK digest auth scheme in the daemons. This is really only
there for testing purposes. Although it could work in production if you wanted
it to, it just will be no where near as secure as kerberos is.
One of the issues we ran into with allowing the workers to communicate with
ZK was that the workers needed some way to authenticate with ZK that didn't
expire. We could force everyone to send a TGT to the worker and then use that
to authenticate with ZK, but TGTs expire and so users would have to push a new
one periodically. So we made the decision that we would use the built in ZK
digest like a ticket. We would randomly generate a 128 bit number as the
secret, and then let nimbus setup the ACLs in ZK to only allow a user with that
128 bit secret to access the data.
That is how it currently works. We didn't really like that and wanted to
leave open the possibility of using a different auth scheme with ZK in the
future. That is why we have the configs as a string and not a boolean. If we
want to update the documentation for the cofnigs we can. But I would say for
now just mark them as being internal configs relating to security that the end
user should not actually set.
---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is enabled but not working, please
contact infrastructure at [email protected] or file a JIRA ticket
with INFRA.
---
