You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@knox.apache.org by "Larry McCay (JIRA)" <ji...@apache.org> on 2018/11/27 22:48:00 UTC
[jira] [Comment Edited] (KNOX-1628) Provide new service definitions
for Ranger and Atlas to support trusted proxy
[ https://issues.apache.org/jira/browse/KNOX-1628?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16701129#comment-16701129 ]
Larry McCay edited comment on KNOX-1628 at 11/27/18 10:47 PM:
--------------------------------------------------------------
This is an incompatible change, AFAICT.
I think that we need to consider an approach that will result in the least amount of broken clients and a way to communicate the need to migrate away from the previous service definitions rather than upgrades having troubles.
For some additional context:
I believe that any existing topologies that are proxying access to the UI or API will suddenly have unexpected behavior since the Anonymous authentication provider isn't being forced by the service.xml anymore. The fact that it was overridden in the service definition previously means that they may have been included in topologies that have any number of authentication or federation providers in place and they will suddenly be engaged.
In addition, I believe that there is an added complication for unsecured clusters.
Trusted proxy support does not imply user.name/Simple authentication support for Atlas and Ranger.
Therefore, the previous behavior of needing the application to provide its own authentication will continue to be needed.
We have a couple possible approaches here - I think:
# New Service Name for Trusted Proxy Support (Secure Clusters Only) and Existing Service Names for Unsecure clusters and existing deployments in upgraded clusters
# Adding a new version to the existing Service definitions that will actually seem older rather than the latest. This will allow the majority of existing deployments to continue to use the old service definition and explicit action to add the version attribute to the service element in topologies that need trusted proxy behavior. This would require a version number like 0.1.2.0 rather than 1.2.0. We could then add a deprecation warning to the previous version.
If we need to keep both due to secure and unsecured clusters than #2 may be cumbersome unless we extend the service definition processing as discussed later in this (way too long) comment.
Perhaps, we should consider changes in the gateway handling of service definitions as well to ease this pain.
We have at least 3 or 4 services that will have this same migration pain: AMBARI, RANGER, ATLAS, ZEPPELIN maybe others?
A. have separate secure and unsecure service definitions? We know whether the gateway is kerberized on start and could add an optional redirection from a default service def to a secure service def and only wire up the secure one at deployment time.
B. add an optional sharing of rewrite rules across service definitions and service definition versions. The rewrite rules are not likely to be different for secure and unsecure clusters and keeping them in sync will be an unnecessary burden.
C. we may get B for free by just adding a new sercure-service.xml file to the latest service definition thereby providing both a new definition of authentication overrides or lack thereof as well as the use of the same rewrite rules.
was (Author: lmccay):
This is an incompatible change, AFAICT.
I think that we need to consider an approach that will result in the least amount of broken clients and a way to communicate the need to migrate away from the previous service definitions rather than upgrades having troubles.
For some additional context:
I believe that any existing topologies that are proxying access to the UI or API will suddenly have unexpected behavior since the Anonymous authentication provider isn't being forced by the service.xml anymore. The fact that it was overridden in the service definition previously means that they may have been included in topologies that have any number of authentication or federation providers in place and they will suddenly be engaged.
In addition, I believe that there is an added complication for unsecured clusters.
Trusted proxy support does not imply user.name/Simple authentication support for Atlas and Ranger.
Therefore, the previous behavior of needing the application to provide its own authentication will continue to be needed.
We have a couple possible approaches here - I think:
# New Service Name for Trusted Proxy Support (Secure Clusters Only) and Existing Service Names for Unsecure clusters and existing deployments in upgraded clusters
# Adding a new version to the existing Service definitions that will actually seem older rather than the latest. This will allow the majority of existing deployments to continue to use the old service definition and explicit action to add the version attribute to the service element in topologies that need trusted proxy behavior. This would require a version number like 0.1.2.0 rather than 1.2.0. We could then add a deprecation warning to the previous version.
If we need to keep both due to secure and unsecured clusters than #2 may be cumbersome unless we extend the service definition processing as discussed later in this (way too long) comment.
Perhaps, we should consider changes in the gateway handling of service definitions as well to ease this pain.
We have at least 3 or 4 services that will have this same migration pain: AMBARI, RANGER, ATLAS, ZEPPELIN maybe others?
A. have separate secure and unsecure service definitions? We know whether the gateway is kerberized on start and could add an optional redirection from a default service def to a secure service def and only wire up the secure one at deployment time.
B. add an optional sharing of rewrite rules across service definitions and service definition versions. The rewrite rules are not likely to be different for secure and unsecure clusters and keeping them in sync will be an unnecessary burden.
> Provide new service definitions for Ranger and Atlas to support trusted proxy
> -----------------------------------------------------------------------------
>
> Key: KNOX-1628
> URL: https://issues.apache.org/jira/browse/KNOX-1628
> Project: Apache Knox
> Issue Type: Improvement
> Reporter: Sailaja Polavarapu
> Assignee: Nixon Rodrigues
> Priority: Major
> Fix For: 1.3.0
>
> Attachments: 0001-KNOX-1628-Added-Atlas-service-defination-version-1.2.patch
>
>
> In order to support knox trusted proxy for Ranger & Atlas REST APIs, corresponding service.xml need to be updated or new version needs to be added. That way, the request contains doAs in the request parameter as well as the corresponding tokens instead of basic auth credentials of end user.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)