[
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)
