[
https://issues.apache.org/jira/browse/KNOX-1740?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Larry McCay updated KNOX-1740:
------------------------------
Description:
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:java}
<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:java}
<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.
was:
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:java}
<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:java}
<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}
> 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: Larry McCay
> Priority: Major
> Fix For: 1.3.0
>
>
> 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:java}
> <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:java}
> <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.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
