[ 
https://issues.apache.org/jira/browse/RANGER-5712?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Ramachandran Krishnan updated RANGER-5712:
------------------------------------------
    Description: 
Trino and Ozone plugins in the ranger-docker dev sandbox fail to download 
policies, roles, tags, and xusers from Ranger Admin with HTTP 400 
({{{}Unauthenticated access not allowed{}}}). HDFS/Hive work because they use 
Kerberos-backed secure download paths. The dev sandbox uses plain HTTP and does 
not configure plugin Kerberos auth on the Admin REST client, so downloads are 
rejected unless {{ranger.admin.allow.unauthenticated.download.access}} is 
enabled.

Problem

After RANGER-5635 (#1048), {{failUnauthenticatedDownloadIfNotAllowed()}} is 
enforced even when Hadoop security is not fully enabled. In ranger-docker:
 * Admin runs with {{policymgr_http_enabled=true}} and 
{{authentication_method=UNIX}}
 * Trino/Ozone plugins call non-secure download URLs (no SPNEGO/Kerberos on the 
plugin REST client)
 * Default {{ranger.admin.allow.unauthenticated.download.access=false}} in 
{{ranger-admin-default-site.xml}}

Affected endpoints:
 * {{/service/plugins/policies/download/}}
 * {{/service/roles/download/}}
 * {{/service/tags/download/}}
 * {{/service/xusers/download/}}

Symptom in Admin logs: {{Unauthenticated access not allowed}} → HTTP 400 in 
access logs.

This is a dev/docker configuration gap, not a plugin or REST bug. 
{{policy.download.auth.users}} on the service (e.g. trino, om) is not 
sufficient when unauthenticated download is disabled globally.
----
Root cause
 # RANGER-5635 tightened download auth checks (correct for production).
 # ranger-docker never wires 
{{ranger.admin.allow.unauthenticated.download.access}} into 
{{{}ranger-admin-site.xml{}}}.
 # Adding the property only to docker {{install.properties}} does not work 
today — {{setup.sh}} only updates keys that already exist in 
{{ranger-admin-site.xml}} (same pattern as 
{{{}FF_ENABLE_OZONE_ACTION_MATCHES_CONDITION{}}}).

----
Proposed solution:
 # *update plugin configuration to include authentication information*

We should look at Ozone setup, to ensure that it has Kerberos configuration 
correctly. For Trino, we should update plugin configuration with 
username/password to authenticate with Ranger admin.

  was:
Trino and Ozone plugins in the ranger-docker dev sandbox fail to download 
policies, roles, tags, and xusers from Ranger Admin with HTTP 400 
({{{}Unauthenticated access not allowed{}}}). HDFS/Hive work because they use 
Kerberos-backed secure download paths. The dev sandbox uses plain HTTP and does 
not configure plugin Kerberos auth on the Admin REST client, so downloads are 
rejected unless {{ranger.admin.allow.unauthenticated.download.access}} is 
enabled.



Problem

After RANGER-5635 (#1048), {{failUnauthenticatedDownloadIfNotAllowed()}} is 
enforced even when Hadoop security is not fully enabled. In ranger-docker:
 * Admin runs with {{policymgr_http_enabled=true}} and 
{{authentication_method=UNIX}}
 * Trino/Ozone plugins call non-secure download URLs (no SPNEGO/Kerberos on the 
plugin REST client)
 * Default {{ranger.admin.allow.unauthenticated.download.access=false}} in 
{{ranger-admin-default-site.xml}}

Affected endpoints:
 * {{/service/plugins/policies/download/}}
 * {{/service/roles/download/}}
 * {{/service/tags/download/}}
 * {{/service/xusers/download/}}

Symptom in Admin logs: {{Unauthenticated access not allowed}} → HTTP 400 in 
access logs.

This is a dev/docker configuration gap, not a plugin or REST bug. 
{{policy.download.auth.users}} on the service (e.g. trino, om) is not 
sufficient when unauthenticated download is disabled globally.
----
Root cause
 # RANGER-5635 tightened download auth checks (correct for production).
 # ranger-docker never wires 
{{ranger.admin.allow.unauthenticated.download.access}} into 
{{{}ranger-admin-site.xml{}}}.
 # Adding the property only to docker {{install.properties}} does not work 
today — {{setup.sh}} only updates keys that already exist in 
{{ranger-admin-site.xml}} (same pattern as 
{{{}FF_ENABLE_OZONE_ACTION_MATCHES_CONDITION{}}}).

----
Proposed solution

Wire a new install property through Admin setup into 
{{{}ranger-admin-site.xml{}}}, and set it to {{true}} only in docker dev 
install files.

Install property (suggested name):
ranger_admin_allow_unauthenticated_download_access=true # docker dev only
ranger_admin_allow_unauthenticated_download_access=false # default everywhere 
else
Maps to site.xml:
 
{code:java}
ranger.admin.allow.unauthenticated.download.access{code}


> Enable unauthenticated plugin download in ranger-docker dev sandbox
> -------------------------------------------------------------------
>
>                 Key: RANGER-5712
>                 URL: https://issues.apache.org/jira/browse/RANGER-5712
>             Project: Ranger
>          Issue Type: Task
>          Components: Ranger
>    Affects Versions: 2.8.0
>            Reporter: Ramachandran Krishnan
>            Assignee: Ramachandran Krishnan
>            Priority: Major
>             Fix For: 3.0.0
>
>          Time Spent: 10m
>  Remaining Estimate: 0h
>
> Trino and Ozone plugins in the ranger-docker dev sandbox fail to download 
> policies, roles, tags, and xusers from Ranger Admin with HTTP 400 
> ({{{}Unauthenticated access not allowed{}}}). HDFS/Hive work because they use 
> Kerberos-backed secure download paths. The dev sandbox uses plain HTTP and 
> does not configure plugin Kerberos auth on the Admin REST client, so 
> downloads are rejected unless 
> {{ranger.admin.allow.unauthenticated.download.access}} is enabled.
> Problem
> After RANGER-5635 (#1048), {{failUnauthenticatedDownloadIfNotAllowed()}} is 
> enforced even when Hadoop security is not fully enabled. In ranger-docker:
>  * Admin runs with {{policymgr_http_enabled=true}} and 
> {{authentication_method=UNIX}}
>  * Trino/Ozone plugins call non-secure download URLs (no SPNEGO/Kerberos on 
> the plugin REST client)
>  * Default {{ranger.admin.allow.unauthenticated.download.access=false}} in 
> {{ranger-admin-default-site.xml}}
> Affected endpoints:
>  * {{/service/plugins/policies/download/}}
>  * {{/service/roles/download/}}
>  * {{/service/tags/download/}}
>  * {{/service/xusers/download/}}
> Symptom in Admin logs: {{Unauthenticated access not allowed}} → HTTP 400 in 
> access logs.
> This is a dev/docker configuration gap, not a plugin or REST bug. 
> {{policy.download.auth.users}} on the service (e.g. trino, om) is not 
> sufficient when unauthenticated download is disabled globally.
> ----
> Root cause
>  # RANGER-5635 tightened download auth checks (correct for production).
>  # ranger-docker never wires 
> {{ranger.admin.allow.unauthenticated.download.access}} into 
> {{{}ranger-admin-site.xml{}}}.
>  # Adding the property only to docker {{install.properties}} does not work 
> today — {{setup.sh}} only updates keys that already exist in 
> {{ranger-admin-site.xml}} (same pattern as 
> {{{}FF_ENABLE_OZONE_ACTION_MATCHES_CONDITION{}}}).
> ----
> Proposed solution:
>  # *update plugin configuration to include authentication information*
> We should look at Ozone setup, to ensure that it has Kerberos configuration 
> correctly. For Trino, we should update plugin configuration with 
> username/password to authenticate with Ranger admin.



--
This message was sent by Atlassian Jira
(v8.20.10#820010)

Reply via email to