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