Hi Nick, I support this direction, but would like to better understand the extent of the proposal.
Do you expect to automate FullDev spin-up with a KDC, realm and principals, and automate the kinit process for all? Currently there is a quite well documented manual process, but I don’t think it’s reasonable to step thru that for every dev test. If we automate that, how do we avoid interfering with local policy in labs that already have a KDC? In particular, many enterprise environments use ActiveDirectory as their KDC, while we will presumably use MIT for the built-in. The three choices Ambari provides (existing MIT KDC, existing AD KDC, or manage principals and keytabs manually) would be good to apply at the higher level, with a fourth choice of “instantiate local MIT KDC”. Can Kerberos run satisfactorily in QuickDev? If so, need for KDC applies, and it would still be good to allow QuickDev to come up without Kerberos as a simplified environment when that’s desirable. Thanks, --Matt From: Nick Allen <[email protected]> Reply-To: "[email protected]" <[email protected]> Date: Monday, May 1, 2017 at 7:57 AM To: dev <[email protected]> Subject: [DISCUSS] Kerberos First I hate dealing with Kerberos. It is a pain to setup, it is a pain to work with, it has its own learning curve, but it is absolutely necessary. Due to the sensitive nature of Metron's use case, most of our users should be using Kerberos as part of a defense-in-depth strategy to protect sensitive data. For the upcoming 0.4.0 release, we have all put in a tremendous amount of work to make integrating Metron into a Kerberized cluster as simple as possible. I hated every minute of it, but the end result speaks for itself. Really great work, everyone. Proposal I am proposing that as a community we choose to support Kerberos first. We should not treat Kerberos as an optional add-on, but as an absolutely necessary component; no different than Kafka or Storm. Should we choose to take this approach as a community, I would assume at least the following by-products. I am sure there are others, but this is a start. All PRs should be tested against a Kerberized environment. All docs should be written assuming a Kerberized environment. All development environments should spin-up pre-Kerberized. If a feature does not support Kerberos, then it should be marked experimental and not suitable for production use. Benefits Metron needs to be secure by default. Production deployments of Metron should use Kerberos, so we should developing and testing features against the same target. Dealing with the pains of Kerberos day-to-day will drive us to think of ways to make it easier to use and less of a pain for our users.
