[
https://issues.apache.org/jira/browse/KNOX-1740?focusedWorklogId=270388&page=com.atlassian.jira.plugin.system.issuetabpanels:worklog-tabpanel#worklog-270388
]
ASF GitHub Bot logged work on KNOX-1740:
----------------------------------------
Author: ASF GitHub Bot
Created on: 01/Jul/19 18:15
Start Date: 01/Jul/19 18:15
Worklog Time Spent: 10m
Work Description: rlevas commented on pull request #106: KNOX-1740 - Add
Trusted Proxy Support to Knox
URL: https://github.com/apache/knox/pull/106
## What changes were proposed in this pull request?
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
- (Please fill in changes proposed in this fix)
## How was this patch tested?
```
mvn -T.5C verify -Prelease,package
...
[INFO]
------------------------------------------------------------------------
[INFO] BUILD SUCCESS
[INFO]
------------------------------------------------------------------------
[INFO] Total time: 16:00 min (Wall Clock)
[INFO] Finished at: 2019-07-01T13:58:13-04:00
[INFO] Final Memory: 280M/1728M
[INFO]
------------------------------------------------------------------------
```
Manually tested....
```
# kinit rlevas
rle...@example.com's password:
# curl -k --negotiate -u: -X GET
"https://knox.local:8443/gateway/dt/knoxtoken/api/v1/token?doAs=userA";
{"access_token":"eyJhbGciOiJSUzI...","endpoint_public_cert":"MIIDaD...","token_type":"Bearer","expires_in":1562008370648}%
```
```
# kinit jqpublic
jqpub...@example.com's password:
# curl -k --negotiate -u: -X GET
"https://knox.local:8443/gateway/dt/knoxtoken/api/v1/token?doAs=userA";
{
"RemoteException" : {
"message" : "User: jqpublic is not allowed to impersonate userA",
"exception" : "AuthorizationException",
"javaClassName" :
"org.apache.hadoop.security.authorize.AuthorizationException"
}
}%
```
----------------------------------------------------------------
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org
Issue Time Tracking
-------------------
Worklog Id: (was: 270388)
Time Spent: 10m
Remaining Estimate: 0h
> 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: 10m
> 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)
