[jira] [Comment Edited] (KNOX-250) SSH Bastion Auditing Functionality

["Ed Kohlwey (JIRA)" <ji...@apache.org>]

    [ https://issues.apache.org/jira/browse/KNOX-250?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13932306#comment-13932306 ] 

Ed Kohlwey edited comment on KNOX-250 at 3/12/14 8:46 PM:
----------------------------------------------------------

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 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.



was (Author: ekohlwey):
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)