[jira] [Assigned] (RANGER-4638) Multiple Columns Revoke not generating policies with correct number of columns
[ https://issues.apache.org/jira/browse/RANGER-4638?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ramesh Mani reassigned RANGER-4638: --- Assignee: Ramesh Mani > Multiple Columns Revoke not generating policies with correct number of columns > -- > > Key: RANGER-4638 > URL: https://issues.apache.org/jira/browse/RANGER-4638 > Project: Ranger > Issue Type: Bug > Components: Ranger >Affects Versions: 3.0.0 >Reporter: Ramesh Mani >Assignee: Ramesh Mani >Priority: Major > > Multiple Columns Revoke not generating policies with correct number of > columns. E.G > When " revoke select(col1, col2,col3) on table demo.test from role Role3;" > is done, the generate policies is not revoking the columns. Currently revoke > statement is only revoking if the is only one column. > Testing to done" > Impala / Hive beeline. > 1) "grant select(col1, col2, col3) on table demo.test to role Role1" > "revoke select(col1, col2, col3) on table demo.test from role Role1" > 2) "grant select(col1, col2, col3, col4) on table demo.test to role Role1" > "revoke select(col1, col2, col3) on table demo.test from role Role1" > HBASE shell > grant 'nifi', 'RWXCA', 'test' > revoke 'nifi', 'test' > -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Created] (RANGER-4638) Multiple Columns Revoke not generating policies with correct number of columns
Ramesh Mani created RANGER-4638: --- Summary: Multiple Columns Revoke not generating policies with correct number of columns Key: RANGER-4638 URL: https://issues.apache.org/jira/browse/RANGER-4638 Project: Ranger Issue Type: Bug Components: Ranger Affects Versions: 3.0.0 Reporter: Ramesh Mani Multiple Columns Revoke not generating policies with correct number of columns. E.G When " revoke select(col1, col2,col3) on table demo.test from role Role3;" is done, the generate policies is not revoking the columns. Currently revoke statement is only revoking if the is only one column. Testing to done" Impala / Hive beeline. 1) "grant select(col1, col2, col3) on table demo.test to role Role1" "revoke select(col1, col2, col3) on table demo.test from role Role1" 2) "grant select(col1, col2, col3, col4) on table demo.test to role Role1" "revoke select(col1, col2, col3) on table demo.test from role Role1" HBASE shell grant 'nifi', 'RWXCA', 'test' revoke 'nifi', 'test' -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (RANGER-4619) Fix NPE in the SHOW GRANT API of RangerHiveAuthorizer
[ https://issues.apache.org/jira/browse/RANGER-4619?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ramesh Mani updated RANGER-4619: Summary: Fix NPE in the SHOW GRANT API of RangerHiveAuthorizer (was: Fix NPE in the SHOW GRANT API of RangerHiveAuthorizer.) > Fix NPE in the SHOW GRANT API of RangerHiveAuthorizer > - > > Key: RANGER-4619 > URL: https://issues.apache.org/jira/browse/RANGER-4619 > Project: Ranger > Issue Type: Bug > Components: Ranger >Affects Versions: 3.0.0 >Reporter: Ramesh Mani >Assignee: Ramesh Mani >Priority: Minor > > When hive plugin is not initialized, SHOW GRANT [principal_specification] > ON (ALL | [TABLE] table_or_view_name) command will result in NPE. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Assigned] (RANGER-4619) Fix NPE in the SHOW GRANT API of RangerHiveAuthorizer.
[ https://issues.apache.org/jira/browse/RANGER-4619?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ramesh Mani reassigned RANGER-4619: --- Assignee: Ramesh Mani > Fix NPE in the SHOW GRANT API of RangerHiveAuthorizer. > -- > > Key: RANGER-4619 > URL: https://issues.apache.org/jira/browse/RANGER-4619 > Project: Ranger > Issue Type: Bug > Components: Ranger >Affects Versions: 3.0.0 >Reporter: Ramesh Mani >Assignee: Ramesh Mani >Priority: Minor > > When hive plugin is not initialized, SHOW GRANT [principal_specification] > ON (ALL | [TABLE] table_or_view_name) command will result in NPE. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Created] (RANGER-4619) Fix NPE in the SHOW GRANT API of RangerHiveAuthorizer.
Ramesh Mani created RANGER-4619: --- Summary: Fix NPE in the SHOW GRANT API of RangerHiveAuthorizer. Key: RANGER-4619 URL: https://issues.apache.org/jira/browse/RANGER-4619 Project: Ranger Issue Type: Bug Components: Ranger Affects Versions: 3.0.0 Reporter: Ramesh Mani When hive plugin is not initialized, SHOW GRANT [principal_specification] ON (ALL | [TABLE] table_or_view_name) command will result in NPE. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Comment Edited] (RANGER-4585) Support multiple columns policy creation in ranger for Grant / Revoke request
[ https://issues.apache.org/jira/browse/RANGER-4585?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17794448#comment-17794448 ] Ramesh Mani edited comment on RANGER-4585 at 12/7/23 10:03 PM: --- Review link : [https://reviews.apache.org/r/74777/] was (Author: rmani): Review link > Support multiple columns policy creation in ranger for Grant / Revoke request > - > > Key: RANGER-4585 > URL: https://issues.apache.org/jira/browse/RANGER-4585 > Project: Ranger > Issue Type: Bug > Components: Ranger >Affects Versions: 3.0.0 >Reporter: Ramesh Mani >Assignee: Ramesh Mani >Priority: Major > Attachments: > 0001-RANGER-4585-Support-multiple-columns-policy-creation.patch > > > Support multiple columns policy creation in ranger for Grant / Revoke request > When request like "grant select ( col1, col2, col3, col4, col5, col6, col7, > col8, col9, col10) on table demo.data5 to role testrole_09289898" is done in > Impala or Hive ranger doesn't create those columns in a single policy. In > Impala case it create one grant for each of the column. In Hive it creates a > "*" column policy. This has to be modified to support creation of single > policy for grant with all the columns added.Same case for Revoke, need to > support update of the policies correctly. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (RANGER-4585) Support multiple columns policy creation in ranger for Grant / Revoke request
[ https://issues.apache.org/jira/browse/RANGER-4585?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ramesh Mani updated RANGER-4585: Attachment: 0001-RANGER-4585-Support-multiple-columns-policy-creation.patch > Support multiple columns policy creation in ranger for Grant / Revoke request > - > > Key: RANGER-4585 > URL: https://issues.apache.org/jira/browse/RANGER-4585 > Project: Ranger > Issue Type: Bug > Components: Ranger >Affects Versions: 3.0.0 >Reporter: Ramesh Mani >Assignee: Ramesh Mani >Priority: Major > Attachments: > 0001-RANGER-4585-Support-multiple-columns-policy-creation.patch > > > Support multiple columns policy creation in ranger for Grant / Revoke request > When request like "grant select ( col1, col2, col3, col4, col5, col6, col7, > col8, col9, col10) on table demo.data5 to role testrole_09289898" is done in > Impala or Hive ranger doesn't create those columns in a single policy. In > Impala case it create one grant for each of the column. In Hive it creates a > "*" column policy. This has to be modified to support creation of single > policy for grant with all the columns added.Same case for Revoke, need to > support update of the policies correctly. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Assigned] (RANGER-4585) Support multiple columns policy creation in ranger for Grant / Revoke request
[ https://issues.apache.org/jira/browse/RANGER-4585?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ramesh Mani reassigned RANGER-4585: --- Assignee: Ramesh Mani > Support multiple columns policy creation in ranger for Grant / Revoke request > - > > Key: RANGER-4585 > URL: https://issues.apache.org/jira/browse/RANGER-4585 > Project: Ranger > Issue Type: Bug > Components: Ranger >Affects Versions: 3.0.0 >Reporter: Ramesh Mani >Assignee: Ramesh Mani >Priority: Major > > Support multiple columns policy creation in ranger for Grant / Revoke request > When request like "grant select ( col1, col2, col3, col4, col5, col6, col7, > col8, col9, col10) on table demo.data5 to role testrole_09289898" is done in > Impala or Hive ranger doesn't create those columns in a single policy. In > Impala case it create one grant for each of the column. In Hive it creates a > "*" column policy. This has to be modified to support creation of single > policy for grant with all the columns added.Same case for Revoke, need to > support update of the policies correctly. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Created] (RANGER-4585) Support multiple columns policy creation in ranger for Grant / Revoke request
Ramesh Mani created RANGER-4585: --- Summary: Support multiple columns policy creation in ranger for Grant / Revoke request Key: RANGER-4585 URL: https://issues.apache.org/jira/browse/RANGER-4585 Project: Ranger Issue Type: Bug Components: Ranger Affects Versions: 3.0.0 Reporter: Ramesh Mani Support multiple columns policy creation in ranger for Grant / Revoke request When request like "grant select ( col1, col2, col3, col4, col5, col6, col7, col8, col9, col10) on table demo.data5 to role testrole_09289898" is done in Impala or Hive ranger doesn't create those columns in a single policy. In Impala case it create one grant for each of the column. In Hive it creates a "*" column policy. This has to be modified to support creation of single policy for grant with all the columns added.Same case for Revoke, need to support update of the policies correctly. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Comment Edited] (RANGER-4404) Audit to hdfs for orc format feature stabilisation
[
https://issues.apache.org/jira/browse/RANGER-4404?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17764835#comment-17764835
]
Ramesh Mani edited comment on RANGER-4404 at 9/14/23 3:57 PM:
--
[~bpatel] Yes directly writing into ORC format and copying is what I was
thinking of, but in this process we should not lose audit in case of failure.
Json to ORC conversion tool looks promising an if we processes parallelly.
Will check it out. Thanks.
was (Author: rmani):
[~bpatel] Yes directly writing into ORC format and copying is what I was
thinking of, but in this process we should not loose audit it case of failure.
Json to ORC conversion tool looks promising an if we processes parallelly.
Will check it out. Thanks.
> Audit to hdfs for orc format feature stabilisation
> --
>
> Key: RANGER-4404
> URL: https://issues.apache.org/jira/browse/RANGER-4404
> Project: Ranger
> Issue Type: Improvement
> Components: audit
>Affects Versions: 3.0.0, 2.4.0
>Reporter: Bhavik Patel
>Assignee: Bhavik Patel
>Priority: Major
>
> Currently if we have 50GB audit log file in spool directory then it is taking
> 4-5hr for the conversion and writing to HDFS.
> Also, we are observing below error logs
> {code:java}
> ERROR [AuditFileQueueSpool_hdfs_destWriter] provider.BaseAuditHandler: Error
> writing to log file.
> java.lang.RuntimeException: Overflow of newLength.
> smallBuffer.length=1073741824, nextElemLength=38
> at
> org.apache.hadoop.hive.ql.exec.vector.BytesColumnVector.increaseBufferSpace(BytesColumnVector.java:311)
> at
> org.apache.hadoop.hive.ql.exec.vector.BytesColumnVector.setVal(BytesColumnVector.java:182)
> at
> org.apache.hadoop.hive.ql.exec.vector.BytesColumnVector.setVal(BytesColumnVector.java:207)
> at org.apache.ranger.audit.utils.ORCFileUtil.log(ORCFileUtil.java:143)
> at
> org.apache.ranger.audit.utils.RangerORCAuditWriter$1.run(RangerORCAuditWriter.java:77)
> at
> org.apache.ranger.audit.utils.RangerORCAuditWriter$1.run(RangerORCAuditWriter.java:73)
> at java.security.AccessController.doPrivileged(Native Method)
> at javax.security.auth.Subject.doAs(Subject.java:422)
> at
> org.apache.hadoop.security.UserGroupInformation.doAs(UserGroupInformation.java:1762)
> at
> org.apache.ranger.audit.provider.MiscUtil.executePrivilegedAction(MiscUtil.java:541)
> at
> org.apache.ranger.audit.utils.RangerORCAuditWriter.logAuditAsORC(RangerORCAuditWriter.java:73)
> at
> org.apache.ranger.audit.utils.RangerORCAuditWriter.logAsORC(RangerORCAuditWriter.java:159)
> at
> org.apache.ranger.audit.utils.RangerORCAuditWriter.log(RangerORCAuditWriter.java:112)
> at
> org.apache.ranger.audit.destination.HDFSAuditDestination.logJSON(HDFSAuditDestination.java:78)
> at
> org.apache.ranger.audit.destination.HDFSAuditDestination.log(HDFSAuditDestination.java:163)
> at
> org.apache.ranger.audit.queue.AuditFileQueueSpool.sendEvent(AuditFileQueueSpool.java:926)
> at
> org.apache.ranger.audit.queue.AuditFileQueueSpool.logEvent(AuditFileQueueSpool.java:913)
> at
> org.apache.ranger.audit.queue.AuditFileQueueSpool.runLogAudit(AuditFileQueueSpool.java:847)
> at
> org.apache.ranger.audit.queue.AuditFileQueueSpool.run(AuditFileQueueSpool.java:790)
> {code}
> hive-storage-api version upgrade(>=2.7.3) required to resolve the above error.
> Current version is 2.7.2
> cc: [~rmani] [~fateh288]
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (RANGER-4404) Audit to hdfs for orc format feature stabilisation
[
https://issues.apache.org/jira/browse/RANGER-4404?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17764835#comment-17764835
]
Ramesh Mani commented on RANGER-4404:
-
[~bpatel] Yes directly writing into ORC format and copying is what I was
thinking of, but in this process we should not loose audit it case of failure.
Json to ORC conversion tool looks promising an if we processes parallelly.
Will check it out. Thanks.
> Audit to hdfs for orc format feature stabilisation
> --
>
> Key: RANGER-4404
> URL: https://issues.apache.org/jira/browse/RANGER-4404
> Project: Ranger
> Issue Type: Improvement
> Components: audit
>Affects Versions: 3.0.0, 2.4.0
>Reporter: Bhavik Patel
>Assignee: Bhavik Patel
>Priority: Major
>
> Currently if we have 50GB audit log file in spool directory then it is taking
> 4-5hr for the conversion and writing to HDFS.
> Also, we are observing below error logs
> {code:java}
> ERROR [AuditFileQueueSpool_hdfs_destWriter] provider.BaseAuditHandler: Error
> writing to log file.
> java.lang.RuntimeException: Overflow of newLength.
> smallBuffer.length=1073741824, nextElemLength=38
> at
> org.apache.hadoop.hive.ql.exec.vector.BytesColumnVector.increaseBufferSpace(BytesColumnVector.java:311)
> at
> org.apache.hadoop.hive.ql.exec.vector.BytesColumnVector.setVal(BytesColumnVector.java:182)
> at
> org.apache.hadoop.hive.ql.exec.vector.BytesColumnVector.setVal(BytesColumnVector.java:207)
> at org.apache.ranger.audit.utils.ORCFileUtil.log(ORCFileUtil.java:143)
> at
> org.apache.ranger.audit.utils.RangerORCAuditWriter$1.run(RangerORCAuditWriter.java:77)
> at
> org.apache.ranger.audit.utils.RangerORCAuditWriter$1.run(RangerORCAuditWriter.java:73)
> at java.security.AccessController.doPrivileged(Native Method)
> at javax.security.auth.Subject.doAs(Subject.java:422)
> at
> org.apache.hadoop.security.UserGroupInformation.doAs(UserGroupInformation.java:1762)
> at
> org.apache.ranger.audit.provider.MiscUtil.executePrivilegedAction(MiscUtil.java:541)
> at
> org.apache.ranger.audit.utils.RangerORCAuditWriter.logAuditAsORC(RangerORCAuditWriter.java:73)
> at
> org.apache.ranger.audit.utils.RangerORCAuditWriter.logAsORC(RangerORCAuditWriter.java:159)
> at
> org.apache.ranger.audit.utils.RangerORCAuditWriter.log(RangerORCAuditWriter.java:112)
> at
> org.apache.ranger.audit.destination.HDFSAuditDestination.logJSON(HDFSAuditDestination.java:78)
> at
> org.apache.ranger.audit.destination.HDFSAuditDestination.log(HDFSAuditDestination.java:163)
> at
> org.apache.ranger.audit.queue.AuditFileQueueSpool.sendEvent(AuditFileQueueSpool.java:926)
> at
> org.apache.ranger.audit.queue.AuditFileQueueSpool.logEvent(AuditFileQueueSpool.java:913)
> at
> org.apache.ranger.audit.queue.AuditFileQueueSpool.runLogAudit(AuditFileQueueSpool.java:847)
> at
> org.apache.ranger.audit.queue.AuditFileQueueSpool.run(AuditFileQueueSpool.java:790)
> {code}
> hive-storage-api version upgrade(>=2.7.3) required to resolve the above error.
> Current version is 2.7.2
> cc: [~rmani] [~fateh288]
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (RANGER-4404) Audit to hdfs for orc format feature stabilisation
[
https://issues.apache.org/jira/browse/RANGER-4404?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17764800#comment-17764800
]
Ramesh Mani commented on RANGER-4404:
-
[~bpatel] Thanks for raising this.
On the time taken to convert 50 gb of log , where do you think that more of the
time spent? Could parallelizing the batch process of files help in this case? I
mean multiple threads ( partitioning) based on the number of files and
processing it parallel will help in this case?
> Audit to hdfs for orc format feature stabilisation
> --
>
> Key: RANGER-4404
> URL: https://issues.apache.org/jira/browse/RANGER-4404
> Project: Ranger
> Issue Type: Improvement
> Components: audit
>Affects Versions: 3.0.0, 2.4.0
>Reporter: Bhavik Patel
>Assignee: Bhavik Patel
>Priority: Major
>
> Currently if we have 50GB audit log file in spool directory then it is taking
> 4-5hr for the conversion and writing to HDFS.
> Also, we are observing below error logs
> {code:java}
> ERROR [AuditFileQueueSpool_hdfs_destWriter] provider.BaseAuditHandler: Error
> writing to log file.
> java.lang.RuntimeException: Overflow of newLength.
> smallBuffer.length=1073741824, nextElemLength=38
> at
> org.apache.hadoop.hive.ql.exec.vector.BytesColumnVector.increaseBufferSpace(BytesColumnVector.java:311)
> at
> org.apache.hadoop.hive.ql.exec.vector.BytesColumnVector.setVal(BytesColumnVector.java:182)
> at
> org.apache.hadoop.hive.ql.exec.vector.BytesColumnVector.setVal(BytesColumnVector.java:207)
> at org.apache.ranger.audit.utils.ORCFileUtil.log(ORCFileUtil.java:143)
> at
> org.apache.ranger.audit.utils.RangerORCAuditWriter$1.run(RangerORCAuditWriter.java:77)
> at
> org.apache.ranger.audit.utils.RangerORCAuditWriter$1.run(RangerORCAuditWriter.java:73)
> at java.security.AccessController.doPrivileged(Native Method)
> at javax.security.auth.Subject.doAs(Subject.java:422)
> at
> org.apache.hadoop.security.UserGroupInformation.doAs(UserGroupInformation.java:1762)
> at
> org.apache.ranger.audit.provider.MiscUtil.executePrivilegedAction(MiscUtil.java:541)
> at
> org.apache.ranger.audit.utils.RangerORCAuditWriter.logAuditAsORC(RangerORCAuditWriter.java:73)
> at
> org.apache.ranger.audit.utils.RangerORCAuditWriter.logAsORC(RangerORCAuditWriter.java:159)
> at
> org.apache.ranger.audit.utils.RangerORCAuditWriter.log(RangerORCAuditWriter.java:112)
> at
> org.apache.ranger.audit.destination.HDFSAuditDestination.logJSON(HDFSAuditDestination.java:78)
> at
> org.apache.ranger.audit.destination.HDFSAuditDestination.log(HDFSAuditDestination.java:163)
> at
> org.apache.ranger.audit.queue.AuditFileQueueSpool.sendEvent(AuditFileQueueSpool.java:926)
> at
> org.apache.ranger.audit.queue.AuditFileQueueSpool.logEvent(AuditFileQueueSpool.java:913)
> at
> org.apache.ranger.audit.queue.AuditFileQueueSpool.runLogAudit(AuditFileQueueSpool.java:847)
> at
> org.apache.ranger.audit.queue.AuditFileQueueSpool.run(AuditFileQueueSpool.java:790)
> {code}
> hive-storage-api version upgrade(>=2.7.3) required to resolve the above error.
> Current version is 2.7.2
> cc: [~rmani] [~fateh288]
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (RANGER-4178) NoClassDefFoundError: org/apache/hadoop/hive/ql/exec/vector/ColumnVector
[ https://issues.apache.org/jira/browse/RANGER-4178?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17758772#comment-17758772 ] Ramesh Mani commented on RANGER-4178: - [~bpatel] This patch has been merged. Please close the Jira and review request. Thanks. > NoClassDefFoundError: org/apache/hadoop/hive/ql/exec/vector/ColumnVector > > > Key: RANGER-4178 > URL: https://issues.apache.org/jira/browse/RANGER-4178 > Project: Ranger > Issue Type: Bug > Components: audit >Affects Versions: 3.0.0, 2.2.0, 2.3.0 >Reporter: Bhavik Patel >Assignee: Bhavik Patel >Priority: Critical > Attachments: > 0001-RANGER-4178-NoClassDefFoundError-org-apache-hadoop-h.patch, > 0001-RANGER-4178-Only-xasecure.audit.destination.hdfs.bat.patch > > > Observed below error when enabled audit type as ORC format. > NoClassDefFoundError: org/apache/hadoop/hive/ql/exec/vector/ColumnVector > https://issues.apache.org/jira/browse/RANGER-1837 > https://issues.apache.org/jira/browse/RANGER-3235 > cc: [~rmani] -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (RANGER-4178) NoClassDefFoundError: org/apache/hadoop/hive/ql/exec/vector/ColumnVector
[ https://issues.apache.org/jira/browse/RANGER-4178?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17755602#comment-17755602 ] Ramesh Mani commented on RANGER-4178: - [~fateh288] Could we have a separate Jira for addressing the issue of 2 configuration. In that way we can merge the patch for this Jira followed by yours? > NoClassDefFoundError: org/apache/hadoop/hive/ql/exec/vector/ColumnVector > > > Key: RANGER-4178 > URL: https://issues.apache.org/jira/browse/RANGER-4178 > Project: Ranger > Issue Type: Bug > Components: audit >Affects Versions: 3.0.0, 2.2.0, 2.3.0 >Reporter: Bhavik Patel >Assignee: Bhavik Patel >Priority: Critical > Attachments: > 0001-RANGER-4178-NoClassDefFoundError-org-apache-hadoop-h.patch, > 0001-RANGER-4178-Only-xasecure.audit.destination.hdfs.bat.patch > > > Observed below error when enabled audit type as ORC format. > NoClassDefFoundError: org/apache/hadoop/hive/ql/exec/vector/ColumnVector > https://issues.apache.org/jira/browse/RANGER-1837 > https://issues.apache.org/jira/browse/RANGER-3235 > cc: [~rmani] -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (RANGER-4349) AtlasTagSource is hardcoded to commit offset to ATLAS_ENTITIES
[ https://issues.apache.org/jira/browse/RANGER-4349?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17752548#comment-17752548 ] Ramesh Mani commented on RANGER-4349: - [~szyorz] Thank you for the contribution. Committed to apache ranger master https://github.com/apache/ranger/commit/a5461808742ef0f40410f326fdf236619e81ca4f > AtlasTagSource is hardcoded to commit offset to ATLAS_ENTITIES > -- > > Key: RANGER-4349 > URL: https://issues.apache.org/jira/browse/RANGER-4349 > Project: Ranger > Issue Type: Bug > Components: tagsync >Affects Versions: 3.0.0, 2.4.0 >Reporter: Szymon Orzechowski >Assignee: Szymon Orzechowski >Priority: Major > Fix For: 3.0.0 > > Attachments: RANGER-4349.patch > > > AtlasTagSource.commitToKafka() is hard coded to commit offset to topic > ATLAS_ENTITIES. The topic to which entity events are sent from Atlas and > received by Ranger Tagsync is determined by > atlas.notification.entities.topic.name property in > atlas-application.properties file. By default, it is ATLAS_ENTITIES but some > might configure it to a different name in which case Tagsync would be > committing offset to the wrong topic. > -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (RANGER-4349) AtlasTagSource is hardcoded to commit offset to ATLAS_ENTITIES
[ https://issues.apache.org/jira/browse/RANGER-4349?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ramesh Mani updated RANGER-4349: Fix Version/s: 3.0.0 > AtlasTagSource is hardcoded to commit offset to ATLAS_ENTITIES > -- > > Key: RANGER-4349 > URL: https://issues.apache.org/jira/browse/RANGER-4349 > Project: Ranger > Issue Type: Bug > Components: tagsync >Affects Versions: 3.0.0, 2.4.0 >Reporter: Szymon Orzechowski >Assignee: Szymon Orzechowski >Priority: Major > Fix For: 3.0.0 > > Attachments: RANGER-4349.patch > > > AtlasTagSource.commitToKafka() is hard coded to commit offset to topic > ATLAS_ENTITIES. The topic to which entity events are sent from Atlas and > received by Ranger Tagsync is determined by > atlas.notification.entities.topic.name property in > atlas-application.properties file. By default, it is ATLAS_ENTITIES but some > might configure it to a different name in which case Tagsync would be > committing offset to the wrong topic. > -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (RANGER-3939) Implement acls, createAcls and deleteAcls in Kafka Authorizer
[ https://issues.apache.org/jira/browse/RANGER-3939?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ramesh Mani updated RANGER-3939: Fix Version/s: 3.0.0 > Implement acls, createAcls and deleteAcls in Kafka Authorizer > - > > Key: RANGER-3939 > URL: https://issues.apache.org/jira/browse/RANGER-3939 > Project: Ranger > Issue Type: Improvement > Components: plugins >Reporter: Daniel Urban >Assignee: Ramesh Mani >Priority: Major > Fix For: 3.0.0 > > > Currently, the Kafka Authorizer only implements the .authorize method. This > is (mostly) enough to support authorization checks in the Kafka API endpoints. > But the Kafka protocol also has support for describing and managing ACLs. > These endpoints do not work with the Ranger plugin, as it requires the acls, > createAcls and deleteAcls endpoints to be correctly implemented. This can > cause issues with tools and clients relying on the Kafka ACL API. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (RANGER-3939) Implement acls, createAcls and deleteAcls in Kafka Authorizer
[ https://issues.apache.org/jira/browse/RANGER-3939?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ramesh Mani updated RANGER-3939: Affects Version/s: 3.0.0 > Implement acls, createAcls and deleteAcls in Kafka Authorizer > - > > Key: RANGER-3939 > URL: https://issues.apache.org/jira/browse/RANGER-3939 > Project: Ranger > Issue Type: Improvement > Components: plugins >Affects Versions: 3.0.0 >Reporter: Daniel Urban >Assignee: Ramesh Mani >Priority: Major > Fix For: 3.0.0 > > > Currently, the Kafka Authorizer only implements the .authorize method. This > is (mostly) enough to support authorization checks in the Kafka API endpoints. > But the Kafka protocol also has support for describing and managing ACLs. > These endpoints do not work with the Ranger plugin, as it requires the acls, > createAcls and deleteAcls endpoints to be correctly implemented. This can > cause issues with tools and clients relying on the Kafka ACL API. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (RANGER-3809) Implement authorizeByResourceType method of Kafka Authorizer
[
https://issues.apache.org/jira/browse/RANGER-3809?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Ramesh Mani updated RANGER-3809:
Fix Version/s: 3.0.0
> Implement authorizeByResourceType method of Kafka Authorizer
>
>
> Key: RANGER-3809
> URL: https://issues.apache.org/jira/browse/RANGER-3809
> Project: Ranger
> Issue Type: Improvement
> Components: plugins
>Affects Versions: 3.0.0
>Reporter: Andras Katona
>Assignee: Ramesh Mani
>Priority: Major
> Fix For: 3.0.0
>
> Time Spent: 20m
> Remaining Estimate: 0h
>
> In Kafka 2.8 this new authorization method was introduced mainly to ease
> authorization (setup) of idempotent producers.
> The default implementation of {{authorizeByResourceType}} uses
> [acls()|https://github.com/apache/kafka/blob/a3c7017ff7e543b50f84110195690a253f19d9cf/clients/src/main/java/org/apache/kafka/server/authorizer/Authorizer.java#L154]
> which is [not
> implemented|https://github.com/apache/ranger/blob/fc7ad98fbb2ee7bb7d4cd3329abc438a73e0444a/plugin-kafka/src/main/java/org/apache/ranger/authorization/kafka/authorizer/RangerKafkaAuthorizer.java#L332-L335]
> in Kafka Ranger Plugin, but it is not really efficient and it is recommended
> to implement/override it in custom authorizer implementation (meaning Ranger
> in our case).
> {code}
> /**
> * Check if the caller is authorized to perform the given ACL operation
> on at least one
> * resource of the given type.
> *
> * Custom authorizer implementations should consider overriding this
> default implementation because:
> * 1. The default implementation iterates all AclBindings multiple times,
> without any caching
> *by principal, host, operation, permission types, and resource
> types. More efficient
> *implementations may be added in custom authorizers that directly
> access cached entries.
> * 2. The default implementation cannot integrate with any audit logging
> included in the
> *authorizer implementation.
> * 3. The default implementation does not support any custom authorizer
> configs or other access
> *rules apart from ACLs.
> *
> * @param requestContext Request context including request resourceType,
> security protocol and listener name
> * @param op The ACL operation to check
> * @param resourceType The resource type to check
> * @return Return {@link AuthorizationResult#ALLOWED} if
> the caller is authorized
> * to perform the given ACL operation on at least
> one resource of the
> * given type. Return {@link
> AuthorizationResult#DENIED} otherwise.
> */
> default AuthorizationResult
> authorizeByResourceType(AuthorizableRequestContext requestContext,
> AclOperation op, ResourceType resourceType) {
> {code}
> In Kafka 3.0.1, 3.1.1 and 3.2.0, producers are idempotent by default
> (KAFKA-13598) and the authorization of producer initialization fails, in case
> the user doesn't have the deprecated idempotent_write access, as it will call
> the {{authorizeByResourceType}} and that calls {{acls}}.
> {code}
> public Iterable acls(AclBindingFilter filter) {
> logger.error("(getting) acls is not supported by Ranger for Kafka");
> throw new UnsupportedOperationException("(getting) acls is not supported
> by Ranger for Kafka");
> }
> {code}
> With [this
> commit|https://github.com/apache/ranger/commit/0ec279474e0439f6c5e7d4497db191fb7cc99bc1]
> {{authorizeByResourceType}} got an implementation with a basic validation
> check and a (constant) denial response. It's just making
> UnsupportedOperationException disappear and having an expected response for
> initProducer authorization.
> Until the proper implementation is done, the idempotent_write access should
> be granted for the producer.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (RANGER-4061) Grant and Revoke Request should support Allow Exception
[ https://issues.apache.org/jira/browse/RANGER-4061?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ramesh Mani updated RANGER-4061: Fix Version/s: 3.0.0 > Grant and Revoke Request should support Allow Exception > > > Key: RANGER-4061 > URL: https://issues.apache.org/jira/browse/RANGER-4061 > Project: Ranger > Issue Type: Improvement > Components: Ranger >Affects Versions: 3.0.0 >Reporter: Ramesh Mani >Assignee: Ramesh Mani >Priority: Major > Fix For: 3.0.0 > > > Current Grant and Revoke functionality in Apache Ranger Supports only request > to create Allowed Permission. But there are services like Kafka where the ACL > grant can have clauses like allow certain users / Groups / hosts except users > / Groups / hosts. > For this enhance the current Ranger Grant Revoke Api to include a new member > to hold the “AllowException” policyItem which can be added by the services > which supports this. > By this enhancement Grant Revoke Api will add the “Allow Exception” > policyItem for the policy that will be created. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Assigned] (RANGER-3939) Implement acls, createAcls and deleteAcls in Kafka Authorizer
[ https://issues.apache.org/jira/browse/RANGER-3939?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ramesh Mani reassigned RANGER-3939: --- Assignee: Ramesh Mani > Implement acls, createAcls and deleteAcls in Kafka Authorizer > - > > Key: RANGER-3939 > URL: https://issues.apache.org/jira/browse/RANGER-3939 > Project: Ranger > Issue Type: Improvement > Components: plugins >Reporter: Daniel Urban >Assignee: Ramesh Mani >Priority: Major > > Currently, the Kafka Authorizer only implements the .authorize method. This > is (mostly) enough to support authorization checks in the Kafka API endpoints. > But the Kafka protocol also has support for describing and managing ACLs. > These endpoints do not work with the Ranger plugin, as it requires the acls, > createAcls and deleteAcls endpoints to be correctly implemented. This can > cause issues with tools and clients relying on the Kafka ACL API. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Comment Edited] (RANGER-4165) Support SELF_OR_PREFIX resource matching scope in Ranger Authorization
[ https://issues.apache.org/jira/browse/RANGER-4165?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17723252#comment-17723252 ] Ramesh Mani edited comment on RANGER-4165 at 5/25/23 3:31 PM: -- Attached reworked Patch from [~madhan] [https://reviews.apache.org/r/74454/diff/3#0] [~abhayk] Please review this patch. Thanks. was (Author: rmani): Attached reworked Patch from [~madhan] [https://reviews.apache.org/r/74441/] [~abhayk] Please review this patch. Thanks. > Support SELF_OR_PREFIX resource matching scope in Ranger Authorization > --- > > Key: RANGER-4165 > URL: https://issues.apache.org/jira/browse/RANGER-4165 > Project: Ranger > Issue Type: Improvement > Components: Ranger >Affects Versions: 3.0.0 >Reporter: Ramesh Mani >Assignee: Madhan Neethiraj >Priority: Major > > Support SELF_OR_PREFIX resource matching scope in Ranger Authorization > * introduced resource-element matching scope SELF_OR_PREFIX, which can be > used to ask Ranger policy engine the following -- check if a user/group/role > has read access in any path/file under directory /dept/hr/ -- check if a > user/group/role has select access to any table having name that starts with > emp_ under database name hr > * moved SELF_OR_CHILD from enum resource-matching-scope to enum > resource-element-matching-scope > This is need to create an api which can find whether a user/group is > authorized to the given operation on any resource of give type. > This is needed to implement a Ranger Kafka authorizer API which checks if the > caller is authorized to perform the given ACL operation on at least one > resource of the given type. > [https://kafka.apache.org/28/javadoc/org/apache/kafka/server/authorizer/Authorizer.html#authorizeByResourceType(org.apache.kafka.server.authorizer.AuthorizableRequestContext,org.apache.kafka.common.acl.AclOperation,org.apache.kafka.common.resource.ResourceType]) -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (RANGER-4165) Support SELF_OR_PREFIX resource matching scope in Ranger Authorization
[ https://issues.apache.org/jira/browse/RANGER-4165?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ramesh Mani updated RANGER-4165: Description: Support SELF_OR_PREFIX resource matching scope in Ranger Authorization * introduced resource-element matching scope SELF_OR_PREFIX, which can be used to ask Ranger policy engine the following -- check if a user/group/role has read access in any path/file under directory /dept/hr/ -- check if a user/group/role has select access to any table having name that starts with emp_ under database name hr * moved SELF_OR_CHILD from enum resource-matching-scope to enum resource-element-matching-scope This is need to create an api which can find whether a user/group is authorized to the given operation on any resource of give type. This is needed to implement a Ranger Kafka authorizer API which checks if the caller is authorized to perform the given ACL operation on at least one resource of the given type. [https://kafka.apache.org/28/javadoc/org/apache/kafka/server/authorizer/Authorizer.html#authorizeByResourceType(org.apache.kafka.server.authorizer.AuthorizableRequestContext,org.apache.kafka.common.acl.AclOperation,org.apache.kafka.common.resource.ResourceType]) was: Support SELF_OR_PREFIX resource matching scope in Ranger Authorization This is need to create an api which can find whether a user/group is authorized to the given operation on any resource of give type. This is needed to implement a Ranger Kafka authorizer API which checks if the caller is authorized to perform the given ACL operation on at least one resource of the given type. [https://kafka.apache.org/28/javadoc/org/apache/kafka/server/authorizer/Authorizer.html#authorizeByResourceType(org.apache.kafka.server.authorizer.AuthorizableRequestContext,org.apache.kafka.common.acl.AclOperation,org.apache.kafka.common.resource.ResourceType]) > Support SELF_OR_PREFIX resource matching scope in Ranger Authorization > --- > > Key: RANGER-4165 > URL: https://issues.apache.org/jira/browse/RANGER-4165 > Project: Ranger > Issue Type: Improvement > Components: Ranger >Affects Versions: 3.0.0 >Reporter: Ramesh Mani >Assignee: Madhan Neethiraj >Priority: Major > > Support SELF_OR_PREFIX resource matching scope in Ranger Authorization > * introduced resource-element matching scope SELF_OR_PREFIX, which can be > used to ask Ranger policy engine the following -- check if a user/group/role > has read access in any path/file under directory /dept/hr/ -- check if a > user/group/role has select access to any table having name that starts with > emp_ under database name hr > * moved SELF_OR_CHILD from enum resource-matching-scope to enum > resource-element-matching-scope > This is need to create an api which can find whether a user/group is > authorized to the given operation on any resource of give type. > This is needed to implement a Ranger Kafka authorizer API which checks if the > caller is authorized to perform the given ACL operation on at least one > resource of the given type. > [https://kafka.apache.org/28/javadoc/org/apache/kafka/server/authorizer/Authorizer.html#authorizeByResourceType(org.apache.kafka.server.authorizer.AuthorizableRequestContext,org.apache.kafka.common.acl.AclOperation,org.apache.kafka.common.resource.ResourceType]) -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Comment Edited] (RANGER-4165) Support SELF_OR_PREFIX resource matching scope in Ranger Authorization
[ https://issues.apache.org/jira/browse/RANGER-4165?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17723252#comment-17723252 ] Ramesh Mani edited comment on RANGER-4165 at 5/24/23 3:10 PM: -- Attached reworked Patch from [~madhan] [https://reviews.apache.org/r/74441/] [~abhayk] Please review this patch. Thanks. was (Author: rmani): Attached reworked Patch from [~madhan] [https://reviews.apache.org/r/74441/diff/2#index_header] [~abhayk] Please review this patch. Thanks. > Support SELF_OR_PREFIX resource matching scope in Ranger Authorization > --- > > Key: RANGER-4165 > URL: https://issues.apache.org/jira/browse/RANGER-4165 > Project: Ranger > Issue Type: Improvement > Components: Ranger >Affects Versions: 3.0.0 >Reporter: Ramesh Mani >Assignee: Madhan Neethiraj >Priority: Major > > Support SELF_OR_PREFIX resource matching scope in Ranger Authorization > This is need to create an api which can find whether a user/group is > authorized to the given operation on any resource of give type. > This is needed to implement a Ranger Kafka authorizer API which checks if the > caller is authorized to perform the given ACL operation on at least one > resource of the given type. > [https://kafka.apache.org/28/javadoc/org/apache/kafka/server/authorizer/Authorizer.html#authorizeByResourceType(org.apache.kafka.server.authorizer.AuthorizableRequestContext,org.apache.kafka.common.acl.AclOperation,org.apache.kafka.common.resource.ResourceType]) -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Assigned] (RANGER-4165) Support SELF_OR_PREFIX resource matching scope in Ranger Authorization
[ https://issues.apache.org/jira/browse/RANGER-4165?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ramesh Mani reassigned RANGER-4165: --- Assignee: Madhan Neethiraj (was: Ramesh Mani) > Support SELF_OR_PREFIX resource matching scope in Ranger Authorization > --- > > Key: RANGER-4165 > URL: https://issues.apache.org/jira/browse/RANGER-4165 > Project: Ranger > Issue Type: Improvement > Components: Ranger >Affects Versions: 3.0.0 >Reporter: Ramesh Mani >Assignee: Madhan Neethiraj >Priority: Major > > Support SELF_OR_PREFIX resource matching scope in Ranger Authorization > This is need to create an api which can find whether a user/group is > authorized to the given operation on any resource of give type. > This is needed to implement a Ranger Kafka authorizer API which checks if the > caller is authorized to perform the given ACL operation on at least one > resource of the given type. > [https://kafka.apache.org/28/javadoc/org/apache/kafka/server/authorizer/Authorizer.html#authorizeByResourceType(org.apache.kafka.server.authorizer.AuthorizableRequestContext,org.apache.kafka.common.acl.AclOperation,org.apache.kafka.common.resource.ResourceType]) -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Comment Edited] (RANGER-4165) Support SELF_OR_PREFIX resource matching scope in Ranger Authorization
[ https://issues.apache.org/jira/browse/RANGER-4165?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17723252#comment-17723252 ] Ramesh Mani edited comment on RANGER-4165 at 5/23/23 7:24 PM: -- Attached reworked Patch from [~madhan] [https://reviews.apache.org/r/74441/diff/2#index_header] [~abhayk] Please review this patch. Thanks. was (Author: rmani): Attached reworked Patch from [~madhan] [https://reviews.apache.org/r/74441/diff/1#index_header] [~abhayk] Please review this patch. Thanks. > Support SELF_OR_PREFIX resource matching scope in Ranger Authorization > --- > > Key: RANGER-4165 > URL: https://issues.apache.org/jira/browse/RANGER-4165 > Project: Ranger > Issue Type: Improvement > Components: Ranger >Affects Versions: 3.0.0 >Reporter: Ramesh Mani >Assignee: Ramesh Mani >Priority: Major > > Support SELF_OR_PREFIX resource matching scope in Ranger Authorization > This is need to create an api which can find whether a user/group is > authorized to the given operation on any resource of give type. > This is needed to implement a Ranger Kafka authorizer API which checks if the > caller is authorized to perform the given ACL operation on at least one > resource of the given type. > [https://kafka.apache.org/28/javadoc/org/apache/kafka/server/authorizer/Authorizer.html#authorizeByResourceType(org.apache.kafka.server.authorizer.AuthorizableRequestContext,org.apache.kafka.common.acl.AclOperation,org.apache.kafka.common.resource.ResourceType]) -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (RANGER-4165) Support SELF_OR_PREFIX resource matching scope in Ranger Authorization
[ https://issues.apache.org/jira/browse/RANGER-4165?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ramesh Mani updated RANGER-4165: Description: Support SELF_OR_PREFIX resource matching scope in Ranger Authorization This is need to create an api which can find whether a user/group is authorized to the given operation on any resource of give type. This is needed to implement a Ranger Kafka authorizer API which checks if the caller is authorized to perform the given ACL operation on at least one resource of the given type. [https://kafka.apache.org/28/javadoc/org/apache/kafka/server/authorizer/Authorizer.html#authorizeByResourceType(org.apache.kafka.server.authorizer.AuthorizableRequestContext,org.apache.kafka.common.acl.AclOperation,org.apache.kafka.common.resource.ResourceType]) was: API to find whether a user/group is authorized to the given operation on any resource of give type. This is needed to implement a Ranger Kafka authorizer API which checks if the caller is authorized to perform the given ACL operation on at least one resource of the given type. [https://kafka.apache.org/28/javadoc/org/apache/kafka/server/authorizer/Authorizer.html#authorizeByResourceType(org.apache.kafka.server.authorizer.AuthorizableRequestContext,org.apache.kafka.common.acl.AclOperation,org.apache.kafka.common.resource.ResourceType]) > Support SELF_OR_PREFIX resource matching scope in Ranger Authorization > --- > > Key: RANGER-4165 > URL: https://issues.apache.org/jira/browse/RANGER-4165 > Project: Ranger > Issue Type: Improvement > Components: Ranger >Affects Versions: 3.0.0 >Reporter: Ramesh Mani >Assignee: Ramesh Mani >Priority: Major > > Support SELF_OR_PREFIX resource matching scope in Ranger Authorization > This is need to create an api which can find whether a user/group is > authorized to the given operation on any resource of give type. > This is needed to implement a Ranger Kafka authorizer API which checks if the > caller is authorized to perform the given ACL operation on at least one > resource of the given type. > [https://kafka.apache.org/28/javadoc/org/apache/kafka/server/authorizer/Authorizer.html#authorizeByResourceType(org.apache.kafka.server.authorizer.AuthorizableRequestContext,org.apache.kafka.common.acl.AclOperation,org.apache.kafka.common.resource.ResourceType]) -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (RANGER-4165) Support SELF_OR_PREFIX resource matching scope in Ranger Authorization
[ https://issues.apache.org/jira/browse/RANGER-4165?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ramesh Mani updated RANGER-4165: Summary: Support SELF_OR_PREFIX resource matching scope in Ranger Authorization (was: API to find whether a user/group is authorized to the given operation on any resource of give type) > Support SELF_OR_PREFIX resource matching scope in Ranger Authorization > --- > > Key: RANGER-4165 > URL: https://issues.apache.org/jira/browse/RANGER-4165 > Project: Ranger > Issue Type: Improvement > Components: Ranger >Affects Versions: 3.0.0 >Reporter: Ramesh Mani >Assignee: Ramesh Mani >Priority: Major > > API to find whether a user/group is authorized to the given operation on any > resource of give type. > This is needed to implement a Ranger Kafka authorizer API which checks if the > caller is authorized to perform the given ACL operation on at least one > resource of the given type. > [https://kafka.apache.org/28/javadoc/org/apache/kafka/server/authorizer/Authorizer.html#authorizeByResourceType(org.apache.kafka.server.authorizer.AuthorizableRequestContext,org.apache.kafka.common.acl.AclOperation,org.apache.kafka.common.resource.ResourceType]) -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (RANGER-4165) API to find whether a user/group is authorized to the given operation on any resource of give type
[ https://issues.apache.org/jira/browse/RANGER-4165?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17723252#comment-17723252 ] Ramesh Mani commented on RANGER-4165: - Attached reworked Patch from [~madhan] [https://reviews.apache.org/r/74441/diff/1#index_header] [~abhayk] Please review this patch. Thanks. > API to find whether a user/group is authorized to the given operation on any > resource of give type > -- > > Key: RANGER-4165 > URL: https://issues.apache.org/jira/browse/RANGER-4165 > Project: Ranger > Issue Type: Improvement > Components: Ranger >Affects Versions: 3.0.0 >Reporter: Ramesh Mani >Assignee: Ramesh Mani >Priority: Major > > API to find whether a user/group is authorized to the given operation on any > resource of give type. > This is needed to implement a Ranger Kafka authorizer API which checks if the > caller is authorized to perform the given ACL operation on at least one > resource of the given type. > [https://kafka.apache.org/28/javadoc/org/apache/kafka/server/authorizer/Authorizer.html#authorizeByResourceType(org.apache.kafka.server.authorizer.AuthorizableRequestContext,org.apache.kafka.common.acl.AclOperation,org.apache.kafka.common.resource.ResourceType]) -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (RANGER-4165) API to find whether a user/group is authorized to the given operation on any resource of give type
[ https://issues.apache.org/jira/browse/RANGER-4165?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ramesh Mani updated RANGER-4165: Summary: API to find whether a user/group is authorized to the given operation on any resource of give type (was: API to find whether a user/group is authorized to the give operation on any resource of give type) > API to find whether a user/group is authorized to the given operation on any > resource of give type > -- > > Key: RANGER-4165 > URL: https://issues.apache.org/jira/browse/RANGER-4165 > Project: Ranger > Issue Type: Improvement > Components: Ranger >Affects Versions: 3.0.0 >Reporter: Ramesh Mani >Assignee: Ramesh Mani >Priority: Major > > API to find whether a user/group is authorized to the given operation on any > resource of give type. > This is needed to implement a Ranger Kafka authorizer API which checks if the > caller is authorized to perform the given ACL operation on at least one > resource of the given type. > [https://kafka.apache.org/28/javadoc/org/apache/kafka/server/authorizer/Authorizer.html#authorizeByResourceType(org.apache.kafka.server.authorizer.AuthorizableRequestContext,org.apache.kafka.common.acl.AclOperation,org.apache.kafka.common.resource.ResourceType]) -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (RANGER-4165) API to find whether a user/group is authorized to the give operation on any resource of give type
[ https://issues.apache.org/jira/browse/RANGER-4165?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ramesh Mani updated RANGER-4165: Description: API to find whether a user/group is authorized to the given operation on any resource of give type. This is needed to implement a Ranger Kafka authorizer API which checks if the caller is authorized to perform the given ACL operation on at least one resource of the given type. [https://kafka.apache.org/28/javadoc/org/apache/kafka/server/authorizer/Authorizer.html#authorizeByResourceType(org.apache.kafka.server.authorizer.AuthorizableRequestContext,org.apache.kafka.common.acl.AclOperation,org.apache.kafka.common.resource.ResourceType]) was: API to find whether a user/group is authorized to the give operation on any resource of give type. This is needed to implement a Ranger Kafka authorizer API which checks if the caller is authorized to perform the given ACL operation on at least one resource of the given type. https://kafka.apache.org/28/javadoc/org/apache/kafka/server/authorizer/Authorizer.html#authorizeByResourceType(org.apache.kafka.server.authorizer.AuthorizableRequestContext,org.apache.kafka.common.acl.AclOperation,org.apache.kafka.common.resource.ResourceType) > API to find whether a user/group is authorized to the give operation on any > resource of give type > - > > Key: RANGER-4165 > URL: https://issues.apache.org/jira/browse/RANGER-4165 > Project: Ranger > Issue Type: Improvement > Components: Ranger >Affects Versions: 3.0.0 >Reporter: Ramesh Mani >Assignee: Ramesh Mani >Priority: Major > > API to find whether a user/group is authorized to the given operation on any > resource of give type. > This is needed to implement a Ranger Kafka authorizer API which checks if the > caller is authorized to perform the given ACL operation on at least one > resource of the given type. > [https://kafka.apache.org/28/javadoc/org/apache/kafka/server/authorizer/Authorizer.html#authorizeByResourceType(org.apache.kafka.server.authorizer.AuthorizableRequestContext,org.apache.kafka.common.acl.AclOperation,org.apache.kafka.common.resource.ResourceType]) -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (RANGER-4165) API to find whether a user/group is authorized to the give operation on any resource of give type
[ https://issues.apache.org/jira/browse/RANGER-4165?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17707430#comment-17707430 ] Ramesh Mani commented on RANGER-4165: - [~mad...@apache.org] Thanks for the clarification and suggestion. I shall check on this. > API to find whether a user/group is authorized to the give operation on any > resource of give type > - > > Key: RANGER-4165 > URL: https://issues.apache.org/jira/browse/RANGER-4165 > Project: Ranger > Issue Type: Improvement > Components: Ranger >Affects Versions: 3.0.0 >Reporter: Ramesh Mani >Assignee: Ramesh Mani >Priority: Major > > API to find whether a user/group is authorized to the give operation on any > resource of give type. > This is needed to implement a Ranger Kafka authorizer API which checks if the > caller is authorized to perform the given ACL operation on at least one > resource of the given type. > https://kafka.apache.org/28/javadoc/org/apache/kafka/server/authorizer/Authorizer.html#authorizeByResourceType(org.apache.kafka.server.authorizer.AuthorizableRequestContext,org.apache.kafka.common.acl.AclOperation,org.apache.kafka.common.resource.ResourceType) -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (RANGER-4165) API to find whether a user/group is authorized to the give operation on any resource of give type
[ https://issues.apache.org/jira/browse/RANGER-4165?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ramesh Mani updated RANGER-4165: Affects Version/s: 3.0.0 > API to find whether a user/group is authorized to the give operation on any > resource of give type > - > > Key: RANGER-4165 > URL: https://issues.apache.org/jira/browse/RANGER-4165 > Project: Ranger > Issue Type: Improvement > Components: Ranger >Affects Versions: 3.0.0 >Reporter: Ramesh Mani >Assignee: Ramesh Mani >Priority: Major > > API to find whether a user/group is authorized to the give operation on any > resource of give type. > This is needed to implement a Ranger Kafka authorizer API which checks if the > caller is authorized to perform the given ACL operation on at least one > resource of the given type. > https://kafka.apache.org/28/javadoc/org/apache/kafka/server/authorizer/Authorizer.html#authorizeByResourceType(org.apache.kafka.server.authorizer.AuthorizableRequestContext,org.apache.kafka.common.acl.AclOperation,org.apache.kafka.common.resource.ResourceType) -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Comment Edited] (RANGER-4165) API to find whether a user/group is authorized to the give operation on any resource of give type
[ https://issues.apache.org/jira/browse/RANGER-4165?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17707395#comment-17707395 ] Ramesh Mani edited comment on RANGER-4165 at 3/31/23 7:02 PM: -- [~mad...@apache.org] [~abhayk] Currently policeEngine apis doesn't have a way to figure of this request. All we can do it run through all the polices and find all the resources of given type and run the authorizer for each of those resources found for the caller. This may not be the efficient way to get the result. Is there a better way to find this like having cache for resources in the policies and run through the policy engine? was (Author: rmani): [~mad...@apache.org] [~abhayk] Currently policeEngine apis doesn't have a way to figure of this request. All we can do it run through all the polices and find all the resources of given type and run the authorizer for each of those resources found for the call. This may not be the efficient way to get the result. Is there a better way to find this like having cache for resources in the policies and run through the policy engine? > API to find whether a user/group is authorized to the give operation on any > resource of give type > - > > Key: RANGER-4165 > URL: https://issues.apache.org/jira/browse/RANGER-4165 > Project: Ranger > Issue Type: Improvement > Components: Ranger >Reporter: Ramesh Mani >Assignee: Ramesh Mani >Priority: Major > > API to find whether a user/group is authorized to the give operation on any > resource of give type. > This is needed to implement a Ranger Kafka authorizer API which checks if the > caller is authorized to perform the given ACL operation on at least one > resource of the given type. > https://kafka.apache.org/28/javadoc/org/apache/kafka/server/authorizer/Authorizer.html#authorizeByResourceType(org.apache.kafka.server.authorizer.AuthorizableRequestContext,org.apache.kafka.common.acl.AclOperation,org.apache.kafka.common.resource.ResourceType) -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (RANGER-4165) API to find whether a user/group is authorized to the give operation on any resource of give type
[ https://issues.apache.org/jira/browse/RANGER-4165?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17707395#comment-17707395 ] Ramesh Mani commented on RANGER-4165: - [~mad...@apache.org] [~abhayk] Currently policeEngine apis doesn't have a way to figure of this request. All we can do it run through all the polices and find all the resources of given type and run the authorizer for each of those resources found for the call. This may not be the efficient way to get the result. Is there a better way to find this like having cache for resources in the policies and run through the policy engine? > API to find whether a user/group is authorized to the give operation on any > resource of give type > - > > Key: RANGER-4165 > URL: https://issues.apache.org/jira/browse/RANGER-4165 > Project: Ranger > Issue Type: Improvement > Components: Ranger >Reporter: Ramesh Mani >Assignee: Ramesh Mani >Priority: Major > > API to find whether a user/group is authorized to the give operation on any > resource of give type. > This is needed to implement a Ranger Kafka authorizer API which checks if the > caller is authorized to perform the given ACL operation on at least one > resource of the given type. > https://kafka.apache.org/28/javadoc/org/apache/kafka/server/authorizer/Authorizer.html#authorizeByResourceType(org.apache.kafka.server.authorizer.AuthorizableRequestContext,org.apache.kafka.common.acl.AclOperation,org.apache.kafka.common.resource.ResourceType) -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Assigned] (RANGER-4165) API to find whether a user/group is authorized to the give operation on any resource of give type
[ https://issues.apache.org/jira/browse/RANGER-4165?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ramesh Mani reassigned RANGER-4165: --- Assignee: Ramesh Mani > API to find whether a user/group is authorized to the give operation on any > resource of give type > - > > Key: RANGER-4165 > URL: https://issues.apache.org/jira/browse/RANGER-4165 > Project: Ranger > Issue Type: Improvement > Components: Ranger >Reporter: Ramesh Mani >Assignee: Ramesh Mani >Priority: Major > > API to find whether a user/group is authorized to the give operation on any > resource of give type. > This is needed to implement a Ranger Kafka authorizer API which checks if the > caller is authorized to perform the given ACL operation on at least one > resource of the given type. > https://kafka.apache.org/28/javadoc/org/apache/kafka/server/authorizer/Authorizer.html#authorizeByResourceType(org.apache.kafka.server.authorizer.AuthorizableRequestContext,org.apache.kafka.common.acl.AclOperation,org.apache.kafka.common.resource.ResourceType) -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Created] (RANGER-4165) API to find whether a user/group is authorized to the give operation on any resource of give type
Ramesh Mani created RANGER-4165: --- Summary: API to find whether a user/group is authorized to the give operation on any resource of give type Key: RANGER-4165 URL: https://issues.apache.org/jira/browse/RANGER-4165 Project: Ranger Issue Type: Improvement Components: Ranger Reporter: Ramesh Mani API to find whether a user/group is authorized to the give operation on any resource of give type. This is needed to implement a Ranger Kafka authorizer API which checks if the caller is authorized to perform the given ACL operation on at least one resource of the given type. https://kafka.apache.org/28/javadoc/org/apache/kafka/server/authorizer/Authorizer.html#authorizeByResourceType(org.apache.kafka.server.authorizer.AuthorizableRequestContext,org.apache.kafka.common.acl.AclOperation,org.apache.kafka.common.resource.ResourceType) -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (RANGER-4061) Grant and Revoke Request should support Allow Exception
[ https://issues.apache.org/jira/browse/RANGER-4061?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ramesh Mani updated RANGER-4061: Description: Current Grant and Revoke functionality in Apache Ranger Supports only request to create Allowed Permission. But there are services like Kafka where the ACL grant can have clauses like allow certain users / Groups/ hosts except users /Groups/ hosts. For this enhance the current Ranger Grant Revoke Api to include a new member to hold the “AllowException” policyItem which can be added by the services which supports this. By this enhancement Grant Revoke Api will add the “Allow Exception” policyItem for the policy that will be created. was: Current Grant and Revoke functionally in Apache Ranger Supports only request to create Allowed Permission. But there are services like Kafka where the ACL grant can have clauses like allow certain users / Groups/ hosts except users /Groups/ hosts. For this enhance the current Ranger Grant Revoke Api to include a new member to hold the “AllowException” policyItem which can be added by the services which supports this. By this enhancement Grant Revoke Api will add the “Allow Exception” policyItem for the policy that will be created. > Grant and Revoke Request should support Allow Exception > > > Key: RANGER-4061 > URL: https://issues.apache.org/jira/browse/RANGER-4061 > Project: Ranger > Issue Type: Improvement > Components: Ranger >Affects Versions: 3.0.0 >Reporter: Ramesh Mani >Assignee: Ramesh Mani >Priority: Major > > Current Grant and Revoke functionality in Apache Ranger Supports only request > to create Allowed Permission. But there are services like Kafka where the ACL > grant can have clauses like allow certain users / Groups/ hosts except users > /Groups/ hosts. > For this enhance the current Ranger Grant Revoke Api to include a new member > to hold the “AllowException” policyItem which can be added by the services > which supports this. > By this enhancement Grant Revoke Api will add the “Allow Exception” > policyItem for the policy that will be created. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (RANGER-4061) Grant and Revoke Request should support Allow Exception
[ https://issues.apache.org/jira/browse/RANGER-4061?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ramesh Mani updated RANGER-4061: Description: Current Grant and Revoke functionality in Apache Ranger Supports only request to create Allowed Permission. But there are services like Kafka where the ACL grant can have clauses like allow certain users / Groups / hosts except users / Groups / hosts. For this enhance the current Ranger Grant Revoke Api to include a new member to hold the “AllowException” policyItem which can be added by the services which supports this. By this enhancement Grant Revoke Api will add the “Allow Exception” policyItem for the policy that will be created. was: Current Grant and Revoke functionality in Apache Ranger Supports only request to create Allowed Permission. But there are services like Kafka where the ACL grant can have clauses like allow certain users / Groups/ hosts except users /Groups/ hosts. For this enhance the current Ranger Grant Revoke Api to include a new member to hold the “AllowException” policyItem which can be added by the services which supports this. By this enhancement Grant Revoke Api will add the “Allow Exception” policyItem for the policy that will be created. > Grant and Revoke Request should support Allow Exception > > > Key: RANGER-4061 > URL: https://issues.apache.org/jira/browse/RANGER-4061 > Project: Ranger > Issue Type: Improvement > Components: Ranger >Affects Versions: 3.0.0 >Reporter: Ramesh Mani >Assignee: Ramesh Mani >Priority: Major > > Current Grant and Revoke functionality in Apache Ranger Supports only request > to create Allowed Permission. But there are services like Kafka where the ACL > grant can have clauses like allow certain users / Groups / hosts except users > / Groups / hosts. > For this enhance the current Ranger Grant Revoke Api to include a new member > to hold the “AllowException” policyItem which can be added by the services > which supports this. > By this enhancement Grant Revoke Api will add the “Allow Exception” > policyItem for the policy that will be created. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (RANGER-4061) Grant and Revoke Request should support Allow Exception
[ https://issues.apache.org/jira/browse/RANGER-4061?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17681887#comment-17681887 ] Ramesh Mani commented on RANGER-4061: - [~mad...@apache.org] [~abhayk] Please review this propose solution and give your comments. > Grant and Revoke Request should support Allow Exception > > > Key: RANGER-4061 > URL: https://issues.apache.org/jira/browse/RANGER-4061 > Project: Ranger > Issue Type: Improvement > Components: Ranger >Affects Versions: 3.0.0 >Reporter: Ramesh Mani >Assignee: Ramesh Mani >Priority: Major > > Current Grant and Revoke functionally in Apache Ranger Supports only request > to create Allowed Permission. But there are services like Kafka where the ACL > grant can have clauses like allow certain users / Groups/ hosts except users > /Groups/ hosts. > For this enhance the current Ranger Grant Revoke Api to include a new member > to hold the “AllowException” policyItem which can be added by the services > which supports this. > By this enhancement Grant Revoke Api will add the “Allow Exception” > policyItem for the policy that will be created. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Created] (RANGER-4061) Grant and Revoke Request should support Allow Exception
Ramesh Mani created RANGER-4061: --- Summary: Grant and Revoke Request should support Allow Exception Key: RANGER-4061 URL: https://issues.apache.org/jira/browse/RANGER-4061 Project: Ranger Issue Type: Improvement Components: Ranger Affects Versions: 3.0.0 Reporter: Ramesh Mani Assignee: Ramesh Mani Current Grant and Revoke functionally in Apache Ranger Supports only request to create Allowed Permission. But there are services like Kafka where the ACL grant can have clauses like allow certain users / Groups/ hosts except users /Groups/ hosts. For this enhance the current Ranger Grant Revoke Api to include a new member to hold the “AllowException” policyItem which can be added by the services which supports this. By this enhancement Grant Revoke Api will add the “Allow Exception” policyItem for the policy that will be created. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (RANGER-3896) Update Ozone dependency version to latest 1.3.0
[ https://issues.apache.org/jira/browse/RANGER-3896?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17655583#comment-17655583 ] Ramesh Mani commented on RANGER-3896: - [~neilj] This is committed to ranger master branch [https://github.com/apache/ranger/commit/3fb89d1aad154c0ff70c77e81bb6ac101380011d.|https://github.com/apache/ranger/commit/3fb89d1aad154c0ff70c77e81bb6ac101380011d] Please close the Review Request and this JIRA. Thank you for the contributions! > Update Ozone dependency version to latest 1.3.0 > --- > > Key: RANGER-3896 > URL: https://issues.apache.org/jira/browse/RANGER-3896 > Project: Ranger > Issue Type: Bug > Components: plugins, Ranger >Affects Versions: 3.0.0 >Reporter: Neil Joshi >Assignee: Neil Joshi >Priority: Major > Fix For: 3.0.0 > > Time Spent: 10m > Remaining Estimate: 0h > > update Ozone dependency in pom build file from 1.0.0 to latest Ozone version > 1.3.0 -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (RANGER-3896) Update Ozone dependency version to latest 1.3.0
[ https://issues.apache.org/jira/browse/RANGER-3896?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ramesh Mani updated RANGER-3896: Affects Version/s: (was: 2.4.0) > Update Ozone dependency version to latest 1.3.0 > --- > > Key: RANGER-3896 > URL: https://issues.apache.org/jira/browse/RANGER-3896 > Project: Ranger > Issue Type: Bug > Components: plugins, Ranger >Affects Versions: 3.0.0 >Reporter: Neil Joshi >Assignee: Neil Joshi >Priority: Major > Time Spent: 10m > Remaining Estimate: 0h > > update Ozone dependency in pom build file from 1.0.0 to latest Ozone version > 1.3.0 -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (RANGER-3896) Update Ozone dependency version to latest 1.3.0
[ https://issues.apache.org/jira/browse/RANGER-3896?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ramesh Mani updated RANGER-3896: Fix Version/s: 3.0.0 > Update Ozone dependency version to latest 1.3.0 > --- > > Key: RANGER-3896 > URL: https://issues.apache.org/jira/browse/RANGER-3896 > Project: Ranger > Issue Type: Bug > Components: plugins, Ranger >Affects Versions: 3.0.0 >Reporter: Neil Joshi >Assignee: Neil Joshi >Priority: Major > Fix For: 3.0.0 > > Time Spent: 10m > Remaining Estimate: 0h > > update Ozone dependency in pom build file from 1.0.0 to latest Ozone version > 1.3.0 -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (RANGER-3896) Update Ozone dependency version to latest 1.3.0
[ https://issues.apache.org/jira/browse/RANGER-3896?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ramesh Mani updated RANGER-3896: Affects Version/s: 3.0.0 2.4.0 > Update Ozone dependency version to latest 1.3.0 > --- > > Key: RANGER-3896 > URL: https://issues.apache.org/jira/browse/RANGER-3896 > Project: Ranger > Issue Type: Bug > Components: plugins, Ranger >Affects Versions: 3.0.0, 2.4.0 >Reporter: Neil Joshi >Assignee: Neil Joshi >Priority: Major > Time Spent: 10m > Remaining Estimate: 0h > > update Ozone dependency in pom build file from 1.0.0 to latest Ozone version > 1.3.0 -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (RANGER-3896) Update Ozone dependency version to latest 1.3.0
[ https://issues.apache.org/jira/browse/RANGER-3896?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17650068#comment-17650068 ] Ramesh Mani commented on RANGER-3896: - [~NeilJoshi] could you please the the "ranger" group added to the Review request [https://reviews.apache.org/r/74263/ |https://reviews.apache.org/r/74263/] Looks like we don't have the permission to review it. > Update Ozone dependency version to latest 1.3.0 > --- > > Key: RANGER-3896 > URL: https://issues.apache.org/jira/browse/RANGER-3896 > Project: Ranger > Issue Type: Bug > Components: plugins, Ranger >Reporter: Neil Joshi >Priority: Major > Time Spent: 10m > Remaining Estimate: 0h > > update Ozone dependency in pom build file from 1.0.0 to latest Ozone version > 1.3.0 -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (RANGER-3400) Include htrace-core.jar in tagsync, usersync and kms module to avoid startup issue
[ https://issues.apache.org/jira/browse/RANGER-3400?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ramesh Mani updated RANGER-3400: Fix Version/s: (was: 2.2.0) > Include htrace-core.jar in tagsync, usersync and kms module to avoid startup > issue > -- > > Key: RANGER-3400 > URL: https://issues.apache.org/jira/browse/RANGER-3400 > Project: Ranger > Issue Type: Bug > Components: Ranger >Affects Versions: 3.0.0 >Reporter: Ramesh Mani >Assignee: Ramesh Mani >Priority: Major > Fix For: 3.0.0 > > > Include htrace-core.jar in tagsync, usersync and kms module to avoid startup > issue. > htrace-core.jar has been removed in RANGER-3340, but because of the Hadoop > version dependency we need to have this to avoid startup issue. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (RANGER-3400) Include htrace-core.jar in tagsync, usersync and kms module to avoid startup issue
[ https://issues.apache.org/jira/browse/RANGER-3400?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ramesh Mani updated RANGER-3400: Affects Version/s: (was: 2.2.0) > Include htrace-core.jar in tagsync, usersync and kms module to avoid startup > issue > -- > > Key: RANGER-3400 > URL: https://issues.apache.org/jira/browse/RANGER-3400 > Project: Ranger > Issue Type: Bug > Components: Ranger >Affects Versions: 3.0.0 >Reporter: Ramesh Mani >Assignee: Ramesh Mani >Priority: Major > Fix For: 3.0.0, 2.2.0 > > > Include htrace-core.jar in tagsync, usersync and kms module to avoid startup > issue. > htrace-core.jar has been removed in RANGER-3340, but because of the Hadoop > version dependency we need to have this to avoid startup issue. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (RANGER-3400) Include htrace-core.jar in tagsync, usersync and kms module to avoid startup issue
[ https://issues.apache.org/jira/browse/RANGER-3400?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17645925#comment-17645925 ] Ramesh Mani commented on RANGER-3400: - [~bpatel] Ranger uses Hadoop 3.3.0 version, but the fix is in 3.3.2 and 3.4.0. So hadoop upgrade has to happen which needs testing across the services. Should we create a task for Hadoop upgrade and do the htrace along with it? > Include htrace-core.jar in tagsync, usersync and kms module to avoid startup > issue > -- > > Key: RANGER-3400 > URL: https://issues.apache.org/jira/browse/RANGER-3400 > Project: Ranger > Issue Type: Bug > Components: Ranger >Affects Versions: 3.0.0, 2.2.0 >Reporter: Ramesh Mani >Assignee: Ramesh Mani >Priority: Major > Fix For: 3.0.0, 2.2.0 > > > Include htrace-core.jar in tagsync, usersync and kms module to avoid startup > issue. > htrace-core.jar has been removed in RANGER-3340, but because of the Hadoop > version dependency we need to have this to avoid startup issue. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Assigned] (RANGER-4001) Wrong permission check for Hive "Alter View as" command in Ranger HiveAuthorizer
[ https://issues.apache.org/jira/browse/RANGER-4001?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ramesh Mani reassigned RANGER-4001: --- Assignee: Ramesh Mani > Wrong permission check for Hive "Alter View as" command in Ranger > HiveAuthorizer > > > Key: RANGER-4001 > URL: https://issues.apache.org/jira/browse/RANGER-4001 > Project: Ranger > Issue Type: Bug > Components: Ranger >Affects Versions: 3.0.0, 2.4.0 >Reporter: Ramesh Mani >Assignee: Ramesh Mani >Priority: Minor > > Hive Alter View as command needs SELECT privilege alone for the selected > table to create view. > command : alter view v1 as select * from db.t1 > Expectation: This command needs alter permission for view v1, select > permission for table "t1" and select permission on database "db" > Current Behavior: Currently the Ranger requires ALTER permission for table > "t1" and database "db" in addition to ALTER permission for the view "v1" . > This behavior is not correct. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Created] (RANGER-4001) Wrong permission check for Hive "Alter View as" command in Ranger HiveAuthorizer
Ramesh Mani created RANGER-4001: --- Summary: Wrong permission check for Hive "Alter View as" command in Ranger HiveAuthorizer Key: RANGER-4001 URL: https://issues.apache.org/jira/browse/RANGER-4001 Project: Ranger Issue Type: Bug Components: Ranger Affects Versions: 3.0.0, 2.4.0 Reporter: Ramesh Mani Hive Alter View as command needs SELECT privilege alone for the selected table to create view. command : alter view v1 as select * from db.t1 Expectation: This command needs alter permission for view v1, select permission for table "t1" and select permission on database "db" Current Behavior: Currently the Ranger requires ALTER permission for table "t1" and database "db" in addition to ALTER permission for the view "v1" . This behavior is not correct. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (RANGER-3912) Ranger Policy report for a given user should fetch policies maintained for roles belonging to that user and groups
[ https://issues.apache.org/jira/browse/RANGER-3912?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ramesh Mani updated RANGER-3912: Fix Version/s: 2.4.0 > Ranger Policy report for a given user should fetch policies maintained for > roles belonging to that user and groups > --- > > Key: RANGER-3912 > URL: https://issues.apache.org/jira/browse/RANGER-3912 > Project: Ranger > Issue Type: Bug > Components: Ranger >Affects Versions: 3.0.0, 2.4.0 >Reporter: Ramesh Mani >Assignee: Ramesh Mani >Priority: Major > Fix For: 3.0.0, 2.4.0 > > > Ranger Policy report for a given user should fetch policies maintained for > roles belonging to that user and groups of the user. Current Policies that > are maintained for the roles are not considered and hence the report is not > accurate. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Resolved] (RANGER-3912) Ranger Policy report for a given user should fetch policies maintained for roles belonging to that user and groups
[ https://issues.apache.org/jira/browse/RANGER-3912?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ramesh Mani resolved RANGER-3912. - Resolution: Fixed > Ranger Policy report for a given user should fetch policies maintained for > roles belonging to that user and groups > --- > > Key: RANGER-3912 > URL: https://issues.apache.org/jira/browse/RANGER-3912 > Project: Ranger > Issue Type: Bug > Components: Ranger >Affects Versions: 3.0.0, 2.4.0 >Reporter: Ramesh Mani >Assignee: Ramesh Mani >Priority: Major > Fix For: 3.0.0, 2.4.0 > > > Ranger Policy report for a given user should fetch policies maintained for > roles belonging to that user and groups of the user. Current Policies that > are maintained for the roles are not considered and hence the report is not > accurate. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (RANGER-3912) Ranger Policy report for a given user should fetch policies maintained for roles belonging to that user and groups
[ https://issues.apache.org/jira/browse/RANGER-3912?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ramesh Mani updated RANGER-3912: Affects Version/s: 2.4.0 > Ranger Policy report for a given user should fetch policies maintained for > roles belonging to that user and groups > --- > > Key: RANGER-3912 > URL: https://issues.apache.org/jira/browse/RANGER-3912 > Project: Ranger > Issue Type: Bug > Components: Ranger >Affects Versions: 3.0.0, 2.4.0 >Reporter: Ramesh Mani >Assignee: Ramesh Mani >Priority: Major > Fix For: 3.0.0 > > > Ranger Policy report for a given user should fetch policies maintained for > roles belonging to that user and groups of the user. Current Policies that > are maintained for the roles are not considered and hence the report is not > accurate. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (RANGER-3912) Ranger Policy report for a given user should fetch policies maintained for roles belonging to that user and groups
[ https://issues.apache.org/jira/browse/RANGER-3912?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ramesh Mani updated RANGER-3912: Summary: Ranger Policy report for a given user should fetch policies maintained for roles belonging to that user and groups (was: Ranger Policy report for a give user should fetch policies maintained for roles belonging to that user ) > Ranger Policy report for a given user should fetch policies maintained for > roles belonging to that user and groups > --- > > Key: RANGER-3912 > URL: https://issues.apache.org/jira/browse/RANGER-3912 > Project: Ranger > Issue Type: Bug > Components: Ranger >Affects Versions: 3.0.0 >Reporter: Ramesh Mani >Assignee: Ramesh Mani >Priority: Major > Fix For: 3.0.0 > > > Ranger Policy report for a give user should fetch policies maintained for > roles belonging to that user. Current Policies that are maintained for the > roles are not considered and hence the report is not accurate. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (RANGER-3912) Ranger Policy report for a given user should fetch policies maintained for roles belonging to that user and groups
[ https://issues.apache.org/jira/browse/RANGER-3912?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ramesh Mani updated RANGER-3912: Description: Ranger Policy report for a given user should fetch policies maintained for roles belonging to that user and groups of the user. Current Policies that are maintained for the roles are not considered and hence the report is not accurate. (was: Ranger Policy report for a give user should fetch policies maintained for roles belonging to that user. Current Policies that are maintained for the roles are not considered and hence the report is not accurate.) > Ranger Policy report for a given user should fetch policies maintained for > roles belonging to that user and groups > --- > > Key: RANGER-3912 > URL: https://issues.apache.org/jira/browse/RANGER-3912 > Project: Ranger > Issue Type: Bug > Components: Ranger >Affects Versions: 3.0.0 >Reporter: Ramesh Mani >Assignee: Ramesh Mani >Priority: Major > Fix For: 3.0.0 > > > Ranger Policy report for a given user should fetch policies maintained for > roles belonging to that user and groups of the user. Current Policies that > are maintained for the roles are not considered and hence the report is not > accurate. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (RANGER-3918) Namespace policy that is created in Ranger by HBase Grant command not getting honored
[ https://issues.apache.org/jira/browse/RANGER-3918?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ramesh Mani updated RANGER-3918: Fix Version/s: 3.0.0 2.4.0 > Namespace policy that is created in Ranger by HBase Grant command not getting > honored > - > > Key: RANGER-3918 > URL: https://issues.apache.org/jira/browse/RANGER-3918 > Project: Ranger > Issue Type: Bug > Components: Ranger >Affects Versions: 3.0.0, 2.4.0 >Reporter: Ramesh Mani >Assignee: Ramesh Mani >Priority: Major > Fix For: 3.0.0, 2.4.0 > > > Namespace policy that is created in Ranger by HBase Grant command not getting > honored > When Grant command is executed on a Namespace for a User, the policy that is > getting created is not honored by HBase Ranger authorizer. > eg. grant 'user' , 'RWXCA', '@namespace' > create HBase Ranger policy for the table resource = "namespace:*" > Ranger HBaseCoprocessor doesn't honor this policy because of the matching > issue in the request resource. Resource that are getting created for this > request should have "namespace:" also as a Table resource. This has to be > done as "Namespace" is not a first call resource in HBase Ranger > Authorization definition. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Resolved] (RANGER-3918) Namespace policy that is created in Ranger by HBase Grant command not getting honored
[ https://issues.apache.org/jira/browse/RANGER-3918?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ramesh Mani resolved RANGER-3918. - Resolution: Fixed > Namespace policy that is created in Ranger by HBase Grant command not getting > honored > - > > Key: RANGER-3918 > URL: https://issues.apache.org/jira/browse/RANGER-3918 > Project: Ranger > Issue Type: Bug > Components: Ranger >Affects Versions: 3.0.0, 2.4.0 >Reporter: Ramesh Mani >Assignee: Ramesh Mani >Priority: Major > Fix For: 3.0.0, 2.4.0 > > > Namespace policy that is created in Ranger by HBase Grant command not getting > honored > When Grant command is executed on a Namespace for a User, the policy that is > getting created is not honored by HBase Ranger authorizer. > eg. grant 'user' , 'RWXCA', '@namespace' > create HBase Ranger policy for the table resource = "namespace:*" > Ranger HBaseCoprocessor doesn't honor this policy because of the matching > issue in the request resource. Resource that are getting created for this > request should have "namespace:" also as a Table resource. This has to be > done as "Namespace" is not a first call resource in HBase Ranger > Authorization definition. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (RANGER-3907) Skip auditing of operation like monitorHealth in HDFS Ranger Plugin audit handler
[ https://issues.apache.org/jira/browse/RANGER-3907?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ramesh Mani updated RANGER-3907: Affects Version/s: 2.4.0 > Skip auditing of operation like monitorHealth in HDFS Ranger Plugin audit > handler > -- > > Key: RANGER-3907 > URL: https://issues.apache.org/jira/browse/RANGER-3907 > Project: Ranger > Issue Type: Bug > Components: Ranger >Affects Versions: 3.0.0, 2.4.0 >Reporter: Ramesh Mani >Assignee: Ramesh Mani >Priority: Minor > Fix For: 3.0.0, 2.4.0 > > > Certain operations like "monitorHealth" in HA environment cannot be excluded > using the Ranger audit filter as these operations are not done on any > resource, doesn't get authorized also. Only auditing is done on those > operations. > These operations fills up the Ranger audits and hence needs to be excluded. > -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (RANGER-3907) Skip auditing of operation like monitorHealth in HDFS Ranger Plugin audit handler
[ https://issues.apache.org/jira/browse/RANGER-3907?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ramesh Mani updated RANGER-3907: Fix Version/s: 3.0.0 2.4.0 > Skip auditing of operation like monitorHealth in HDFS Ranger Plugin audit > handler > -- > > Key: RANGER-3907 > URL: https://issues.apache.org/jira/browse/RANGER-3907 > Project: Ranger > Issue Type: Bug > Components: Ranger >Affects Versions: 3.0.0 >Reporter: Ramesh Mani >Assignee: Ramesh Mani >Priority: Minor > Fix For: 3.0.0, 2.4.0 > > > Certain operations like "monitorHealth" in HA environment cannot be excluded > using the Ranger audit filter as these operations are not done on any > resource, doesn't get authorized also. Only auditing is done on those > operations. > These operations fills up the Ranger audits and hence needs to be excluded. > -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Resolved] (RANGER-3907) Skip auditing of operation like monitorHealth in HDFS Ranger Plugin audit handler
[ https://issues.apache.org/jira/browse/RANGER-3907?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ramesh Mani resolved RANGER-3907. - Resolution: Fixed > Skip auditing of operation like monitorHealth in HDFS Ranger Plugin audit > handler > -- > > Key: RANGER-3907 > URL: https://issues.apache.org/jira/browse/RANGER-3907 > Project: Ranger > Issue Type: Bug > Components: Ranger >Affects Versions: 3.0.0, 2.4.0 >Reporter: Ramesh Mani >Assignee: Ramesh Mani >Priority: Minor > Fix For: 3.0.0, 2.4.0 > > > Certain operations like "monitorHealth" in HA environment cannot be excluded > using the Ranger audit filter as these operations are not done on any > resource, doesn't get authorized also. Only auditing is done on those > operations. > These operations fills up the Ranger audits and hence needs to be excluded. > -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (RANGER-3907) Skip auditing of operation like monitorHealth in HDFS Ranger Plugin audit handler
[ https://issues.apache.org/jira/browse/RANGER-3907?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17610202#comment-17610202 ] Ramesh Mani commented on RANGER-3907: - This happens in HA environment and when NameNode is in HA. > Skip auditing of operation like monitorHealth in HDFS Ranger Plugin audit > handler > -- > > Key: RANGER-3907 > URL: https://issues.apache.org/jira/browse/RANGER-3907 > Project: Ranger > Issue Type: Bug > Components: Ranger >Affects Versions: 3.0.0 >Reporter: Ramesh Mani >Assignee: Ramesh Mani >Priority: Minor > > Certain operations like "monitorHealth" in HA environment cannot be excluded > using the Ranger audit filter as these operations are not done on any > resource, doesn't get authorized also. Only auditing is done on those > operations. > These operations fills up the Ranger audits and hence needs to be excluded. > -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (RANGER-3281) Ranger Authorization for StorageHandler based Hive table creation
[ https://issues.apache.org/jira/browse/RANGER-3281?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17608543#comment-17608543 ] Ramesh Mani commented on RANGER-3281: - This feature requires HIVE side change which has been completed in Hive 4.0.0 against https://issues.apache.org/jira/browse/HIVE-24705. [~thejas] [~ngangam] There has been quite a number of request about this feature in the community and would like to know when Apache Hive 4.0.0 will be released. > Ranger Authorization for StorageHandler based Hive table creation > - > > Key: RANGER-3281 > URL: https://issues.apache.org/jira/browse/RANGER-3281 > Project: Ranger > Issue Type: Bug > Components: Ranger >Affects Versions: 3.0.0 >Reporter: Ramesh Mani >Assignee: Ramesh Mani >Priority: Minor > > Ranger Authorization for StorageHandler based Hive table creation -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Assigned] (RANGER-3281) Ranger Authorization for StorageHandler based Hive table creation
[ https://issues.apache.org/jira/browse/RANGER-3281?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ramesh Mani reassigned RANGER-3281: --- Assignee: Ramesh Mani > Ranger Authorization for StorageHandler based Hive table creation > - > > Key: RANGER-3281 > URL: https://issues.apache.org/jira/browse/RANGER-3281 > Project: Ranger > Issue Type: Bug > Components: Ranger >Affects Versions: 3.0.0 >Reporter: Ramesh Mani >Assignee: Ramesh Mani >Priority: Minor > > Ranger Authorization for StorageHandler based Hive table creation -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Assigned] (RANGER-3918) Namespace policy that is created in Ranger by HBase Grant command not getting honored
[ https://issues.apache.org/jira/browse/RANGER-3918?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ramesh Mani reassigned RANGER-3918: --- Assignee: Ramesh Mani > Namespace policy that is created in Ranger by HBase Grant command not getting > honored > - > > Key: RANGER-3918 > URL: https://issues.apache.org/jira/browse/RANGER-3918 > Project: Ranger > Issue Type: Bug > Components: Ranger >Affects Versions: 3.0.0, 2.4.0 >Reporter: Ramesh Mani >Assignee: Ramesh Mani >Priority: Major > > Namespace policy that is created in Ranger by HBase Grant command not getting > honored > When Grant command is executed on a Namespace for a User, the policy that is > getting created is not honored by HBase Ranger authorizer. > eg. grant 'user' , 'RWXCA', '@namespace' > create HBase Ranger policy for the table resource = "namespace:*" > Ranger HBaseCoprocessor doesn't honor this policy because of the matching > issue in the request resource. Resource that are getting created for this > request should have "namespace:" also as a Table resource. This has to be > done as "Namespace" is not a first call resource in HBase Ranger > Authorization definition. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (RANGER-3918) Namespace policy that is created in Ranger by HBase Grant command not getting honored
[ https://issues.apache.org/jira/browse/RANGER-3918?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ramesh Mani updated RANGER-3918: Description: Namespace policy that is created in Ranger by HBase Grant command not getting honored When Grant command is executed on a Namespace for a User, the policy that is getting created is not honored by HBase Ranger authorizer. eg. grant 'user' , 'RWXCA', '@namespace' create HBase Ranger policy for the table resource = "namespace:*" Ranger HBaseCoprocessor doesn't honor this policy because of the matching issue in the request resource. Resource that are getting created for this request should have "namespace:" also as a Table resource. This has to be done as "Namespace" is not a first call resource in HBase Ranger Authorization definition. > Namespace policy that is created in Ranger by HBase Grant command not getting > honored > - > > Key: RANGER-3918 > URL: https://issues.apache.org/jira/browse/RANGER-3918 > Project: Ranger > Issue Type: Bug > Components: Ranger >Affects Versions: 3.0.0, 2.4.0 >Reporter: Ramesh Mani >Priority: Major > > Namespace policy that is created in Ranger by HBase Grant command not getting > honored > When Grant command is executed on a Namespace for a User, the policy that is > getting created is not honored by HBase Ranger authorizer. > eg. grant 'user' , 'RWXCA', '@namespace' > create HBase Ranger policy for the table resource = "namespace:*" > Ranger HBaseCoprocessor doesn't honor this policy because of the matching > issue in the request resource. Resource that are getting created for this > request should have "namespace:" also as a Table resource. This has to be > done as "Namespace" is not a first call resource in HBase Ranger > Authorization definition. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Created] (RANGER-3918) Namespace policy that is created in Ranger by HBase Grant command not getting honored
Ramesh Mani created RANGER-3918: --- Summary: Namespace policy that is created in Ranger by HBase Grant command not getting honored Key: RANGER-3918 URL: https://issues.apache.org/jira/browse/RANGER-3918 Project: Ranger Issue Type: Bug Components: Ranger Affects Versions: 3.0.0, 2.4.0 Reporter: Ramesh Mani -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Assigned] (RANGER-3912) Ranger Policy report for a give user should fetch policies maintained for roles belonging to that user
[ https://issues.apache.org/jira/browse/RANGER-3912?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ramesh Mani reassigned RANGER-3912: --- Assignee: Ramesh Mani > Ranger Policy report for a give user should fetch policies maintained for > roles belonging to that user > > > Key: RANGER-3912 > URL: https://issues.apache.org/jira/browse/RANGER-3912 > Project: Ranger > Issue Type: Bug > Components: Ranger >Affects Versions: 3.0.0 >Reporter: Ramesh Mani >Assignee: Ramesh Mani >Priority: Major > Fix For: 3.0.0 > > > Ranger Policy report for a give user should fetch policies maintained for > roles belonging to that user. Current Policies that are maintained for the > roles are not considered and hence the report is not accurate. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Created] (RANGER-3912) Ranger Policy report for a give user should fetch policies maintained for roles belonging to that user
Ramesh Mani created RANGER-3912: --- Summary: Ranger Policy report for a give user should fetch policies maintained for roles belonging to that user Key: RANGER-3912 URL: https://issues.apache.org/jira/browse/RANGER-3912 Project: Ranger Issue Type: Bug Components: Ranger Affects Versions: 3.0.0 Reporter: Ramesh Mani Fix For: 3.0.0 Ranger Policy report for a give user should fetch policies maintained for roles belonging to that user. Current Policies that are maintained for the roles are not considered and hence the report is not accurate. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Assigned] (RANGER-3907) Skip auditing of operation like monitorHealth in HDFS Ranger Plugin audit handler
[ https://issues.apache.org/jira/browse/RANGER-3907?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ramesh Mani reassigned RANGER-3907: --- Assignee: Ramesh Mani > Skip auditing of operation like monitorHealth in HDFS Ranger Plugin audit > handler > -- > > Key: RANGER-3907 > URL: https://issues.apache.org/jira/browse/RANGER-3907 > Project: Ranger > Issue Type: Bug > Components: Ranger >Affects Versions: 3.0.0 >Reporter: Ramesh Mani >Assignee: Ramesh Mani >Priority: Minor > > Certain operations like "monitorHealth" in HA environment cannot be excluded > using the Ranger audit filter as these operations are not done on any > resource, doesn't get authorized also. Only auditing is done on those > operations. > These operations fills up the Ranger audits and hence needs to be excluded. > -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Created] (RANGER-3907) Skip auditing of operation like monitorHealth in HDFS Ranger Plugin audit handler
Ramesh Mani created RANGER-3907: --- Summary: Skip auditing of operation like monitorHealth in HDFS Ranger Plugin audit handler Key: RANGER-3907 URL: https://issues.apache.org/jira/browse/RANGER-3907 Project: Ranger Issue Type: Bug Components: Ranger Affects Versions: 3.0.0 Reporter: Ramesh Mani Certain operations like "monitorHealth" in HA environment cannot be excluded using the Ranger audit filter as these operations are not done on any resource, doesn't get authorized also. Only auditing is done on those operations. These operations fills up the Ranger audits and hence needs to be excluded. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Created] (RANGER-3905) Ranger metrics on audit throughput for each of the Ranger Service plugins
Ramesh Mani created RANGER-3905: --- Summary: Ranger metrics on audit throughput for each of the Ranger Service plugins Key: RANGER-3905 URL: https://issues.apache.org/jira/browse/RANGER-3905 Project: Ranger Issue Type: Bug Components: Ranger Affects Versions: 3.0.0 Reporter: Ramesh Mani Ranger metrics on audit throughput for each of the Ranger Service plugins * To record ranger audit rate for each of the Ranger plugin * To derive metrics and create charts which can be used for alert and notification -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Assigned] (RANGER-3905) Ranger metrics on audit throughput for each of the Ranger Service plugins
[ https://issues.apache.org/jira/browse/RANGER-3905?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ramesh Mani reassigned RANGER-3905: --- Assignee: Ramesh Mani > Ranger metrics on audit throughput for each of the Ranger Service plugins > - > > Key: RANGER-3905 > URL: https://issues.apache.org/jira/browse/RANGER-3905 > Project: Ranger > Issue Type: Bug > Components: Ranger >Affects Versions: 3.0.0 >Reporter: Ramesh Mani >Assignee: Ramesh Mani >Priority: Major > > Ranger metrics on audit throughput for each of the Ranger Service plugins > * To record ranger audit rate for each of the Ranger plugin > * To derive metrics and create charts which can be used for alert and > notification -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (RANGER-3848) RangerClient does not auto renew Kerberos ticket after ticket lifetime expired
[
https://issues.apache.org/jira/browse/RANGER-3848?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17578121#comment-17578121
]
Ramesh Mani commented on RANGER-3848:
-
[~abhi_2110] Patch committed to 2.4 and master branch. Thanks.
> RangerClient does not auto renew Kerberos ticket after ticket lifetime expired
> --
>
> Key: RANGER-3848
> URL: https://issues.apache.org/jira/browse/RANGER-3848
> Project: Ranger
> Issue Type: Bug
> Components: Ranger
>Affects Versions: 2.3.0
>Reporter: Abhishek Kumar
>Assignee: Abhishek Kumar
>Priority: Major
>
> RangerClient does not seem to auto renew Kerberos ticket after ticket
> lifetime expired.
> This prevents applications using RangerClient from making any requests after
> the ticket lifetime (as RangerClient is instantiated once and only once upon
> application startup using Kerberos principal and keytab).
> Evidence from a test cluster:
> First Unauthorized 401 started to appear after 24 hrs (the same as
> ticket_lifetime defined in krb5.conf).
> Verified that /etc/krb5.conf ticket_lifetime is 1 day:
> {code:java}
> [systest@random-3 ~]$ cat /etc/krb5.conf
> [logging]
> default = FILE:/var/log/krb5libs.log
> kdc = FILE:/var/log/krb5kdc.log
> admin_server = FILE:/var/log/kadmind.log
> [libdefaults]
> renew_lifetime = 8d
> default_realm = SOURCE7172.SITE
> dns_lookup_realm = false
> dns_lookup_kdc = false
> ticket_lifetime = 1d
> forwardable = yes
> ...{code}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Comment Edited] (RANGER-3790) Ranger tagsync module should not depend on kafka server
[ https://issues.apache.org/jira/browse/RANGER-3790?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17571767#comment-17571767 ] Ramesh Mani edited comment on RANGER-3790 at 7/27/22 7:22 AM: -- [~pmarton] This has been committed to master branch and 2.4 branch. Thanks for the contribution. was (Author: rmani): [~pmarton] This has been committed to master branch. Thanks for the contribution. > Ranger tagsync module should not depend on kafka server > --- > > Key: RANGER-3790 > URL: https://issues.apache.org/jira/browse/RANGER-3790 > Project: Ranger > Issue Type: Bug > Components: tagsync >Affects Versions: 3.0.0 >Reporter: Patrik Márton >Assignee: Patrik Márton >Priority: Major > Fix For: 3.0.0, 2.4.0 > > Attachments: RANGER-3790.patch > > Time Spent: 10m > Remaining Estimate: 0h > > This is a follow-up of RANGER-2426. > Kafka Core dependency has already been removed from tagsync as part of the > mentioned ticket, but since the _distro/src/main/assembly/tagsync.xml_ > contains this dependency, it is included in the distribution. > [https://github.com/apache/ranger/blob/master/distro/src/main/assembly/tagsync.xml#L56] > > The goal is to remove this from the assembly. > -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (RANGER-3790) Ranger tagsync module should not depend on kafka server
[ https://issues.apache.org/jira/browse/RANGER-3790?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ramesh Mani updated RANGER-3790: Fix Version/s: 2.4.0 > Ranger tagsync module should not depend on kafka server > --- > > Key: RANGER-3790 > URL: https://issues.apache.org/jira/browse/RANGER-3790 > Project: Ranger > Issue Type: Bug > Components: tagsync >Affects Versions: 3.0.0 >Reporter: Patrik Márton >Assignee: Patrik Márton >Priority: Major > Fix For: 3.0.0, 2.4.0 > > Attachments: RANGER-3790.patch > > Time Spent: 10m > Remaining Estimate: 0h > > This is a follow-up of RANGER-2426. > Kafka Core dependency has already been removed from tagsync as part of the > mentioned ticket, but since the _distro/src/main/assembly/tagsync.xml_ > contains this dependency, it is included in the distribution. > [https://github.com/apache/ranger/blob/master/distro/src/main/assembly/tagsync.xml#L56] > > The goal is to remove this from the assembly. > -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (RANGER-3790) Ranger tagsync module should not depend on kafka server
[ https://issues.apache.org/jira/browse/RANGER-3790?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ramesh Mani updated RANGER-3790: Fix Version/s: 3.0.0 > Ranger tagsync module should not depend on kafka server > --- > > Key: RANGER-3790 > URL: https://issues.apache.org/jira/browse/RANGER-3790 > Project: Ranger > Issue Type: Bug > Components: tagsync >Affects Versions: 3.0.0 >Reporter: Patrik Márton >Assignee: Patrik Márton >Priority: Major > Fix For: 3.0.0 > > Attachments: RANGER-3790.patch > > Time Spent: 10m > Remaining Estimate: 0h > > This is a follow-up of RANGER-2426. > Kafka Core dependency has already been removed from tagsync as part of the > mentioned ticket, but since the _distro/src/main/assembly/tagsync.xml_ > contains this dependency, it is included in the distribution. > [https://github.com/apache/ranger/blob/master/distro/src/main/assembly/tagsync.xml#L56] > > The goal is to remove this from the assembly. > -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (RANGER-3790) Ranger tagsync module should not depend on kafka server
[ https://issues.apache.org/jira/browse/RANGER-3790?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17571767#comment-17571767 ] Ramesh Mani commented on RANGER-3790: - [~pmarton] This has been committed to master branch. Thanks for the contribution. > Ranger tagsync module should not depend on kafka server > --- > > Key: RANGER-3790 > URL: https://issues.apache.org/jira/browse/RANGER-3790 > Project: Ranger > Issue Type: Bug > Components: tagsync >Affects Versions: 3.0.0 >Reporter: Patrik Márton >Assignee: Patrik Márton >Priority: Major > Attachments: RANGER-3790.patch > > Time Spent: 10m > Remaining Estimate: 0h > > This is a follow-up of RANGER-2426. > Kafka Core dependency has already been removed from tagsync as part of the > mentioned ticket, but since the _distro/src/main/assembly/tagsync.xml_ > contains this dependency, it is included in the distribution. > [https://github.com/apache/ranger/blob/master/distro/src/main/assembly/tagsync.xml#L56] > > The goal is to remove this from the assembly. > -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (RANGER-3809) Implement authorizeByResourceType method of Kafka Authorizer
[
https://issues.apache.org/jira/browse/RANGER-3809?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17570248#comment-17570248
]
Ramesh Mani commented on RANGER-3809:
-
[~akatona] Shim patch is committed now. Please close the review request. Thanks
> Implement authorizeByResourceType method of Kafka Authorizer
>
>
> Key: RANGER-3809
> URL: https://issues.apache.org/jira/browse/RANGER-3809
> Project: Ranger
> Issue Type: Improvement
> Components: plugins
>Affects Versions: 3.0.0
>Reporter: Andras Katona
>Assignee: Ramesh Mani
>Priority: Major
> Time Spent: 20m
> Remaining Estimate: 0h
>
> In Kafka 2.8 this new authorization method was introduced mainly to ease
> authorization (setup) of idempotent producers.
> The default implementation of {{authorizeByResourceType}} uses
> [acls()|https://github.com/apache/kafka/blob/a3c7017ff7e543b50f84110195690a253f19d9cf/clients/src/main/java/org/apache/kafka/server/authorizer/Authorizer.java#L154]
> which is [not
> implemented|https://github.com/apache/ranger/blob/fc7ad98fbb2ee7bb7d4cd3329abc438a73e0444a/plugin-kafka/src/main/java/org/apache/ranger/authorization/kafka/authorizer/RangerKafkaAuthorizer.java#L332-L335]
> in Kafka Ranger Plugin, but it is not really efficient and it is recommended
> to implement/override it in custom authorizer implementation (meaning Ranger
> in our case).
> {code}
> /**
> * Check if the caller is authorized to perform the given ACL operation
> on at least one
> * resource of the given type.
> *
> * Custom authorizer implementations should consider overriding this
> default implementation because:
> * 1. The default implementation iterates all AclBindings multiple times,
> without any caching
> *by principal, host, operation, permission types, and resource
> types. More efficient
> *implementations may be added in custom authorizers that directly
> access cached entries.
> * 2. The default implementation cannot integrate with any audit logging
> included in the
> *authorizer implementation.
> * 3. The default implementation does not support any custom authorizer
> configs or other access
> *rules apart from ACLs.
> *
> * @param requestContext Request context including request resourceType,
> security protocol and listener name
> * @param op The ACL operation to check
> * @param resourceType The resource type to check
> * @return Return {@link AuthorizationResult#ALLOWED} if
> the caller is authorized
> * to perform the given ACL operation on at least
> one resource of the
> * given type. Return {@link
> AuthorizationResult#DENIED} otherwise.
> */
> default AuthorizationResult
> authorizeByResourceType(AuthorizableRequestContext requestContext,
> AclOperation op, ResourceType resourceType) {
> {code}
> In Kafka 3.0.1, 3.1.1 and 3.2.0, producers are idempotent by default
> (KAFKA-13598) and the authorization of producer initialization fails, in case
> the user doesn't have the deprecated idempotent_write access, as it will call
> the {{authorizeByResourceType}} and that calls {{acls}}.
> {code}
> public Iterable acls(AclBindingFilter filter) {
> logger.error("(getting) acls is not supported by Ranger for Kafka");
> throw new UnsupportedOperationException("(getting) acls is not supported
> by Ranger for Kafka");
> }
> {code}
> With [this
> commit|https://github.com/apache/ranger/commit/0ec279474e0439f6c5e7d4497db191fb7cc99bc1]
> {{authorizeByResourceType}} got an implementation with a basic validation
> check and a (constant) denial response. It's just making
> UnsupportedOperationException disappear and having an expected response for
> initProducer authorization.
> Until the proper implementation is done, the idempotent_write access should
> be granted for the producer.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (RANGER-3831) Add support of pegasus to ranger
[ https://issues.apache.org/jira/browse/RANGER-3831?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17567086#comment-17567086 ] Ramesh Mani commented on RANGER-3831: - [~kirbyzhou] Nice to see this initiative! Are you planning to work on it or expecting Apache Ranger community to contribute to this? > Add support of pegasus to ranger > > > Key: RANGER-3831 > URL: https://issues.apache.org/jira/browse/RANGER-3831 > Project: Ranger > Issue Type: Improvement > Components: admin, plugins >Affects Versions: 3.0.0 >Reporter: kirby zhou >Priority: Major > > Apache Pegasus is A horizontally scalable, strongly consistent and > high-performance key-value store. > It now have ACLs and SASL, but do not related to ranger. > I suggest to add support to it. > -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (RANGER-3830) Estimated date for Apache Ranger 2.3.0 and 3.0.0 release
[ https://issues.apache.org/jira/browse/RANGER-3830?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17566671#comment-17566671 ] Ramesh Mani commented on RANGER-3830: - [~puram.vaibhav] Apache Ranger 2.3.0 is already released. Please review the Release Notes for features and improvements [https://ranger.apache.org/] > Estimated date for Apache Ranger 2.3.0 and 3.0.0 release > > > Key: RANGER-3830 > URL: https://issues.apache.org/jira/browse/RANGER-3830 > Project: Ranger > Issue Type: Wish > Components: documentation >Reporter: Phani Vaibhav Puram >Priority: Major > > Hi All, > > We have a project that uses apache Ranger 2.2.0 and we would now want to > upgrade it to the latest version available before we move to production. Is > there any estimated date for Apache Ranger 2.3.0 and 3.0.0 so that we can > plan our project accordingly? Also any feature list for the above releases > would be helpful. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Resolved] (RANGER-3809) Implement authorizeByResourceType method of Kafka Authorizer
[
https://issues.apache.org/jira/browse/RANGER-3809?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Ramesh Mani resolved RANGER-3809.
-
Resolution: Fixed
> Implement authorizeByResourceType method of Kafka Authorizer
>
>
> Key: RANGER-3809
> URL: https://issues.apache.org/jira/browse/RANGER-3809
> Project: Ranger
> Issue Type: Improvement
> Components: plugins
>Affects Versions: 3.0.0
>Reporter: Andras Katona
>Assignee: Ramesh Mani
>Priority: Major
> Fix For: 3.0.0
>
> Time Spent: 20m
> Remaining Estimate: 0h
>
> In Kafka 2.8 this new authorization method was introduced mainly to ease
> authorization (setup) of idempotent producers.
> The default implementation uses
> [acls()|https://github.com/apache/kafka/blob/a3c7017ff7e543b50f84110195690a253f19d9cf/clients/src/main/java/org/apache/kafka/server/authorizer/Authorizer.java#L154]
> which is [not
> implemented|https://github.com/apache/ranger/blob/fc7ad98fbb2ee7bb7d4cd3329abc438a73e0444a/plugin-kafka/src/main/java/org/apache/ranger/authorization/kafka/authorizer/RangerKafkaAuthorizer.java#L332-L335]
> in Kafka Ranger Plugin
> {code}
> /**
> * Returns ACL bindings which match the provided filter.
> *
> * This is a synchronous API designed for use with locally cached ACLs.
> This method is invoked on the request
> * thread while processing DescribeAcls requests and should avoid
> time-consuming remote communication that may
> * block request threads.
> *
> * @return Iterator for ACL bindings, which may be populated lazily.
> */
> Iterable acls(AclBindingFilter filter);
> {code}
> {code}
> /**
> * Check if the caller is authorized to perform the given ACL operation
> on at least one
> * resource of the given type.
> *
> * Custom authorizer implementations should consider overriding this
> default implementation because:
> * 1. The default implementation iterates all AclBindings multiple times,
> without any caching
> *by principal, host, operation, permission types, and resource
> types. More efficient
> *implementations may be added in custom authorizers that directly
> access cached entries.
> * 2. The default implementation cannot integrate with any audit logging
> included in the
> *authorizer implementation.
> * 3. The default implementation does not support any custom authorizer
> configs or other access
> *rules apart from ACLs.
> *
> * @param requestContext Request context including request resourceType,
> security protocol and listener name
> * @param op The ACL operation to check
> * @param resourceType The resource type to check
> * @return Return {@link AuthorizationResult#ALLOWED} if
> the caller is authorized
> * to perform the given ACL operation on at least
> one resource of the
> * given type. Return {@link
> AuthorizationResult#DENIED} otherwise.
> */
> default AuthorizationResult
> authorizeByResourceType(AuthorizableRequestContext requestContext,
> AclOperation op, ResourceType resourceType) {
> {code}
> In Kafka 3.0.1, 3.1.1 and 3.2.0, producers are idempotent by default
> (KAFKA-13598) and the authorization of producer initialization fails, in case
> the user doesn't have the deprecated idempotent_write access, as it will call
> the {{authorizeByResourceType}} and that calls {{acls}}.
> {code}
> public Iterable acls(AclBindingFilter filter) {
> logger.error("(getting) acls is not supported by Ranger for Kafka");
> throw new UnsupportedOperationException("(getting) acls is not supported
> by Ranger for Kafka");
> }
> {code}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (RANGER-3809) Implement authorizeByResourceType method of Kafka Authorizer
[
https://issues.apache.org/jira/browse/RANGER-3809?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Ramesh Mani updated RANGER-3809:
Affects Version/s: 3.0.0
> Implement authorizeByResourceType method of Kafka Authorizer
>
>
> Key: RANGER-3809
> URL: https://issues.apache.org/jira/browse/RANGER-3809
> Project: Ranger
> Issue Type: Improvement
> Components: plugins
>Affects Versions: 3.0.0
>Reporter: Andras Katona
>Assignee: Ramesh Mani
>Priority: Major
> Fix For: 3.0.0
>
> Time Spent: 20m
> Remaining Estimate: 0h
>
> In Kafka 2.8 this new authorization method was introduced mainly to ease
> authorization (setup) of idempotent producers.
> The default implementation uses
> [acls()|https://github.com/apache/kafka/blob/a3c7017ff7e543b50f84110195690a253f19d9cf/clients/src/main/java/org/apache/kafka/server/authorizer/Authorizer.java#L154]
> which is [not
> implemented|https://github.com/apache/ranger/blob/fc7ad98fbb2ee7bb7d4cd3329abc438a73e0444a/plugin-kafka/src/main/java/org/apache/ranger/authorization/kafka/authorizer/RangerKafkaAuthorizer.java#L332-L335]
> in Kafka Ranger Plugin
> {code}
> /**
> * Returns ACL bindings which match the provided filter.
> *
> * This is a synchronous API designed for use with locally cached ACLs.
> This method is invoked on the request
> * thread while processing DescribeAcls requests and should avoid
> time-consuming remote communication that may
> * block request threads.
> *
> * @return Iterator for ACL bindings, which may be populated lazily.
> */
> Iterable acls(AclBindingFilter filter);
> {code}
> {code}
> /**
> * Check if the caller is authorized to perform the given ACL operation
> on at least one
> * resource of the given type.
> *
> * Custom authorizer implementations should consider overriding this
> default implementation because:
> * 1. The default implementation iterates all AclBindings multiple times,
> without any caching
> *by principal, host, operation, permission types, and resource
> types. More efficient
> *implementations may be added in custom authorizers that directly
> access cached entries.
> * 2. The default implementation cannot integrate with any audit logging
> included in the
> *authorizer implementation.
> * 3. The default implementation does not support any custom authorizer
> configs or other access
> *rules apart from ACLs.
> *
> * @param requestContext Request context including request resourceType,
> security protocol and listener name
> * @param op The ACL operation to check
> * @param resourceType The resource type to check
> * @return Return {@link AuthorizationResult#ALLOWED} if
> the caller is authorized
> * to perform the given ACL operation on at least
> one resource of the
> * given type. Return {@link
> AuthorizationResult#DENIED} otherwise.
> */
> default AuthorizationResult
> authorizeByResourceType(AuthorizableRequestContext requestContext,
> AclOperation op, ResourceType resourceType) {
> {code}
> In Kafka 3.0.1, 3.1.1 and 3.2.0, producers are idempotent by default
> (KAFKA-13598) and the authorization of producer initialization fails, in case
> the user doesn't have the deprecated idempotent_write access, as it will call
> the {{authorizeByResourceType}} and that calls {{acls}}.
> {code}
> public Iterable acls(AclBindingFilter filter) {
> logger.error("(getting) acls is not supported by Ranger for Kafka");
> throw new UnsupportedOperationException("(getting) acls is not supported
> by Ranger for Kafka");
> }
> {code}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (RANGER-3809) Implement authorizeByResourceType method of Kafka Authorizer
[
https://issues.apache.org/jira/browse/RANGER-3809?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Ramesh Mani updated RANGER-3809:
Fix Version/s: 3.0.0
> Implement authorizeByResourceType method of Kafka Authorizer
>
>
> Key: RANGER-3809
> URL: https://issues.apache.org/jira/browse/RANGER-3809
> Project: Ranger
> Issue Type: Improvement
> Components: plugins
>Reporter: Andras Katona
>Assignee: Ramesh Mani
>Priority: Major
> Fix For: 3.0.0
>
> Time Spent: 20m
> Remaining Estimate: 0h
>
> In Kafka 2.8 this new authorization method was introduced mainly to ease
> authorization (setup) of idempotent producers.
> The default implementation uses
> [acls()|https://github.com/apache/kafka/blob/a3c7017ff7e543b50f84110195690a253f19d9cf/clients/src/main/java/org/apache/kafka/server/authorizer/Authorizer.java#L154]
> which is [not
> implemented|https://github.com/apache/ranger/blob/fc7ad98fbb2ee7bb7d4cd3329abc438a73e0444a/plugin-kafka/src/main/java/org/apache/ranger/authorization/kafka/authorizer/RangerKafkaAuthorizer.java#L332-L335]
> in Kafka Ranger Plugin
> {code}
> /**
> * Returns ACL bindings which match the provided filter.
> *
> * This is a synchronous API designed for use with locally cached ACLs.
> This method is invoked on the request
> * thread while processing DescribeAcls requests and should avoid
> time-consuming remote communication that may
> * block request threads.
> *
> * @return Iterator for ACL bindings, which may be populated lazily.
> */
> Iterable acls(AclBindingFilter filter);
> {code}
> {code}
> /**
> * Check if the caller is authorized to perform the given ACL operation
> on at least one
> * resource of the given type.
> *
> * Custom authorizer implementations should consider overriding this
> default implementation because:
> * 1. The default implementation iterates all AclBindings multiple times,
> without any caching
> *by principal, host, operation, permission types, and resource
> types. More efficient
> *implementations may be added in custom authorizers that directly
> access cached entries.
> * 2. The default implementation cannot integrate with any audit logging
> included in the
> *authorizer implementation.
> * 3. The default implementation does not support any custom authorizer
> configs or other access
> *rules apart from ACLs.
> *
> * @param requestContext Request context including request resourceType,
> security protocol and listener name
> * @param op The ACL operation to check
> * @param resourceType The resource type to check
> * @return Return {@link AuthorizationResult#ALLOWED} if
> the caller is authorized
> * to perform the given ACL operation on at least
> one resource of the
> * given type. Return {@link
> AuthorizationResult#DENIED} otherwise.
> */
> default AuthorizationResult
> authorizeByResourceType(AuthorizableRequestContext requestContext,
> AclOperation op, ResourceType resourceType) {
> {code}
> In Kafka 3.0.1, 3.1.1 and 3.2.0, producers are idempotent by default
> (KAFKA-13598) and the authorization of producer initialization fails, in case
> the user doesn't have the deprecated idempotent_write access, as it will call
> the {{authorizeByResourceType}} and that calls {{acls}}.
> {code}
> public Iterable acls(AclBindingFilter filter) {
> logger.error("(getting) acls is not supported by Ranger for Kafka");
> throw new UnsupportedOperationException("(getting) acls is not supported
> by Ranger for Kafka");
> }
> {code}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (RANGER-3809) Implement authorizeByResourceType method of Kafka Authorizer
[
https://issues.apache.org/jira/browse/RANGER-3809?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17566421#comment-17566421
]
Ramesh Mani commented on RANGER-3809:
-
[~akatona] Thanks for the contribution. Patch has been committed to Apache
master. Please close the the PR.
[https://gitbox.apache.org/repos/asf?p=ranger.git;a=commit;h=0ec279474e0439f6c5e7d4497db191fb7cc99bc1]
> Implement authorizeByResourceType method of Kafka Authorizer
>
>
> Key: RANGER-3809
> URL: https://issues.apache.org/jira/browse/RANGER-3809
> Project: Ranger
> Issue Type: Improvement
> Components: plugins
>Affects Versions: 3.0.0
>Reporter: Andras Katona
>Assignee: Ramesh Mani
>Priority: Major
> Fix For: 3.0.0
>
> Time Spent: 20m
> Remaining Estimate: 0h
>
> In Kafka 2.8 this new authorization method was introduced mainly to ease
> authorization (setup) of idempotent producers.
> The default implementation uses
> [acls()|https://github.com/apache/kafka/blob/a3c7017ff7e543b50f84110195690a253f19d9cf/clients/src/main/java/org/apache/kafka/server/authorizer/Authorizer.java#L154]
> which is [not
> implemented|https://github.com/apache/ranger/blob/fc7ad98fbb2ee7bb7d4cd3329abc438a73e0444a/plugin-kafka/src/main/java/org/apache/ranger/authorization/kafka/authorizer/RangerKafkaAuthorizer.java#L332-L335]
> in Kafka Ranger Plugin
> {code}
> /**
> * Returns ACL bindings which match the provided filter.
> *
> * This is a synchronous API designed for use with locally cached ACLs.
> This method is invoked on the request
> * thread while processing DescribeAcls requests and should avoid
> time-consuming remote communication that may
> * block request threads.
> *
> * @return Iterator for ACL bindings, which may be populated lazily.
> */
> Iterable acls(AclBindingFilter filter);
> {code}
> {code}
> /**
> * Check if the caller is authorized to perform the given ACL operation
> on at least one
> * resource of the given type.
> *
> * Custom authorizer implementations should consider overriding this
> default implementation because:
> * 1. The default implementation iterates all AclBindings multiple times,
> without any caching
> *by principal, host, operation, permission types, and resource
> types. More efficient
> *implementations may be added in custom authorizers that directly
> access cached entries.
> * 2. The default implementation cannot integrate with any audit logging
> included in the
> *authorizer implementation.
> * 3. The default implementation does not support any custom authorizer
> configs or other access
> *rules apart from ACLs.
> *
> * @param requestContext Request context including request resourceType,
> security protocol and listener name
> * @param op The ACL operation to check
> * @param resourceType The resource type to check
> * @return Return {@link AuthorizationResult#ALLOWED} if
> the caller is authorized
> * to perform the given ACL operation on at least
> one resource of the
> * given type. Return {@link
> AuthorizationResult#DENIED} otherwise.
> */
> default AuthorizationResult
> authorizeByResourceType(AuthorizableRequestContext requestContext,
> AclOperation op, ResourceType resourceType) {
> {code}
> In Kafka 3.0.1, 3.1.1 and 3.2.0, producers are idempotent by default
> (KAFKA-13598) and the authorization of producer initialization fails, in case
> the user doesn't have the deprecated idempotent_write access, as it will call
> the {{authorizeByResourceType}} and that calls {{acls}}.
> {code}
> public Iterable acls(AclBindingFilter filter) {
> logger.error("(getting) acls is not supported by Ranger for Kafka");
> throw new UnsupportedOperationException("(getting) acls is not supported
> by Ranger for Kafka");
> }
> {code}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Resolved] (RANGER-3712) Update Apache Ranger website for 2.3.0 release
[ https://issues.apache.org/jira/browse/RANGER-3712?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ramesh Mani resolved RANGER-3712. - Resolution: Fixed > Update Apache Ranger website for 2.3.0 release > --- > > Key: RANGER-3712 > URL: https://issues.apache.org/jira/browse/RANGER-3712 > Project: Ranger > Issue Type: Sub-task > Components: Ranger >Affects Versions: 3.0.0 >Reporter: Ramesh Mani >Assignee: Ramesh Mani >Priority: Major > Fix For: 3.0.0 > > Attachments: > 0001-RANGER-3712-Update-Apache-Ranger-website-for-2.3.0-r.patch > > > Update Apache Ranger website for 2.3.0 release -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (RANGER-3712) Update Apache Ranger website for 2.3.0 release
[ https://issues.apache.org/jira/browse/RANGER-3712?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17564519#comment-17564519 ] Ramesh Mani commented on RANGER-3712: - This is to update the Apache Ranger Website with release 2.3.0 release information. Activities done : 1) Updated release folder cwiki https://cwiki.apache.org/confluence/display/RANGER/Apache+Ranger+Releases 2) Updated Ranger API Docs in https://ranger.apache.org/apidocs/index.html 3) This patch to update the Release information in Apache Ranger Home page https://ranger.apache.org/ > Update Apache Ranger website for 2.3.0 release > --- > > Key: RANGER-3712 > URL: https://issues.apache.org/jira/browse/RANGER-3712 > Project: Ranger > Issue Type: Sub-task > Components: Ranger >Affects Versions: 3.0.0 >Reporter: Ramesh Mani >Assignee: Ramesh Mani >Priority: Major > Fix For: 3.0.0 > > Attachments: > 0001-RANGER-3712-Update-Apache-Ranger-website-for-2.3.0-r.patch > > > Update Apache Ranger website for 2.3.0 release -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (RANGER-3712) Update Apache Ranger website for 2.3.0 release
[ https://issues.apache.org/jira/browse/RANGER-3712?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ramesh Mani updated RANGER-3712: Attachment: 0001-RANGER-3712-Update-Apache-Ranger-website-for-2.3.0-r.patch > Update Apache Ranger website for 2.3.0 release > --- > > Key: RANGER-3712 > URL: https://issues.apache.org/jira/browse/RANGER-3712 > Project: Ranger > Issue Type: Sub-task > Components: Ranger >Affects Versions: 3.0.0 >Reporter: Ramesh Mani >Assignee: Ramesh Mani >Priority: Major > Fix For: 3.0.0 > > Attachments: > 0001-RANGER-3712-Update-Apache-Ranger-website-for-2.3.0-r.patch > > > Update Apache Ranger website for 2.3.0 release -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (RANGER-3712) Update Apache Ranger website for 2.3.0 release
[ https://issues.apache.org/jira/browse/RANGER-3712?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ramesh Mani updated RANGER-3712: Affects Version/s: 3.0.0 (was: 2.3.0) > Update Apache Ranger website for 2.3.0 release > --- > > Key: RANGER-3712 > URL: https://issues.apache.org/jira/browse/RANGER-3712 > Project: Ranger > Issue Type: Sub-task > Components: Ranger >Affects Versions: 3.0.0 >Reporter: Ramesh Mani >Assignee: Ramesh Mani >Priority: Major > Fix For: 3.0.0 > > > Update Apache Ranger website for 2.3.0 release -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (RANGER-3712) Update Apache Ranger website for 2.3.0 release
[ https://issues.apache.org/jira/browse/RANGER-3712?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ramesh Mani updated RANGER-3712: Fix Version/s: 3.0.0 (was: 2.3.0) > Update Apache Ranger website for 2.3.0 release > --- > > Key: RANGER-3712 > URL: https://issues.apache.org/jira/browse/RANGER-3712 > Project: Ranger > Issue Type: Sub-task > Components: Ranger >Affects Versions: 2.3.0 >Reporter: Ramesh Mani >Assignee: Ramesh Mani >Priority: Major > Fix For: 3.0.0 > > > Update Apache Ranger website for 2.3.0 release -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Assigned] (RANGER-3712) Update Apache Ranger website for 2.3.0 release
[ https://issues.apache.org/jira/browse/RANGER-3712?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ramesh Mani reassigned RANGER-3712: --- Assignee: Ramesh Mani > Update Apache Ranger website for 2.3.0 release > --- > > Key: RANGER-3712 > URL: https://issues.apache.org/jira/browse/RANGER-3712 > Project: Ranger > Issue Type: Sub-task > Components: Ranger >Affects Versions: 2.3.0 >Reporter: Ramesh Mani >Assignee: Ramesh Mani >Priority: Major > Fix For: 2.3.0 > > > Update Apache Ranger website for 2.3.0 release -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (RANGER-3730) log4j dependency is not completely removed
[ https://issues.apache.org/jira/browse/RANGER-3730?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17564390#comment-17564390 ] Ramesh Mani commented on RANGER-3730: - Thank you [~sneethiraj] > log4j dependency is not completely removed > -- > > Key: RANGER-3730 > URL: https://issues.apache.org/jira/browse/RANGER-3730 > Project: Ranger > Issue Type: Bug > Components: Ranger >Affects Versions: 3.0.0, 2.3.0 >Reporter: Bhavik Patel >Assignee: kirby zhou >Priority: Major > Fix For: 3.0.0, 2.3.0 > > Attachments: 0001-RANGER-3730-use-reload4j-to-replace-log4j.patch > > > log4j dependency is present in parent pom file - > [https://github.com/apache/ranger/blob/master/pom.xml#L166] > > [~madhan] [~ma3mansoori123] -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Comment Edited] (RANGER-3713) Publish release artifacts
[ https://issues.apache.org/jira/browse/RANGER-3713?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17564029#comment-17564029 ] Ramesh Mani edited comment on RANGER-3713 at 7/8/22 12:24 AM: -- Maven Central Repo for Apache Ranger 2.3.0 [https://mvnrepository.com/artifact/org.apache.ranger] Artifacts are present in * h2. [2.3.0 release artifacts|https://dist.apache.org/repos/dist/release/ranger/2.3.0/] * h2. Release Tag: [release-ranger-2.3.0|https://github.com/apache/ranger/tree/release-ranger-2.3.0] was (Author: rmani): Maven Central Repo for Apache Ranger 2.3.0 [https://mvnrepository.com/artifact/org.apache.ranger] > Publish release artifacts > - > > Key: RANGER-3713 > URL: https://issues.apache.org/jira/browse/RANGER-3713 > Project: Ranger > Issue Type: Sub-task > Components: Ranger >Affects Versions: 2.3.0 >Reporter: Ramesh Mani >Priority: Major > Fix For: 2.3.0 > > > Publish release artifacts -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Resolved] (RANGER-3713) Publish release artifacts
[ https://issues.apache.org/jira/browse/RANGER-3713?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ramesh Mani resolved RANGER-3713. - Resolution: Fixed Maven Central Repo for Apache Ranger 2.3.0 [https://mvnrepository.com/artifact/org.apache.ranger] > Publish release artifacts > - > > Key: RANGER-3713 > URL: https://issues.apache.org/jira/browse/RANGER-3713 > Project: Ranger > Issue Type: Sub-task > Components: Ranger >Affects Versions: 2.3.0 >Reporter: Ramesh Mani >Priority: Major > Fix For: 2.3.0 > > > Publish release artifacts -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Resolved] (RANGER-768) Hive Metastore Plugin
[ https://issues.apache.org/jira/browse/RANGER-768?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ramesh Mani resolved RANGER-768. Fix Version/s: 2.1.0 Assignee: Ramesh Mani Resolution: Fixed This was implemented in https://issues.apache.org/jira/browse/HIVE-21753 > Hive Metastore Plugin > - > > Key: RANGER-768 > URL: https://issues.apache.org/jira/browse/RANGER-768 > Project: Ranger > Issue Type: New Feature > Components: admin, plugins >Reporter: Yan >Assignee: Ramesh Mani >Priority: Major > Fix For: 2.1.0 > > Attachments: Design Proposal for Hive Metastore Plugin of Ranger - > V1.2.docx, Design Proposal for Hive Metastore Plugin of Ranger - V1.3.docx, > Design Proposal for Hive Metastore Plugin of Ranger - V1.4.docx, Design > Proposal for Hive Metastore Plugin of Ranger.docx, Design Proposal for Hive > Metastore Plugin of Ranger.docx > > > Currently there is no Ranger processing of Hive table meta store events that > could result in privilege modifications. One example is that when a table is > renamed by a Hive Server 2 client (the "beeline"), no proper privilege > adjustments in Ranger are made to allow/deny previously allowed/denied users > the same privileges as before. In addition, more advanced features, such as > granting/denying similar accesses to Hive's HDFS data to users that have (or > do not have) privileges in the Hive, would require that detailed metadata of > the Hive table, the storage info to be specific, be available to Ranger in > order to make the corresponding HDFS data accessible to the Hive users > directly. > This plugin will depend upon the existing Ranger Hive plugin, so it shares > the same "service" name as the associated Ranger Hive service deployed, and > it will be "co-enabled" with the existing Ranger Hive plugin. > Design doc will come soon. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (RANGER-3710) Release Apache Ranger 2.3.0
[ https://issues.apache.org/jira/browse/RANGER-3710?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17558737#comment-17558737 ] Ramesh Mani commented on RANGER-3710: - [~bpatel] Apache Ranger release 2.3.0 rc3 is ready for voting. So no more commit will be allowed in the branch. > Release Apache Ranger 2.3.0 > --- > > Key: RANGER-3710 > URL: https://issues.apache.org/jira/browse/RANGER-3710 > Project: Ranger > Issue Type: Task > Components: Ranger >Affects Versions: 2.3.0 >Reporter: Ramesh Mani >Assignee: Ramesh Mani >Priority: Major > Fix For: 2.3.0 > > > Release Apache Ranger 2.3.0 -- This message was sent by Atlassian Jira (v8.20.7#820007)
[jira] [Updated] (RANGER-3798) Ranger API Resource Metrics REST "Up time of JVM" does not update.
[ https://issues.apache.org/jira/browse/RANGER-3798?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ramesh Mani updated RANGER-3798: Fix Version/s: 3.0.0 (was: 2.3.0) > Ranger API Resource Metrics REST "Up time of JVM" does not update. > -- > > Key: RANGER-3798 > URL: https://issues.apache.org/jira/browse/RANGER-3798 > Project: Ranger > Issue Type: Bug > Components: Ranger >Reporter: Dineshkumar Yadav >Assignee: Dineshkumar Yadav >Priority: Minor > Fix For: 3.0.0 > > > Ranger API Resource Metrics REST, one of the attribute "Up time of JVM" does > not get updated value over the period of time . -- This message was sent by Atlassian Jira (v8.20.7#820007)
[jira] [Comment Edited] (RANGER-3730) log4j dependency is not completely removed
[ https://issues.apache.org/jira/browse/RANGER-3730?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17558735#comment-17558735 ] Ramesh Mani edited comment on RANGER-3730 at 6/25/22 6:57 AM: -- [~kirbyzhou] commit to Apache Ranger 2.3.0 release branch also. Thanks Please close the review request was (Author: rmani): [~kirbyzhou] commit to Apache Ranger 2.3.0 release branch also. Thanks > log4j dependency is not completely removed > -- > > Key: RANGER-3730 > URL: https://issues.apache.org/jira/browse/RANGER-3730 > Project: Ranger > Issue Type: Bug > Components: Ranger >Affects Versions: 3.0.0, 2.3.0 >Reporter: Bhavik Patel >Assignee: kirby zhou >Priority: Major > Fix For: 3.0.0, 2.3.0 > > Attachments: 0001-RANGER-3730-use-reload4j-to-replace-log4j.patch > > > log4j dependency is present in parent pom file - > [https://github.com/apache/ranger/blob/master/pom.xml#L166] > > [~madhan] [~ma3mansoori123] -- This message was sent by Atlassian Jira (v8.20.7#820007)
[jira] [Updated] (RANGER-3730) log4j dependency is not completely removed
[ https://issues.apache.org/jira/browse/RANGER-3730?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ramesh Mani updated RANGER-3730: Fix Version/s: 2.3.0 > log4j dependency is not completely removed > -- > > Key: RANGER-3730 > URL: https://issues.apache.org/jira/browse/RANGER-3730 > Project: Ranger > Issue Type: Bug > Components: Ranger >Affects Versions: 3.0.0, 2.3.0 >Reporter: Bhavik Patel >Assignee: kirby zhou >Priority: Major > Fix For: 3.0.0, 2.3.0 > > Attachments: 0001-RANGER-3730-use-reload4j-to-replace-log4j.patch > > > log4j dependency is present in parent pom file - > [https://github.com/apache/ranger/blob/master/pom.xml#L166] > > [~madhan] [~ma3mansoori123] -- This message was sent by Atlassian Jira (v8.20.7#820007)
[jira] [Commented] (RANGER-3730) log4j dependency is not completely removed
[ https://issues.apache.org/jira/browse/RANGER-3730?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17558735#comment-17558735 ] Ramesh Mani commented on RANGER-3730: - [~kirbyzhou] commit to Apache Ranger 2.3.0 release branch also. Thanks > log4j dependency is not completely removed > -- > > Key: RANGER-3730 > URL: https://issues.apache.org/jira/browse/RANGER-3730 > Project: Ranger > Issue Type: Bug > Components: Ranger >Affects Versions: 3.0.0, 2.3.0 >Reporter: Bhavik Patel >Assignee: kirby zhou >Priority: Major > Fix For: 3.0.0, 2.3.0 > > Attachments: 0001-RANGER-3730-use-reload4j-to-replace-log4j.patch > > > log4j dependency is present in parent pom file - > [https://github.com/apache/ranger/blob/master/pom.xml#L166] > > [~madhan] [~ma3mansoori123] -- This message was sent by Atlassian Jira (v8.20.7#820007)
