> Working this out within the community makes more sense, rather than doing this outside. Not attempting would be counterproductive.
Does this not argue directly against the rationale of the Argus proposal? Please correct me if I am wrong, but this suggests addressing security concerns within existing Hadoop ecosystem communities rather than attempting an overlay project. This applies equally to Sentry, on its current trajectory, by the way. > The option to externalize security is always a good thing. A contradiction with the above? But I agree that having a trustworthy option would be fantastic. > Option to externalize is a well accepted notion in the community. Commercial databases allow externalizing security, web applications externalize authentication and authorization, there are vulnerability management systems for file system/software version, etc. I don’t see a security provider like Argus or Sentry extending the native security as a risk or bad thing, instead, a good motivation for projects (particularly new) to focus on their core features. Concerns about starting a new community from a position of a lack of trust are ignored to the peril of this stated goal. I think Argus - or any project with aims to discuss, and ultimately convince, other projects to externalize a core matter like security - will fail to make their case if there is perceived risk. Any perceived risk will be proportional to lack of trust in the integrity, openness, and healthy function of an Argus PMC and community processes. We can ignore the elephant in the room, so to speak, and pretend like this proposal drops in out of the blue sky, but clear thinking individuals to whom you are making your case for externalization of security features at a later time will not. Establishing trust and a track record of inclusion and openness will be essential for Argus to achieve your objectives, if I understand them correctly. I encourage you to address concerns raised on this thread about the complexion of the initial PMC and mentorships. There have been a few suggestions worth exploring. > Similar discussion can be made between no-sql projects like Apache HBase, Apache Accumulo and Apache Cassandra. Not similar at all. This isn't about choice, this is about trust. Security and trust are wedded inseparably. On Thu, Jul 17, 2014 at 1:03 PM, Don Bosco Durai <bdu...@hortonworks.com> wrote: > Andrews, thanks for your feedback. My responses are inline. > > Regards > > Bosco > > On Jul 17, 2014, at 11:41 AM, Andrew Purtell <apurt...@apache.org> wrote: > > > Thank you for writing back with a detailed clarification. > > > > Regarding encryption at rest, HDFS is adding it as HDFS-6134, so likely > > there will be a new core feature option for the ecosystem to consider > > shortly. > > > > > I don’t feel one technology or one company or one small group or one > > approach can solve this problem. This has to be addressed by the > community > > working together. This would also require a lot of support from each > > dependent projects and lot of co-ordination. And there would be multiple > > security solutions available for the end users to pick from. > > > > Completely agreed. However, the desired community cooperation has both > > technical and political components. I think there are some concerns about > > how successful an outcome Argus may produce, informed by experience. > > Perhaps it would be worthwhile to address those concerns. Argus proposes > to > > The current Argus solution already has integration with the core Hadoop > components like HDFS, Hive and HBase. There are work in progress to support > additional Hadoop components, which includes Knox. Anytime, we cross > project boundaries, there were would be always challenges wrt technical and > political. Working this out within the community makes more sense, rather > than doing this outside. Not attempting would be counterproductive. > > > develop a common security infrastructure for the Hadoop ecosystem. In my > > opinion (and informed by personal experience) we have new incubating > Hadoop > > ecosystem security projects like Sentry and Knox and proposals such as > > Argus because Hadoop core is locked down. Argus et. al. are like the > > proverbial blocked river (user demand for features) seeking a new route > > around a landslide (obvious poisonous contention and litigation-via-JIRA > on > > every significant topic). I would be curious your thoughts on how to > avoid > > the same end state in the Argus project. In my opinion, it would be a > > tragedy if a potential solution ends up perpetuating the dysfunction it > > seeks to bypass to a greater proportion of Foundation projects instead. A > > Hadoop ecosystem project attempting to remain independent from the > > dysfunction of Hadoop core would be well advised to stay away from > adoption > > of Argus components (security is so critical) if the governance of Argus > I don’t believe Argus existence is because HDFS or any other component is > locked down or dysfunctional. Each component will continue to evolve (core > features and security) overtime based on their priority, severity and > timeline. The option to externalize security is always a good thing. Option > to externalize is a well accepted notion in the community. Commercial > databases allow externalizing security, web applications externalize > authentication and authorization, there are vulnerability management > systems for file system/software version, etc. I don’t see a security > provider like Argus or Sentry extending the native security as a risk or > bad thing, instead, a good motivation for projects (particularly new) to > focus on their core features. > > I also don’t feel this is a short term user demand. Security requirement > changes on regular basis and as different type of industries adopt hadoop, > their security requirements might be also different. They will look for > different options for security and select what addresses their needs. > > > perpetuates that dysfunction. By the way, it is also not too late for > Knox > > and Sentry. > > > Security is most effective when it is deployed as layered solution. Knox > addresses the perimeter security. Currently it is REST and they will extend > it to support security for more external API technologies. Argus will not > replace it, but complement Knox by centralizing the administration and > common auditing. Sentry and Argus have some overlap, but at the core, they > have different philosophies and approach. Similar discussion can be made > between no-sql projects like Apache HBase, Apache Accumulo and Apache > Cassandra. Varying options is always healthy. > > > > > > -- > CONFIDENTIALITY NOTICE > NOTICE: This message is intended for the use of the individual or entity to > which it is addressed and may contain information that is confidential, > privileged and exempt from disclosure under applicable law. If the reader > of this message is not the intended recipient, you are hereby notified that > any printing, copying, dissemination, distribution, disclosure or > forwarding of this communication is strictly prohibited. If you have > received this communication in error, please contact the sender immediately > and delete it from your system. Thank You. > > --------------------------------------------------------------------- > To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org > For additional commands, e-mail: general-h...@incubator.apache.org > > -- Best regards, - Andy Problems worthy of attack prove their worth by hitting back. - Piet Hein (via Tom White)
