Hi Ed - Thanks for the interesting thoughts.
Unfortunately, I don't think that have the full picture of what you are thinking in my mind yet. Let's leave out the implementation options and talk purely about the usecase for a second. * You have a set of users (what are their roles - sounds like admins of some sort?) * You'd like them to be able to gain access to the cluster through Knox (Knox is obviously a REST API Gateway) * What is it that these particular users need to do? * When you say "the user could interact normally with Hadoop" - do you mean that they have shell access for running the hadoop CLI's - eg: "hadoop fs -l /tmp"? * are you assuming a browser based application for this or is this a Knox CLI extension? When we were first talking about the ClientDSL we briefly considered using Apache Mina sshd but it didn't seem necessary given that we are able to use the REST APIs remotely. Again, if you can articulate the (a) usecase end to end that would be a great starting place. Thanks again for your ideas! I look forward to contributions from you on this. --larry On Tue, Feb 4, 2014 at 4:22 PM, Ed Kohlwey <[email protected]> wrote: > I'm interested in implementing a knox service that implements full shell > access to hosts within a hadoop cluster. The point of doing so is to > provide administrative auditing capability for all cluster user accounts, > including privileged users. A smaller number of users would have access to > the knox host than the full cluster. > > My current thinking on how to do this is to implement a servlet. Using a > GET or POST request, the request body would be passed to standard in, and > the response body would contain standard out. Knox itself would use ssh > public key based login to connect as a knox user to the other cluster > hosts, and then use a combinaiton of sudo and exec commands to change the > shell to the appropriate user. Knox would set up a hadoop delegation token > so the user could interact normally with Hadoop. > > Another option could be to start a java based SSH server on another > (non-22) port and perform normal tunneling, probably by adding an > interactive shell that asks what host the user would like to connect to. > This has the advantage of basically looking like a normal SSH connection. > > I noticed this is not how the Knox DSL is implemented, which seems to use > some session state. Can anyone discuss the motivations for doing this? Does > the community have any opinions on how best to go about providing audited > secure shell access? >
