[
https://issues.apache.org/jira/browse/STORM-346?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14074762#comment-14074762
]
ASF GitHub Bot commented on STORM-346:
--------------------------------------
Github user Parth-Brahmbhatt commented on a diff in the pull request:
https://github.com/apache/incubator-storm/pull/190#discussion_r15417963
--- Diff: storm-core/src/clj/backtype/storm/daemon/nimbus.clj ---
@@ -1046,7 +1047,10 @@
(dissoc storm-conf
STORM-ZOOKEEPER-TOPOLOGY-AUTH-SCHEME STORM-ZOOKEEPER-TOPOLOGY-AUTH-PAYLOAD))
total-storm-conf (merge conf storm-conf)
topology (normalize-topology total-storm-conf topology)
+ nimbus-autocred-plugins
(AuthUtils/getNimbusAutoCredPlugins total-storm-conf)
--- End diff --
I have a few questions:
* Shouldn't the plugin be cleared up as soon as the scope of submit
topology is over?
* If we generate these instances at startup then it means anyone wanting to
use it will have to change the nimbus config and restart nimbus. Right now the
restart is required because renewers are designed that way. I could follow that
pattern however I think this approach is better because no restart is required
as long as all the hdfs configuration files are already in the class path.
If you like to stick to this approach I can change the code so the list of
plugins are loaded at startup and stored in nimbus data structure and their
populateCred method is invoked as part of submit topology.
We need some way of identifying who the topology submitter is. Without that
information we don't know for whom are we getting the creds. I can pass just
the topology config and I think any future implementations of the interface
would also need that. I could make the config immutable thus ensuring the user
code can not modify it, does that work ?
> (Security) Oozie style delegation tokens for HDFS/HBase
> -------------------------------------------------------
>
> Key: STORM-346
> URL: https://issues.apache.org/jira/browse/STORM-346
> Project: Apache Storm (Incubating)
> Issue Type: Bug
> Reporter: Robert Joseph Evans
> Assignee: Parth Brahmbhatt
> Labels: security
>
> Oozie has the ability to fetch delegation tokens on behalf of other users by
> running as a super user that can become a proxy user for almost anyone else.
> We should build one or more classes similar to AutoTGT that can fetch a
> delegation token for HDFS/HBase, renew the token if needed, and then once the
> token is about to permanently expire fetch a new one.
> According to some people I have talked with HBase may need to have a JIRA
> filed against it so that it can pick up a new delegation token without
> needing to restart the process.
--
This message was sent by Atlassian JIRA
(v6.2#6252)
