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. [image: Inline image 1]
