[
https://issues.apache.org/jira/browse/RANGER-4481?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17776958#comment-17776958
]
Xuze Yang edited comment on RANGER-4481 at 10/26/23 2:52 AM:
-------------------------------------------------------------
{*}1. Problem phenomenon{*}:
>From a certain moment on, the ranger plugin of resourcemanager0 has been
>unable to pull policies, and the error log is 401. The kerberos service is
>normal, and as a comparison, the ranger plugin of resourcemanager1 can pull
>policies normally. Resourcemanager0's error log:
{code:java}
2023-10-19 08:55:02,551 WARN
org.apache.ranger.admin.client.RangerAdminRESTClient: Error getting Roles.
secureMode=true,
user=hadoop/hdp-hadoop-hdp-resourcemanager-1.hdp-hadoop-hdp-resourcemanager.yangxuze.svc.cluster.lo...@dahua.com
(auth:KERBEROS), response={"httpStatusCode":401,"statusCode":0},
serviceName=default-Yarn
2023-10-19 08:55:02,552 WARN
org.apache.ranger.admin.client.RangerAdminRESTClient: Error getting policies.
secureMode=true,
user=hadoop/hdp-hadoop-hdp-resourcemanager-1.hdp-hadoop-hdp-resourcemanager.yangxuze.svc.cluster.lo...@dahua.com
(auth:KERBEROS), response={"httpStatusCode":401,"statusCode":0},
serviceName=default-Yarn
2023-10-19 08:55:12,572 WARN
org.apache.ranger.admin.client.RangerAdminRESTClient: Error getting Roles.
secureMode=true,
user=hadoop/hdp-hadoop-hdp-resourcemanager-1.hdp-hadoop-hdp-resourcemanager.yangxuze.svc.cluster.lo...@dahua.com
(auth:KERBEROS), response={"httpStatusCode":401,"statusCode":0},
serviceName=default-Yarn
2023-10-19 08:55:12,574 WARN
org.apache.ranger.admin.client.RangerAdminRESTClient: Error getting policies.
secureMode=true,
user=hadoop/hdp-hadoop-hdp-resourcemanager-1.hdp-hadoop-hdp-resourcemanager.yangxuze.svc.cluster.lo...@dahua.com
(auth:KERBEROS), response={"httpStatusCode":401,"statusCode":0},
serviceName=default-Yarn{code}
*2. Problem Cause Analysis：*
The normal process for the Ranger plugin to pull policies from the Ranger
server：
1) For the first request, the server will reply with a 401 and carry "WWW
Authenticate: Negotiate" in the HTTP header
!first http response.png!
2) The internal httpUrlConnection class of Openjdk handles this by performing a
kerberos authentication, and then placing the authentication result in the HTTP
header field Authorization to request again
!second http request.png!
3) Afterwards, the server can provide the correct response, such as a 200
response or a 304 response
abnormal:
When performing kerberos authentication, if the kdc service is abnormal, it
will be determined that the service does not support kerberos authentication,
and then this information will be stored in a global static map called
'supported'. Subsequent requests will be obtained from the 'supported' based on
the server hostname to determine whether authentication methods are supported
!openjdk problem code.png!
*Therefore, once the first failure occurs, it will be determined that the
service does not support authentication, and the second HTTP request will never
be triggered, resulting in the inability to obtain policies from the service
forever.*
was (Author: xuze yang):
{*}1. Problem phenomenon{*}:
>From a certain moment on, the ranger plugin of resourcemanager0 has been
>unable to pull policies, and the error log is 401. The kerberos service is
>normal, and as a comparison, the ranger plugin of resourcemanager1 can pull
>policies normally. Resourcemanager0's error log:
{code:java}
2023-10-19 08:55:02,551 WARN
org.apache.ranger.admin.client.RangerAdminRESTClient: Error getting Roles.
secureMode=true,
user=hadoop/hdp-hadoop-hdp-resourcemanager-1.hdp-hadoop-hdp-resourcemanager.yangxuze.svc.cluster.lo...@dahua.com
(auth:KERBEROS), response={"httpStatusCode":401,"statusCode":0},
serviceName=default-Yarn
2023-10-19 08:55:02,552 WARN
org.apache.ranger.admin.client.RangerAdminRESTClient: Error getting policies.
secureMode=true,
user=hadoop/hdp-hadoop-hdp-resourcemanager-1.hdp-hadoop-hdp-resourcemanager.yangxuze.svc.cluster.lo...@dahua.com
(auth:KERBEROS), response={"httpStatusCode":401,"statusCode":0},
serviceName=default-Yarn
2023-10-19 08:55:12,572 WARN
org.apache.ranger.admin.client.RangerAdminRESTClient: Error getting Roles.
secureMode=true,
user=hadoop/hdp-hadoop-hdp-resourcemanager-1.hdp-hadoop-hdp-resourcemanager.yangxuze.svc.cluster.lo...@dahua.com
(auth:KERBEROS), response={"httpStatusCode":401,"statusCode":0},
serviceName=default-Yarn
2023-10-19 08:55:12,574 WARN
org.apache.ranger.admin.client.RangerAdminRESTClient: Error getting policies.
secureMode=true,
user=hadoop/hdp-hadoop-hdp-resourcemanager-1.hdp-hadoop-hdp-resourcemanager.yangxuze.svc.cluster.lo...@dahua.com
(auth:KERBEROS), response={"httpStatusCode":401,"statusCode":0},
serviceName=default-Yarn{code}
*2. Problem Cause Analysis：*
The normal process for the Ranger plugin to pull policies from the Ranger
server：
1) For the first request, the server will reply with a 401 and carry "WWW
Authenticate: Negotiate" in the HTTP header
!1.png!
2) The internal httpUrlConnection class of Openjdk handles this by performing a
kerberos authentication, and then placing the authentication result in the HTTP
header field Authorization to request again
!2.png!
3) Afterwards, the server can provide the correct response, such as a 200
response or a 304 response
abnormal:
When performing kerberos authentication, if the kdc service is abnormal, it
will be determined that the service does not support kerberos authentication,
and then this information will be stored in a global static map called
'supported'. Subsequent requests will be obtained from the 'supported' based on
the server hostname to determine whether authentication methods are supported
!3.png!
*Therefore, once the first failure occurs, it will be determined that the
service does not support authentication, and the second HTTP request will never
be triggered, resulting in the inability to obtain policies from the service
forever.*
> Add a configuration item to support Ranger client not using authentication
> --------------------------------------------------------------------------
>
> Key: RANGER-4481
> URL: https://issues.apache.org/jira/browse/RANGER-4481
> Project: Ranger
> Issue Type: Improvement
> Components: Ranger
> Affects Versions: 2.1.0
> Reporter: Xuze Yang
> Priority: Major
> Attachments: feasible solution code.png, first http response.png,
> openjdk problem code.png, second http request.png
>
>
> As described in RANGER-3602, ranger supports downloading policies and roles
> through unauthenticated http requests even if kerberos is enabled on the
> server.
> But in terms of the current implementation of RangerAdminRESTClient, whether
> to enable authenticated HTTP requests depends on the service in which it is
> located. For example, if the Hadoop service has kerberos enabled, then the
> RangerAdminRESTClient in the HDFS and Yarn plugins will also use
> authenticated HTTP requests.
> I think this is not reasonable enough. In this case (both the Ranger server
> and Hadoop are enabled for kerberos), the RangerAdminRESTClient of the HDFS
> and Yarn plugins should also be allowed to download policies and roles
> through unauthenticated HTTP requests.
> The reason why I proposed this improvement is due to a bug I encountered in
> our production environment. I will introduce the bug I encountered later.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
