knox-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Ed Kohlwey (JIRA)" <j...@apache.org>
Subject [jira] [Commented] (KNOX-250) SSH Bastion Auditing Functionality
Date Wed, 12 Mar 2014 20:44:43 GMT

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

Ed Kohlwey commented on KNOX-250:
---------------------------------

Larry, I've been familiarizing myself with a lot of the API's as I go along - so I'm not really
taking the time to put together design documentation as I've found that a lot of my initial
assumptions about how Knox might work are being invalidated as I go along. If the comment
above isn't detailed enough, let me know what you'd like to know more about and I'll happily
throw something together.

I am actually using the Knox audit functionality already, and have done what seems to make
intuitive sense (the actual rubber hits the road in TerminalAuditor.java). Expressing a command
as a resource is sort of awkward, but I have made an attempt.

It is not working yet - I'm finishing up a few areas and will be writing integration tests
at a minimum before attempting a deployment on the knox environment I have set up for our
new cluster.

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

Mime
View raw message