[
https://issues.apache.org/jira/browse/KNOX-1740?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16876504#comment-16876504
]
Robert Levas commented on KNOX-1740:
------------------------------------
Submitted patch for v1.3.0 branch - [https://github.com/apache/knox/pull/108]
> Add Trusted Proxy Support to Knox
> ---------------------------------
>
> Key: KNOX-1740
> URL: https://issues.apache.org/jira/browse/KNOX-1740
> Project: Apache Knox
> Issue Type: Improvement
> Components: Server
> Reporter: Larry McCay
> Assignee: Robert Levas
> Priority: Major
> Fix For: 1.3.0
>
> Time Spent: 0.5h
> Remaining Estimate: 0h
>
> There are token exchange scenarios where an application may want to acquire a
> KnoxToken on behalf of a user authenticated by the application. We need to
> implement a version of the Hadoop Trusted Proxy/Impersonation pattern for
> Knox at the topology level.
> This includes:
> * Principal assertion method (possibilities: doAs query param, path segment
> within an API, HTTP header)
> * Config within topology for trusted principals, groups that they are
> allowed to impersonate, users that they are allowed to impersonate, ip
> address from which requests are expected
> * Make part of the identity assertion provider since this is the provider
> that determines which identity to assert to the down stream service
> * Config will need to be qualified by service due to the multiple services
> per topology
> Example to indicate which type of impersonation mechanism to use for a given
> service/s:
> {code:xml}
> <param>
> <name>impersonated.principal.path-segment</name>
> <value>KNOXTOKEN;credentials</value>
> </param>
> <param>
> <name>impersonated.principal.header</name>
> <value>*;SM_USER</value>
> </param>
> <param>
> <name>impersonated.principal.query-param</name>
> <value>WEBHDFS,HIVE;doas</value>
> </param>
> {code}
> Example to indicate trusted service principals, hosts, groups:
> {code:xml}
> <param>
> <name>knox.proxyuser.hive.hosts</name>
> <value>10.222.0.0/16,10.113.221.221</value>
> </param>
> <param>
> <name>knox.proxyuser.hive.users</name>
> <value>user1,user2</value>
> </param>
> <param>
> <name>knox.proxyuser.hive.groups</name>
> <value>users</value>
> </param>
> {code}
> Putting the above in identity assertion provider - or any providers for that
> matter will potentially impact sharing of provider configs.
> However, it is inappropriate to make it global config within gateway-site.xml
> as this would be bad across tenants and clusters - and therefore topologies.
> We could possibly extend the dispatch with enforcing the above and that would
> mean making them Service level params rather than identity assertion. We
> could also avoid the need to disambiguate the impersonated.principal
> mechanism by service.
> Example:
> {code:xml}
> <service>
> <role>KNOXTOKEN</role>
> <param>
> <name>impersonated.principal.query-param</name>
> <value>doas</value>
> </param>
> <param>
> <name>knox.proxyuser.hive.hosts</name>
> <value>10.222.0.0/16,10.113.221.221</value>
> </param>
> <param>
> <name>knox.proxyuser.hive.users</name>
> <value>user1,user2</value>
> </param>
> <param>
> <name>knox.proxyuser.hive.groups</name>
> <value>users</value>
> </param>
> </service>
> {code}
> Another possibility is to configure it within the services as described above
> and push the config up at deployment time so that it can be available to
> identity assertion without the config needed to be shared across all
> topologies sharing the provider-config.
> This last approach seems like a good approach even though it is leaking
> service config into providers. Currently, identity assertion is where the
> impersonation attempts are being scrubbed to avoid inadvertently allowing
> impersonation due to case sensitivity of query params and things like that.
> Extending that logic to only scrub when impersonation isn't allowed seems
> appropriate.
> Perhaps, this approach can be turned into a generic provider param service
> level override. Then the config is officially in identity assertion so it
> could be shared across topologies by configuring them within the provider and
> also added by services to allow for service level config to drive it and not
> affect other topologies that are sharing the same config.
> Example:
> {code}
> <service>
> <role>KNOXTOKEN</role>
> <param>
>
> <name>provider-param-override.identity-assertion.impersonated.principal.query-param</name>
> <value>doas</value>
> </param>
> <param>
>
> <name>provider-param-override.identity-assertion.knox.proxyuser.hive.hosts</name>
> <value>10.222.0.0/16,10.113.221.221</value>
> </param>
> <param>
>
> <name>provider-param-override.identity-assertion.knox.proxyuser.hive.users</name>
> <value>user1,user2</value>
> </param>
> <param>
>
> <name>provider-param-override.identity-assertion.knox.proxyuser.hive.groups</name>
> <value>users</value>
> </param>
> </service>
> {code}
> The idea above is that the deployment contributor of the service that has the
> above code would need to recognize the provider-param-override prefix and
> take the next portion within dots (identity-assertion here) to look up the
> provider with the given role and dynamically add the parm without the prefix.
> This would allow for override of config at the provider level or the addition
> of the config.
> Question is how to deal with the fact that the provider contributor has
> likely already pushed all the init params for the filters.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
