[
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: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}
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: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}
> 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: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}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
