[
https://issues.apache.org/jira/browse/KNOX-250?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13932306#comment-13932306
]
Ed Kohlwey commented on KNOX-250:
---------------------------------
I'd be interested in hearing about any thoughts folks have, especially around
the handling of logging (see TerminalAuditThread.java), kerberos-based
authentication logging (KnoxUserAuthGSS.java), the shell interpreter
(ShellInterpreterThread.java), and longer-term strategies for obtaining
delegation tokens for the user (I am not sure I will implement that in this
first cut).
This implementation has a simple REPL that takes two commands (connect and
help) which do the obvious things. The commands are designed in a modular way
so that other folks can add things like opening the Knox DSL shell or whatever
they might be interested in adding.
This uses a buffered reader to read in input from the user's ssh session and
either routes the input to the REPL or a remote host (depending on application
state - conencted, not connected). When using the connect command to connect to
hosts in a topology, the buffer gets forked using a ReaderInputStream and
TeeInputStream. One branch is written to console input on the remote host and
one branch is logged using the knox auditor.
The connect command will log in to remote hosts using a configurable SSH
keypair as the knox user using passwordless ssh private keys, then sudo to the
correct remote user. I'm planning to force the user to kinit in the first
implementation, but will look at delegation tokens as a solution in the longer
term. It seems that locating the correct libraries for Hadoop will be a task
that is very difficult, and it might make more sense to work to update Hadoop's
REST API's instead. Using the WebHDFS API to obtain a HDFS token makes a lot of
sense and is very easy in the context of Knox, but I'm not sure of an effective
way to obtain a job submission token (or if the namenode is also capable of
providing that functionality -- I was unable to find any evidence that it can,
or that YARN has a restful API for creating tokens).
Again, any feedback is appreciated.
> SSH Bastion Auditing Functionality
> ----------------------------------
>
> Key: KNOX-250
> URL: https://issues.apache.org/jira/browse/KNOX-250
> Project: Apache Knox
> Issue Type: New Feature
> Reporter: Ed Kohlwey
>
> It would be nice for Knox to provide SSH tunneling and auditing functionality
> in addition to the rest gateway services it provides. This would help Knox be
> a single-stop for cluster audit logging requirements.
> Larry McCay provided the following design guidance via the mailing list
> related to an implementation:
> * Apache Mina SSHD Knox Provider (providers are great for introducing
> configuration, filters, listeners, etc.)
> * Each topology (which represents a managed Hadoop cluster) may configure
> an optional sshd-provider
> * The sshd-provider would likely require a ShellFactory that sets up a
> tunneling client into the target cluster (perhaps with the sshd client
> component)
> * The sshd-provider ShellFactory would need to resolve the appropriate
> Hadoop client configuration for it's intended Hadoop cluster
> * The sshd-provider would expose a separate ssh port per cluster for users
> to connect to
--
This message was sent by Atlassian JIRA
(v6.2#6252)
