[
https://issues.apache.org/jira/browse/RANGER-4481?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17783990#comment-17783990
]
Xuze Yang commented on RANGER-4481:
-----------------------------------
This problem can be reproduced everytime according to the following steps:
Environment: 2 ranger servers（called ranger0 and ranger1）, 1 kerberos
1. Restart the ranger client (to ensure that the ranger client has
interacted with only one ranger server)
2. Determine the range server that the range client reqeust to, assuming
it is range0
3. Make the kerberos unavailable
4. Make ranger0 unavailable
5. Make the kerberos available
A little explanation: In step 4, by making range0 unavailable, the ranger
client will switch to interacting with range1. After the first HTTP request
returns 401, the ranger client will request a ticket for ranger1 from kerberos.
However, due to kerberos's unavailable at this time, the ticket request failed.
And Because it's the first time for ranger client interact with ranger1,
NegotiateAuthentication#supported will put the entry: \{ranger1's hostname,
false}, and it will continue to return false in subsequent requests.
After applying the provided patch, the ranger client can pull policies after
kerberos returns to normal.
> 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
> Assignee: 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)
