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:47:00 UTC

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

Ben Iglauer created RANGER-2460:
-----------------------------------

             Summary: 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


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)