Knox is a proxy and as such does add overhead. At a simplistic level, this overhead can be broken down into five areas: Authentication and authorization - The additional time required to perform authentication and authorization. Connection creation - The additional time required to setup the connection between Knox and the backend service. Data transport - The additional time required physically move the request and response data through the Knox server unaltered. Request and response processing - The additional time imposed by processing done to the request and response data stream. SSL termination - The additional time imposed by SSL encryption if the direct connection to the service would otherwise not occur over a secure connection. We try to set expectations at around +0.5 to +1.0 in terms of overhead, yielding a 1.5x to 2.0x increase in overall response times. These types of numbers are of course highly generalized and may vary significantly based on the use case. For example, as you point for very small requests and responses the connection creation time may disproportionately dominate overall and produce a higher relative overhead. ... View more

Look for example at this HBase rule which does something similar to what I believe you are asking. This rule however will handle anything under **/hbase due to the ** in {path=**}. <rule dir="IN" name="WEBHBASE/webhbase/path/inbound" pattern="*://*:*/**/hbase/{path=**}?{**}"> <rewrite template="{$serviceUrl[WEBHBASE]}/{path=**}?{**}"/> </rule> You can certainly also write a pattern for a single file. I assume here that your service's role is MYSERVICE which is why it is upper case in the $serviceUrl[MYSERVICE] function. That could hypothetically look something like this: <rule dir="IN" name="MYSERVICE/myservice/logo" pattern="*://*:*/**/myservice/myLogo.png?{**}"> <rewrite template="{$serviceUrl[MYSERVICE]}/myLogo.png?{**}"/> </rule> I wasn't sure about including the ?{**} in the rewrite template to propagate the query parameters but it is a good idea to include it in the match pattern to make it as general as possible. If you didn't include the ?{**} in the rewrite template the query parameters would not be copied over from the original matched URL. Either behavior may be what you want. ... View more

Currently Knox uses the username returned by the authentication provider. This identity can then be manipulated by an identity-assertion provider. However at this time none of the "out of the box" identity-assertion providers support an ability to lower case the identity. This would however be very easy to implement and plug in "on site". It would require implementing a custom identity-assertion provider that essentially implements the mapUserPrincial method of org.apache.hadoop.gateway.identityasserter.common.filter.AbstractIdentityAssertionFilter in module gateway-provider-identity-assertion-common. The whole process of writing and hooking up a Knox extension plugin is described in Larry's blog. http://hortonworks.com/blog/adding-federation-provider-apache-knox/ This described a federation provider but the overall mechanism is similar. General details about Knox development can be found in the dev guide. http://knox.apache.org/books/knox-0-6-0/dev-guide.html ... View more

In the Knox <knox-home>/bin/gateway.sh file (e.g. /usr/hdp/current/knox-server/bin/gateway.sh) you will find a variable that can be populated with JVM memory settings. APP_MEM_OPTS="" For example, you could provide the values show below for an initial and max 2GB heap. Knox will need to be restarted for this to take effect. APP_MEM_OPTS="-Xms2g -Xmx2g" ... View more