[jira] [Commented] (RANGER-3133) Ranger plugin audits to hdfs fail for presto

2020-12-24 Thread Bosco (Jira)


[ 
https://issues.apache.org/jira/browse/RANGER-3133?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17254695#comment-17254695
 ] 

Bosco commented on RANGER-3133:
---

I am assuming you are not running Presto in Hadoop. So it might be better for 
you not to enable audit to HDFS in your case.

> Ranger plugin audits to hdfs fail for presto
> 
>
> Key: RANGER-3133
> URL: https://issues.apache.org/jira/browse/RANGER-3133
> Project: Ranger
>  Issue Type: Bug
>  Components: Ranger
>Affects Versions: 2.1.0
>Reporter: Md Mehrab Alam
>Priority: Major
>
> 2020-12-25T01:30:30.057+0530 ERROR 
> org.apache.ranger.audit.queue.AuditBatchQueue0 
> org.apache.ranger.audit.provider.BaseAuditHandler Error writing to log 
> file.2020-12-25T01:30:30.057+0530 ERROR 
> org.apache.ranger.audit.queue.AuditBatchQueue0 
> org.apache.ranger.audit.provider.BaseAuditHandler Error writing to log 
> file.org.apache.hadoop.fs.UnsupportedFileSystemException: No FileSystem for 
> scheme "hdfs" at 
> org.apache.hadoop.fs.FileSystem.getFileSystemClass(FileSystem.java:3332) at 
> org.apache.hadoop.fs.FileSystem.createFileSystem(FileSystem.java:3352) at 
> org.apache.hadoop.fs.FileSystem.access$200(FileSystem.java:124) at 
> org.apache.hadoop.fs.FileSystem$Cache.getInternal(FileSystem.java:3403) at 
> org.apache.hadoop.fs.FileSystem$Cache.get(FileSystem.java:3371) at 
> org.apache.hadoop.fs.FileSystem.get(FileSystem.java:477) at 
> org.apache.ranger.audit.destination.HDFSAuditDestination.getLogFileStream(HDFSAuditDestination.java:277)
>  at 
> org.apache.ranger.audit.destination.HDFSAuditDestination$1.run(HDFSAuditDestination.java:157)
>  at 
> org.apache.ranger.audit.destination.HDFSAuditDestination$1.run(HDFSAuditDestination.java:154)
>  at java.base/java.security.AccessController.doPrivileged(Native Method) at 
> java.base/javax.security.auth.Subject.doAs(Subject.java:423) at 
> org.apache.hadoop.security.UserGroupInformation.doAs(UserGroupInformation.java:1729)
>  at 
> org.apache.ranger.audit.provider.MiscUtil.executePrivilegedAction(MiscUtil.java:529)
>  at 
> org.apache.ranger.audit.destination.HDFSAuditDestination.logJSON(HDFSAuditDestination.java:154)
>  at 
> org.apache.ranger.audit.destination.HDFSAuditDestination.log(HDFSAuditDestination.java:227)
>  at 
> org.apache.ranger.audit.queue.AuditBatchQueue.runLogAudit(AuditBatchQueue.java:309)
>  at 
> org.apache.ranger.audit.queue.AuditBatchQueue.run(AuditBatchQueue.java:215) 
> at java.base/java.lang.Thread.run(Thread.java:834)



--
This message was sent by Atlassian Jira
(v8.3.4#803005)


[jira] [Commented] (RANGER-3132) RangerDefaultAuditHandler: mapping problem for AuthzAuditEvent between ActionType and Action

2020-12-24 Thread Bosco (Jira)


[ 
https://issues.apache.org/jira/browse/RANGER-3132?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17254623#comment-17254623
 ] 

Bosco commented on RANGER-3132:
---

[~rroodd] thanks for catching it. This is a small, but critical change. 
[~madhan] can you help to do a quick review? Thanks

> RangerDefaultAuditHandler: mapping problem for AuthzAuditEvent between 
> ActionType and Action
> 
>
> Key: RANGER-3132
> URL: https://issues.apache.org/jira/browse/RANGER-3132
> Project: Ranger
>  Issue Type: Bug
>  Components: plugins
>Affects Versions: 2.1.0
>Reporter: Rodolphe Dugé de Bernonville
>Priority: Minor
>
> in RangerDefaultAuditHandler, method getAuthzEvents
> we have 
> ret.setAction(request.getAccessType());
> ret.setAccessType(request.getAction());
> it seems to be overridden in all plugins except the hbase plugin
>  
>  
>  



--
This message was sent by Atlassian Jira
(v8.3.4#803005)


[jira] [Commented] (RANGER-3085) Require column masking based on the value of another column

2020-12-04 Thread Bosco (Jira)


[ 
https://issues.apache.org/jira/browse/RANGER-3085?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17244418#comment-17244418
 ] 

Bosco commented on RANGER-3085:
---

[~xbbnyzh] where is the mapping for user to department mapping?

> Require column masking based on the value of another column
> ---
>
> Key: RANGER-3085
> URL: https://issues.apache.org/jira/browse/RANGER-3085
> Project: Ranger
>  Issue Type: Improvement
>  Components: admin, Ranger
>Reporter: Vishal Khare
>Priority: Critical
>  Labels: features
>
> Right now, I can create a custom hive function and configure it to enable 
> masking on the masking screen. The column that needs to be masked will be 
> provided as a parameter to the custom hive function that I create.
>  
> There is a requirement to mask a column of only certain rows based on some 
> logic depending on another column that do not needs to be masked.
> E.g - Lets' say there are 5 columns in my hive table namely name, age, dept, 
> salary and username.
>  
> If Employee 1 belongs to 'A' department. He should be able to see salary for 
> only 'A' employees. However all others rows should also be returned to 
> Employee 1 but their salary column should be masked.
>  
> This requirement is critical to our use case because of which we are not able 
> to utilize ranger. Any help would be appreciated.



--
This message was sent by Atlassian Jira
(v8.3.4#803005)


[jira] [Created] (RANGER-3059) Make 2-way SSL authentication in Ranger Plugin more resilient

2020-10-25 Thread Bosco (Jira)
Bosco created RANGER-3059:
-

 Summary: Make 2-way SSL authentication in Ranger Plugin more 
resilient 
 Key: RANGER-3059
 URL: https://issues.apache.org/jira/browse/RANGER-3059
 Project: Ranger
  Issue Type: Task
  Components: admin, plugins
Reporter: Bosco
Assignee: Bosco


Currently, the 2-way SSL authentication code doesn't have enough logs for 
debugging. Also, some edge cases like certificate chaining are not handled 
elegantly.



--
This message was sent by Atlassian Jira
(v8.3.4#803005)


[jira] [Commented] (RANGER-2774) Enhance RangerBasePlugin to be able to retrieve all policies for a user, and list of groups.

2020-04-12 Thread Bosco (Jira)


[ 
https://issues.apache.org/jira/browse/RANGER-2774?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17081879#comment-17081879
 ] 

Bosco commented on RANGER-2774:
---

I feel it does. But I don't see the patch anymore to reference it. I feel if 
you stick to the commonly used method, you should be okay.

> Enhance RangerBasePlugin to be able to retrieve all policies for a user, and 
> list of groups.
> 
>
> Key: RANGER-2774
> URL: https://issues.apache.org/jira/browse/RANGER-2774
> Project: Ranger
>  Issue Type: New Feature
>  Components: Ranger
>Reporter: Mert Hocanin
>Assignee: Mert Hocanin
>Priority: Minor
>
> Currently, the RangerBasePlugin has API's that given a RangerAccessRequest, 
> it will return a RangerAccessResult which returns basically whether the 
> access is grantable or not. However, there are certain use cases where a 
> developer may want to pull all policies that a user and list of groups may 
> have access to. One use case that we had in mind was to translate a policy 
> from a calling user to another policy management system. 



--
This message was sent by Atlassian Jira
(v8.3.4#803005)


[jira] [Commented] (RANGER-2634) Add ElasticSearch support

2020-04-12 Thread Bosco (Jira)


[ 
https://issues.apache.org/jira/browse/RANGER-2634?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17081876#comment-17081876
 ] 

Bosco commented on RANGER-2634:
---

[~acharneski] I am still getting the same error. Checking at 
https://reviews.apache.org/r/71921/, it seems it was last updated 2 weeks ago. 
And also your pull request https://github.com/acharneski/ranger/pull/3/commits 
is pretty old.

Am I looking at the wrong place?

Thank

> Add ElasticSearch support
> -
>
> Key: RANGER-2634
> URL: https://issues.apache.org/jira/browse/RANGER-2634
> Project: Ranger
>  Issue Type: Wish
>  Components: audit
>Reporter: Andrew Charneski
>Priority: Major
>
> Hello,
> Our organization is working on integrating and rolling out Apache Ranger for 
> our internal toolset, and firstly, we'd like to thank you all for your great 
> work!
> Although we have decided to adopt Ranger, for a variety of reasons we would 
> very much like to use an alternate indexing service (Elasticsearch) in 
> preference to the currently-supported Solr.
> We are happy to develop this extension on our own, and the initial efforts 
> are underway at [https://github.com/acharneski/ranger/pull/1] however we 
> would like to engage the community for guidance and suggestions with the aim 
> of getting this change merged into the main codebase when it is ready.
> Our initial approach is in three main phases:
>  # Isolate all usages of Solr packages/classes to pass through an API 
> wrapper, delegating to the original Solr code with minimal changes. (Dev 
> complete)
>  # Refactor api package as a pluggable interface with greater simplicity and 
> implementation agnosticism.
>  # Provide alternate implementation for the new interface for Elasticsearch.
> Any guidance and feedback is appreciated. Thank you for reading!



--
This message was sent by Atlassian Jira
(v8.3.4#803005)


[jira] [Comment Edited] (RANGER-2634) Add ElasticSearch support

2020-04-12 Thread Bosco (Jira)


[ 
https://issues.apache.org/jira/browse/RANGER-2634?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17081876#comment-17081876
 ] 

Bosco edited comment on RANGER-2634 at 4/12/20, 6:12 PM:
-

[~acharneski] I am still getting the same error. Checking at 
https://reviews.apache.org/r/71921/, it seems it was last updated 2 weeks ago. 
And also your pull request https://github.com/acharneski/ranger/pull/3/commits 
is pretty old.

Am I looking at the wrong place?

Thanks


was (Author: bosco):
[~acharneski] I am still getting the same error. Checking at 
https://reviews.apache.org/r/71921/, it seems it was last updated 2 weeks ago. 
And also your pull request https://github.com/acharneski/ranger/pull/3/commits 
is pretty old.

Am I looking at the wrong place?

Thank

> Add ElasticSearch support
> -
>
> Key: RANGER-2634
> URL: https://issues.apache.org/jira/browse/RANGER-2634
> Project: Ranger
>  Issue Type: Wish
>  Components: audit
>Reporter: Andrew Charneski
>Priority: Major
>
> Hello,
> Our organization is working on integrating and rolling out Apache Ranger for 
> our internal toolset, and firstly, we'd like to thank you all for your great 
> work!
> Although we have decided to adopt Ranger, for a variety of reasons we would 
> very much like to use an alternate indexing service (Elasticsearch) in 
> preference to the currently-supported Solr.
> We are happy to develop this extension on our own, and the initial efforts 
> are underway at [https://github.com/acharneski/ranger/pull/1] however we 
> would like to engage the community for guidance and suggestions with the aim 
> of getting this change merged into the main codebase when it is ready.
> Our initial approach is in three main phases:
>  # Isolate all usages of Solr packages/classes to pass through an API 
> wrapper, delegating to the original Solr code with minimal changes. (Dev 
> complete)
>  # Refactor api package as a pluggable interface with greater simplicity and 
> implementation agnosticism.
>  # Provide alternate implementation for the new interface for Elasticsearch.
> Any guidance and feedback is appreciated. Thank you for reading!



--
This message was sent by Atlassian Jira
(v8.3.4#803005)


[jira] [Created] (RANGER-2778) Create Ranger Service Def for S3

2020-04-03 Thread Bosco (Jira)
Bosco created RANGER-2778:
-

 Summary: Create Ranger Service Def for S3
 Key: RANGER-2778
 URL: https://issues.apache.org/jira/browse/RANGER-2778
 Project: Ranger
  Issue Type: Task
  Components: plugins
Reporter: Bosco
Assignee: Bosco


Create a Ranger ServiceDef for Ranger Plugin which can be implemented  by 
different providers



--
This message was sent by Atlassian Jira
(v8.3.4#803005)


[jira] [Commented] (RANGER-2774) Enhance RangerBasePlugin to be able to retrieve all policies for a user, and list of groups.

2020-04-03 Thread Bosco (Jira)


[ 
https://issues.apache.org/jira/browse/RANGER-2774?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17074670#comment-17074670
 ] 

Bosco commented on RANGER-2774:
---

[~mert_hoc] thanks for contributing to the Ranger community. I have added you 
as a contributor and assigned this JIRA to you.

Would you be able to upload your patch to the review board? It will be easy for 
us to provide feedback and commit the code.  
https://cwiki.apache.org/confluence/pages/viewpage.action?pageId=55151244


Thanks


> Enhance RangerBasePlugin to be able to retrieve all policies for a user, and 
> list of groups.
> 
>
> Key: RANGER-2774
> URL: https://issues.apache.org/jira/browse/RANGER-2774
> Project: Ranger
>  Issue Type: New Feature
>  Components: Ranger
>Reporter: Mert Hocanin
>Assignee: Mert Hocanin
>Priority: Minor
> Attachments: RANGER-2774.patch
>
>
> Currently, the RangerBasePlugin has API's that given a RangerAccessRequest, 
> it will return a RangerAccessResult which returns basically whether the 
> access is grantable or not. However, there are certain use cases where a 
> developer may want to pull all policies that a user and list of groups may 
> have access to. One use case that we had in mind was to translate a policy 
> from a calling user to another policy management system. 



--
This message was sent by Atlassian Jira
(v8.3.4#803005)


[jira] [Assigned] (RANGER-2774) Enhance RangerBasePlugin to be able to retrieve all policies for a user, and list of groups.

2020-04-03 Thread Bosco (Jira)


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

Bosco reassigned RANGER-2774:
-

Assignee: Mert Hocanin

> Enhance RangerBasePlugin to be able to retrieve all policies for a user, and 
> list of groups.
> 
>
> Key: RANGER-2774
> URL: https://issues.apache.org/jira/browse/RANGER-2774
> Project: Ranger
>  Issue Type: New Feature
>  Components: Ranger
>Reporter: Mert Hocanin
>Assignee: Mert Hocanin
>Priority: Minor
> Attachments: RANGER-2774.patch
>
>
> Currently, the RangerBasePlugin has API's that given a RangerAccessRequest, 
> it will return a RangerAccessResult which returns basically whether the 
> access is grantable or not. However, there are certain use cases where a 
> developer may want to pull all policies that a user and list of groups may 
> have access to. One use case that we had in mind was to translate a policy 
> from a calling user to another policy management system. 



--
This message was sent by Atlassian Jira
(v8.3.4#803005)


[jira] [Commented] (RANGER-2634) Add ElasticSearch support

2020-03-14 Thread Bosco (Jira)


[ 
https://issues.apache.org/jira/browse/RANGER-2634?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17059421#comment-17059421
 ] 

Bosco commented on RANGER-2634:
---

[~acharneski] just checking were you able to apply the patch? Thanks

> Add ElasticSearch support
> -
>
> Key: RANGER-2634
> URL: https://issues.apache.org/jira/browse/RANGER-2634
> Project: Ranger
>  Issue Type: Wish
>  Components: audit
>Reporter: Andrew Charneski
>Priority: Major
>
> Hello,
> Our organization is working on integrating and rolling out Apache Ranger for 
> our internal toolset, and firstly, we'd like to thank you all for your great 
> work!
> Although we have decided to adopt Ranger, for a variety of reasons we would 
> very much like to use an alternate indexing service (Elasticsearch) in 
> preference to the currently-supported Solr.
> We are happy to develop this extension on our own, and the initial efforts 
> are underway at [https://github.com/acharneski/ranger/pull/1] however we 
> would like to engage the community for guidance and suggestions with the aim 
> of getting this change merged into the main codebase when it is ready.
> Our initial approach is in three main phases:
>  # Isolate all usages of Solr packages/classes to pass through an API 
> wrapper, delegating to the original Solr code with minimal changes. (Dev 
> complete)
>  # Refactor api package as a pluggable interface with greater simplicity and 
> implementation agnosticism.
>  # Provide alternate implementation for the new interface for Elasticsearch.
> Any guidance and feedback is appreciated. Thank you for reading!



--
This message was sent by Atlassian Jira
(v8.3.4#803005)


[jira] [Commented] (RANGER-2634) Add ElasticSearch support

2020-03-07 Thread Bosco (Jira)


[ 
https://issues.apache.org/jira/browse/RANGER-2634?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17054224#comment-17054224
 ] 

Bosco commented on RANGER-2634:
---

[~acharneski] sorry for the delay. I have given my feedback in the review board.

I was not able to apply the patch and test it. Can you help me resolve this 
error?

git apply --check  0001-Added-ElasticSearch-Audit-DB-support.patch 
error: patch failed: pom.xml:130
error: pom.xml: patch does not apply
error: patch failed: 
security-admin/src/main/java/org/apache/ranger/solr/SolrAccessAuditsService.java:19
error: 
security-admin/src/main/java/org/apache/ranger/solr/SolrAccessAuditsService.java:
 patch does not apply
error: src/main/assembly/hive-agent.xml: No such file or directory

Thanks

> Add ElasticSearch support
> -
>
> Key: RANGER-2634
> URL: https://issues.apache.org/jira/browse/RANGER-2634
> Project: Ranger
>  Issue Type: Wish
>  Components: audit
>Reporter: Andrew Charneski
>Priority: Major
>
> Hello,
> Our organization is working on integrating and rolling out Apache Ranger for 
> our internal toolset, and firstly, we'd like to thank you all for your great 
> work!
> Although we have decided to adopt Ranger, for a variety of reasons we would 
> very much like to use an alternate indexing service (Elasticsearch) in 
> preference to the currently-supported Solr.
> We are happy to develop this extension on our own, and the initial efforts 
> are underway at [https://github.com/acharneski/ranger/pull/1] however we 
> would like to engage the community for guidance and suggestions with the aim 
> of getting this change merged into the main codebase when it is ready.
> Our initial approach is in three main phases:
>  # Isolate all usages of Solr packages/classes to pass through an API 
> wrapper, delegating to the original Solr code with minimal changes. (Dev 
> complete)
>  # Refactor api package as a pluggable interface with greater simplicity and 
> implementation agnosticism.
>  # Provide alternate implementation for the new interface for Elasticsearch.
> Any guidance and feedback is appreciated. Thank you for reading!



--
This message was sent by Atlassian Jira
(v8.3.4#803005)


[jira] [Commented] (RANGER-2634) Add ElasticSearch support

2020-01-23 Thread Bosco (Jira)


[ 
https://issues.apache.org/jira/browse/RANGER-2634?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17022567#comment-17022567
 ] 

Bosco commented on RANGER-2634:
---

[~acharneski] which version of Elastic Search should I use? Thanks

> Add ElasticSearch support
> -
>
> Key: RANGER-2634
> URL: https://issues.apache.org/jira/browse/RANGER-2634
> Project: Ranger
>  Issue Type: Wish
>  Components: audit
>Reporter: Andrew Charneski
>Priority: Major
>
> Hello,
> Our organization is working on integrating and rolling out Apache Ranger for 
> our internal toolset, and firstly, we'd like to thank you all for your great 
> work!
> Although we have decided to adopt Ranger, for a variety of reasons we would 
> very much like to use an alternate indexing service (Elasticsearch) in 
> preference to the currently-supported Solr.
> We are happy to develop this extension on our own, and the initial efforts 
> are underway at [https://github.com/acharneski/ranger/pull/1] however we 
> would like to engage the community for guidance and suggestions with the aim 
> of getting this change merged into the main codebase when it is ready.
> Our initial approach is in three main phases:
>  # Isolate all usages of Solr packages/classes to pass through an API 
> wrapper, delegating to the original Solr code with minimal changes. (Dev 
> complete)
>  # Refactor api package as a pluggable interface with greater simplicity and 
> implementation agnosticism.
>  # Provide alternate implementation for the new interface for Elasticsearch.
> Any guidance and feedback is appreciated. Thank you for reading!



--
This message was sent by Atlassian Jira
(v8.3.4#803005)


[jira] [Commented] (RANGER-2634) Add ElasticSearch support

2019-12-07 Thread Bosco (Jira)


[ 
https://issues.apache.org/jira/browse/RANGER-2634?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16990765#comment-16990765
 ] 

Bosco commented on RANGER-2634:
---

Hi [~acharneski] sorry for  the delay. I can try it out.

For reviewing the code, would you be able to create a Review Board request?  
https://cwiki.apache.org/confluence/pages/viewpage.action?pageId=55151244

Thanks


> Add ElasticSearch support
> -
>
> Key: RANGER-2634
> URL: https://issues.apache.org/jira/browse/RANGER-2634
> Project: Ranger
>  Issue Type: Wish
>  Components: audit
>Reporter: Andrew Charneski
>Priority: Major
>
> Hello,
> Our organization is working on integrating and rolling out Apache Ranger for 
> our internal toolset, and firstly, we'd like to thank you all for your great 
> work!
> Although we have decided to adopt Ranger, for a variety of reasons we would 
> very much like to use an alternate indexing service (Elasticsearch) in 
> preference to the currently-supported Solr.
> We are happy to develop this extension on our own, and the initial efforts 
> are underway at [https://github.com/acharneski/ranger/pull/1] however we 
> would like to engage the community for guidance and suggestions with the aim 
> of getting this change merged into the main codebase when it is ready.
> Our initial approach is in three main phases:
>  # Isolate all usages of Solr packages/classes to pass through an API 
> wrapper, delegating to the original Solr code with minimal changes. (Dev 
> complete)
>  # Refactor api package as a pluggable interface with greater simplicity and 
> implementation agnosticism.
>  # Provide alternate implementation for the new interface for Elasticsearch.
> Any guidance and feedback is appreciated. Thank you for reading!



--
This message was sent by Atlassian Jira
(v8.3.4#803005)


[jira] [Commented] (RANGER-1429) Ranger Audit solrconfig.xml optimizations

2019-11-09 Thread Bosco (Jira)


[ 
https://issues.apache.org/jira/browse/RANGER-1429?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16971030#comment-16971030
 ] 

Bosco commented on RANGER-1429:
---

[~krisden] I don't think we are using spell check in Ranger audits.

> Ranger Audit solrconfig.xml optimizations
> -
>
> Key: RANGER-1429
> URL: https://issues.apache.org/jira/browse/RANGER-1429
> Project: Ranger
>  Issue Type: Bug
>  Components: audit
>Affects Versions: 0.7.0
>Reporter: Greg Senia
>Priority: Major
> Attachments: RANGER-1429.patch
>
>
> When using SolrCloud and having a single shard single replica with a large 
> number of audit records 20GB for 2 weeks. It takes Solr a very long time to 
> open up the replica for work. After doing some research I determine via 
> thread dumps that on the first request to the Solr Collection it kicks off a 
> Suggestion thread and a SpellCheck thread. I propose removing these as it 
> does not seem to impact RangerAudit and solves the issue of Solr 
> ranger_audits collection being unavailable after solr startup.



--
This message was sent by Atlassian Jira
(v8.3.4#803005)


[jira] [Commented] (RANGER-2634) Modularize Solr dependency

2019-11-01 Thread Bosco (Jira)


[ 
https://issues.apache.org/jira/browse/RANGER-2634?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16965230#comment-16965230
 ] 

Bosco commented on RANGER-2634:
---

Hi [~acharneski]

Thanks for your interest in contributing to Ranger.

I am curious if you considered of just creating another implementation of 
AuditDestination,. e.g. ElasticAuditDestination?  And override the log() 
methods? In this way, you can just configure Ranger plugin to use your 
destination?

I feel, the plugins are easy. However, the Ranger Portal might need more work 
in supporting Elastic Search. You design might be more applicable on the portal 
side.



> Modularize Solr dependency
> --
>
> Key: RANGER-2634
> URL: https://issues.apache.org/jira/browse/RANGER-2634
> Project: Ranger
>  Issue Type: Wish
>  Components: audit
>Reporter: Andrew Charneski
>Priority: Major
>
> Hello,
> Our organization is working on integrating and rolling out Apache Ranger for 
> our internal toolset, and firstly, we'd like to thank you all for your great 
> work!
> Although we have decided to adopt Ranger, for a variety of reasons we would 
> very much like to use an alternate indexing service (Elasticsearch) in 
> preference to the currently-supported Solr.
> We are happy to develop this extension on our own, and the initial efforts 
> are underway at [https://github.com/acharneski/ranger/pull/1] however we 
> would like to engage the community for guidance and suggestions with the aim 
> of getting this change merged into the main codebase when it is ready.
> Our initial approach is in three main phases:
>  # Isolate all usages of Solr packages/classes to pass through an API 
> wrapper, delegating to the original Solr code with minimal changes. (Dev 
> complete)
>  # Refactor api package as a pluggable interface with greater simplicity and 
> implementation agnosticism.
>  # Provide alternate implementation for the new interface for Elasticsearch.
> Any guidance and feedback is appreciated. Thank you for reading!



--
This message was sent by Atlassian Jira
(v8.3.4#803005)


[jira] [Commented] (RANGER-924) Support Authorization and Auditing for Zookeeper

2019-10-02 Thread Bosco (Jira)


[ 
https://issues.apache.org/jira/browse/RANGER-924?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16943216#comment-16943216
 ] 

Bosco commented on RANGER-924:
--

Hi [~andorm] thanks for your interest in contributing. 

Ranger uses the plugin architecture. If you are able to call Ranger plugin at a 
point where the authorization can be called, then Ranger infrastructure will 
take care from there. Generally we ask the component to create an interface for 
their authorization implementation and make the implementation configurable. In 
this way, the existing functionality will work and anyone who wants Ranger, 
then they can change the configuration to use Ranger implementation.

Regarding Audit, Ranger takes care of it as part of its audit framework. It has 
inbuilt summary concept which scales to the performance requirements for Kakfa 
and HBase. So I feel we should be okay here.

Regarding Authentication, since Zookeeper uses Kerberos, I feel we should be 
okay. Ranger comes post authentication/connection anyway. We can discuss this 
in more detail if needed.

If you have a Ranger Service def in mind, we can start from there. I feel, it 
will follow "File" like permission. Folders/Files with read/write/delete 
permissions.

Happy to help anywhere I can.

Thanks




> Support Authorization and Auditing for Zookeeper
> 
>
> Key: RANGER-924
> URL: https://issues.apache.org/jira/browse/RANGER-924
> Project: Ranger
>  Issue Type: Improvement
>Reporter: Bosco
>Priority: Major
>
> Most of the Hadoop components are storing their states in Zookeeper. And some 
> products (Kafka and Solr) are even storing security policies in Zookeeper.
> Since there are no human interaction with Zookeeper, very often, setting up 
> access controls to Zookeeper are ignored. However, it is very critical to 
> ensure that proper authorization controls are setup for Zookeeper and all 
> access are audited.
> If would be good if some familiar with Zookeeper can work on a Ranger plugin 
> for Zookeeper. Or help the Ranger team to come with the integration design.



--
This message was sent by Atlassian Jira
(v8.3.4#803005)