Currently Knox does not currently support proxying the Ranger UI. If/when Knox does support proxying the Ranger UI you are correct that it may be impossible to access the Ranger UI via Knox if the Range/Knox agent is installed and if the required users have not already been granted access. Presumably setting up the required policies would be done before hand or from "within" the cluster and not via Knox. ... View more

The answer is going to depend on exactly what you are looking for. Knox has a general purpose WebAppSercurityProvider that currently supports layering Cross Site Request Forgery (CSRF) protection onto any of the REST APIs Knox currently supports. The WebAppSecurityProvider is also extensible to so that support for other common WebApp vulnerabilities could be developed and plugged in. Knox does not currently have any support for layering injection vulnerability protection to the supported REST APIs. This is possible for some services given the architecture but would require a much tighter coupling between Knox and those services than would be ideal. Can you please clarify what you mean by "broken authentication" before I tackle that one? ... View more

Thinking about running it "within Hadoop" may be the wrong way to think about it. From a Knox perspective "within Hadoop" is usually discussed from a security perspective. This means that everything "within Hadoop" is protected by the same firewall setup, same Kerberos configuration, etc. It is really just a collection of hosts dedicated to the various components that make up the solution. So in your case the Tomcat hosted API could simply run on one of the hosts that is part of the infrastructure dedicated to Hadoop. This API would be accessed via Knox which would be running on one of the hosts considered to be at the "permitter" from a network security perspective. All of the above being said, it is actually possible to run your Jetty or Tomcat hosted API "on Hadoop" via Slider. In this case the life-cycle of your API server would be managed by Hadoop. This would present some challenges from a Knox perspective as the Hadoop resource manager YARN may run your API server on any compute node in the Hadoop cluster making the Knox configuration challenging. ... View more

In your rewrite.xml you can use a rewrite function to retrieve the current effective username. You can see an example of this in WebHDFS. {code} <rule dir="IN" name="WEBHDFS/webhdfs/inbound/namenode/home/file" pattern="*://*:*/**/webhdfs/{version}/~/{path=**}?{**}"> <rewrite template="{$serviceUrl[WEBHDFS]}/{version}/user/{$username}/{path=**}?{**}"/> </rule> {code} However password is a different matter. There are several issues with this. Depending upon the authorization provider there may be no password. The general Knox model is to protect the password not to make it easy to access. So from this perspective perhaps we need to understand your use case a bit better to determine if there is a different way to accomplish your goals. Without more information I'm guessing you actually need a trusted proxy model where your target service needs to trust that Knox has pre-authenticated the user and therefore only the username is required. ... View more