metron-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Simon Elliston Ball <si...@simonellistonball.com>
Subject Re: [DISCUSS] Getting to a 1.0 release
Date Wed, 15 Aug 2018 19:47:19 GMT
What would you see as secure? I’ve seen people use TDE for the HDFS store, but it’s harder
to encrypt storage with solr / es. Something I was thinking of doing to follow up on the Knox
Feature was to add Ranger integration for securing and auditing configs, and potentially extending
to the index destinations. Do you think that would cover the secure storage concept? 

Simon

> On 15 Aug 2018, at 20:39, Otto Fowler <ottobackwards@gmail.com> wrote:
> 
> Secure storage off the top of my head
> 
> On August 15, 2018 at 14:49:26, Zeolla@GMail.com (zeolla@gmail.com) wrote:
> 
> So, as has been discussed in a few
> <
> https://lists.apache.org/thread.html/0445cd8f94dfb844cd5a23ac3eeca04c9f44c9d8f269c6ef12cb3598@%3Cdev.metron.apache.org%3E>
> 
> other
> <
> https://lists.apache.org/thread.html/427a20c22207e84331b94e8ead9a4172a22577d26eb581c0e564d0dc@%3Cdev.metron.apache.org%3E>
> 
> recent dev list threads, I would like to discuss what a Metron 1.0 release
> looks like.
> 
> In order to kick off the conversation, I would like to make a few
> suggestions regarding "what 1.0 means to me," but I'm very interested to
> hear everybody else's opinions.
> 
> In order to go 1.0 I believe we should have:
> 1. A clear, supported method of upgrading from one version of Metron to the
> next. We have attempted
> <https://github.com/apache/metron/blob/master/Upgrading.md> to make this
> easier in the past, but it is currently not
> <
> https://github.com/apache/metron/tree/master/metron-deployment/packaging/ambari/metron-mpack#limitations>
> 
> supported
> <
> https://github.com/apache/metron/tree/master/metron-deployment/packaging/ambari/elasticsearch-mpack#limitations>
> 
> .
> 2. Authentication for all of the UIs and APIs should be secure and support
> SSO. I believe this is in progress via METRON-1663
> <https://issues.apache.org/jira/browse/METRON-1663>.
> 3. Each of our personas
> <
> https://cwiki.apache.org/confluence/display/METRON/Metron+User+Personas+And+Benefits>
> 
> should
> be well documented, understood, and supported.
> - The current state of documentation is, in my opinion, inadequate and I
> admit I am partially to blame for this. I suggest we define a strict
> approach for documentation, align to it (such as perhaps migrating all
> useful wiki documentation to git), and enforce it.
> - I would consider METRON-1699
> <https://issues.apache.org/jira/browse/METRON-1699> as a critical item for
> a Security Data Scientist, but it is currently not clear to me where the
> line exists between some of the other personas, or that each persona has
> been sufficiently implemented.
> 4. A performance tuning guide should be available for all of the main
> components, whether as an independent document or as a part of a larger
> document.
> 5. Simple data ingest.
> - Similar to the ongoing conversation for NiFi integration
> <
> https://lists.apache.org/thread.html/d7bb4d32c8c42bd40b2f26973f989bcba16010a672fd8a533a5544bf@%3Cdev.metron.apache.org%3E>,
> 
> we should be able to say that we have broken down the barriers to getting
> data into a Metron cluster in easy and efficient ways. In addition to
> NiFi, having support for other popular tools such as beats
> <https://www.elastic.co/products/beats>, fluentd <https://www.fluentd.org/>,
> 
> etc.
> - Parsers should be pluggable, with independent tests and the ability to
> make versioned modifications with roll-backs.
> 
> What else? Are any of these items not necessary for a 1.0?
> 
> Jon
> -- 
> 
> Jon

Mime
View raw message