You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@ranger.apache.org by "Ben Iglauer (JIRA)" <ji...@apache.org> on 2019/06/05 19:48:00 UTC

[jira] [Updated] (RANGER-2460) Failed attempts to update a policy via the ranger rest api and kerberos show up as successful logins in the audit logs

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

Ben Iglauer updated RANGER-2460:
--------------------------------
    Attachment: failed_kerberos_logins_audited_incorrectly.png

> Failed attempts to update a policy via the ranger rest api and kerberos show up as successful logins in the audit logs
> ----------------------------------------------------------------------------------------------------------------------
>
>                 Key: RANGER-2460
>                 URL: https://issues.apache.org/jira/browse/RANGER-2460
>             Project: Ranger
>          Issue Type: Bug
>          Components: audit, Ranger
>    Affects Versions: 2.0.0
>            Reporter: Ben Iglauer
>            Priority: Major
>         Attachments: failed_kerberos_logins_audited_incorrectly.png
>
>
> I am using kerberos authentication to ingest a policy via a script that is essentially a sentry to ranger policy migration tool. This tool uses kerberos authentication when connecting to the ranger REST API. If I use an incorrect kerberos identity, the connection attempt correctly fails with an authentication error. However, the ranger audit logs, in the login sessions tab of the ranger admin UI, show that the authentication was successful. 
> Instead, the ranger audit logs should show that there was a failed authentication attempt. 
> To reproduce:
> 0. I have setup admin, and otheradmin as the two admin users. These users (with the respective kerberos principles admin and otheradmin) are the only ones who can login to the ranger web ui, or use the migration tool to ingest new policies. 
> 1. I kinit as test_user2, and attempt to ingest a policy. Since this is an upstream JIRA, a person reproducing this will instead attempt to connect to the REST API via arguments passed to the ranger client. 
> {noformat}
> [root@aragorn-1 scripts]# kinit test_user2
> Password for test_user2@VPC.CLOUDERA.COM: 
> [root@aragorn-1 scripts]# ./authmigration_ingest.sh -c ingest -dr /var/run/cloudera-scm-agent/process/63-ranger-RANGER_ADMIN/
> log4j:WARN No appenders could be found for logger (org.apache.hadoop.util.Shell).
> log4j:WARN Please initialize the log4j system properly.
> log4j:WARN See http://logging.apache.org/log4j/1.2/faq.html#noconfig for more info.
> Ingestion of the permissions in progress...
> [Started] Reading policy information from file:/opt/backup/mx_ingest.json
> [Completed] Reading policy information from file:/opt/backup/mx_ingest.json
> De-serialization of data is complete
> Loading permissions from storage is successful
> Initiating the ingest as user: root
> Ingesting the Policies using ranger import API
> Created Ranger policy for resource db=default
> Created Ranger policy for resource db=default->Udf=*
> Created Ranger policy for resource db=default->tbl=web_logs
> Created Ranger policy for resource db=database_u1->tbl=table_u2
> Created Ranger policy for resource db=default->tbl=customers
> Created Ranger policy for resource db=database_u1
> Created Ranger policy for resource db=database_u1->Udf=*
> Created Ranger policy for resource db=database_u1->tbl=table_u2->col=fn
> Created Ranger policy for resource db=default->tbl=sample_07
> Created Ranger policy for resource db=*->tbl=*->column=*
> Created Ranger policy for resource db=*->Udf=*
> Created Ranger policy for resource Url=*
> Created Ranger policy for resource hiveservice=*
> Created Ranger policy for resource Global=*
> Created Ranger policy for resource db=default->tbl=sample_08
> User root, is not authorized to perform admin operation. Please grant admin role to user: root using ranger admin UI
> Ranger policy ingest failed
> Bulk Ingesting of permissions to ranger service has failed
> [root@aragorn-1 scripts]# klist
> Ticket cache: FILE:/tmp/krb5cc_0
> Default principal: test_user2@VPC.CLOUDERA.COM
> Valid starting       Expires              Service principal
> 05/31/2019 11:55:04  05/31/2019 12:20:04  krbtgt/VPC.CLOUDERA.COM@VPC.CLOUDERA.COM
>         renew until 05/31/2019 13:25:04
> {noformat} 
> The login attempt by test_user2 shows up as successful in the ranger audit logs for login sessions.   See attached screen shot.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)