[
https://issues.apache.org/jira/browse/RANGER-2634?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16979343#comment-16979343
]
Andrew Charneski edited comment on RANGER-2634 at 11/25/19 10:54 PM:
---------------------------------------------------------------------
Hi [~bosco] -
This PR (at
[https://github.com/apache/ranger/pull/42|https://github.com/apache/ranger/pull/42)])
is ready for review and feedback. Some of the items are merely to get the
build to work in my environments. I'm happy to create the review on Reviewboard
if that's appropriate at this point, but had one major question first I'm
hoping you can provide guidance on.
My main concern is that I have been unable to test this functionality in an
integrated environment - Currently our organization is only using the Hive
plugin and my analysis of the code suggests that only "grant" and "revoke"
permission operations (in RangerBasePlugin) make use of
RangerAccessResultProcessor, which seems to end up in the audit log. Our test
environment does show such events, but I am fairly certain this does not
actually use the Audit DB (with the new Elasticsearch support). I have prepared
some test code that uses a local Elasticsearch to read and write events
(ElasticSearchAccessAuditsServiceTest) but have been unable to test actual
audit events in our integration test environment.
Do you have any suggestions on how to properly test this? Thank you very much
for your guidance and feedback!
was (Author: acharneski):
Hi [~bosco] -
This PR (at [https://github.com/apache/ranger/pull/42)] is ready for review and
feedback. Some of the items are merely to get the build to work in my
environments. I'm happy to create the review on Reviewboard if that's
appropriate at this point, but had one major question first I'm hoping you can
provide guidance on.
My main concern is that I have been unable to test this functionality in an
integrated environment - Currently our organization is only using the Hive
plugin and my analysis of the code suggests that only "grant" and "revoke"
permission operations (in RangerBasePlugin) make use of
RangerAccessResultProcessor, which seems to end up in the audit log. Our test
environment does show such events, but I am fairly certain this does not
actually use the Audit DB (with the new Elasticsearch support). I have prepared
some test code that uses a local Elasticsearch to read and write events
(ElasticSearchAccessAuditsServiceTest) but have been unable to test actual
audit events in our integration test environment.
Do you have any suggestions on how to properly test this? Thank you very much
for your guidance and feedback!
> 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)
