THIS IS A TEST INSTANCE. ALL YOUR CHANGES WILL BE LOST!!!!
Status
Current state: Proposed
Discussion thread: https://
JIRA: KNOX-NNNN
Motiviation
While Apache Knox aids in helping to lessen the need to gain physical access
to deployment machines, there are still numerous compelling reasons for users
to require such access:
1. Debugging, log access, etc
2. CLI use and automation
3. beeline and other clients that are deployed to gateway machines
Gaining access to a shell for these purposes currently requires the user to have
an ssh client installed and valid credentials that can be used for ssh, such as:
username and password or SSH keys. Separate management of credentials for this
access introduces some additional complexities which may even violate enterprise
infosec policies and require the secure distribution and management of keys.
The intent of this proposed improvement is to add a browser based terminal application
that will provide secure access to a shell on the Knox machine. Just as any resource
exposed by or hosted by Knox, you would be able to protect access to this terminal
with any of the available security providers. We would also like to make this
available out of the box as available from the Knox Homepage. This would make the
terminal/shell available via KnoxSSO thus providing shell access with your existing
enterprise credential authenticated SSO session.
Usecases
* UC-1: SSO for Secure Shell Access to Log Files
* UC-2: SSO for Secure Shell Access to Service CLIs
UC-1: SSO for Secure Shell Access to Log Files
Let's assume a debugging scenario and a user needs access to the gateway logs.
The user navigates to the Knox Homepage in order to get to the hosted services,
APIs and applications. The browser is redirected to KnoxSSO and user challenged
for enterprise credentials. Upon successful authentication, the user is redirected
back to the Homepage and presented with a page with topology endpoints and general
proxy information. Within the general proxy information section a link to a secure
shell will be presented - when configured to be enabled. The user clicks this link
and is presented with an xterm based shell in their browser. The user's uid on
the server side for the shell represented in the browser will need to be set to
that of the authenticated user (see resources for example code, articles).
NOTE: This will require Knox to be allowed to set uid's and may require some root
priveledge that needs to be acquired. This is a challenge and listed as an open
question below.
Once in a terminal within the browser, the user is able to invoke OS commands
to navigate to the {GATEWAY_HOME}/logs/gateway.log and gateway-audit.log files.
The user may use any other commands in the terminal to interrogate the log files:
grep, more, vi, etc.
UC-2: SSO for Secure Shell Access to Service CLIs
Let's assume a debugging scenario and a user needs access to the gateway logs.
The user navigates to the Knox Homepage in order to get to the hosted services,
APIs and applications. The browser is redirected to KnoxSSO and user challenged
for enterprise credentials. Upon successful authentication, the user is redirected
back to the Homepage and presented with a page with topology endpoints and general
proxy information. Within the general proxy information section a link to a secure
shell will be presented - when configured to be enabled. The user clicks this link
and is presented with an xterm based shell in their browser. The user's uid on
the server side for the shell represented in the browser will need to be set to
that of the authenticated user (see resources for example code, articles).
NOTE: This will require Knox to be allowed to set uid's and may require some root
priveledge that needs to be acquired. This is a challenge and listed as an open
question below.
Once in a terminal within the browser, they user is able to invoke OS commands
to kinit for access to kerberized resources.
The user will kinit with either username and password as a KDC user or with a keytab
file provisioned for their use and for which they have access via file permissions.
The user will then be able to use hadoop -dfs commands, beeline, pyspark, etc.
Open Questions
1. How will Knox set the UID for the authenticated user and how will it not change
the UID of the Knox server itself?