Andy, Joe, Thank you for the feedback folks, we appreciate that very much.
Right, as you noted, that's our key use case, having Nifi use a PKI cert to retrieve a TGT and service ticket on-demand. The reasoning is also as you stated, the expectation that credential control using x509 management would provide better/tighter controls, over keytabs. For example, difficulties in auditing keytabs to ensure they weren't incorrectly copied or assigned unsafe permissions temporarily. Using a PkinitCredentialsService approach sounds very promising, thanks Andy for the info on this. patw On Fri, Jan 24, 2020 at 10:52 AM Andy LoPresto <[email protected]> wrote: > I believe the issue here is not NiFi to NiFi communication (where we use > PKI certs for TLS mutual authentication) or user to NiFi (where client > certificate authentication is currently available), but for NiFi to use a > PKI cert to retrieve a TGT & service ticket on-demand rather than > persisting a keytab internally. This allows for better control over the > credential material via X.509 expiration & revocation. > > I know there are people working on this that are currently investigating > pkinit to see if it is feasible to implement. The ticket mentioned below is > for complementing keytab capability with username/password credentials for > a related but different use case. > > Paul, it sounds like your move to this approach, while challenging, will > definitely enhance the security and auditability of your system. We would > definitely encourage you to contribute back your development process. I > think the cleanest approach would probably be to provide a custom > implementation of a controller service like KerberosCredentialsService [1] > called PkinitCredentialsService which points to a certificate/keystore and > accepts a password. You can reference KeytabCredentialsService [2] as a > reference implementation. > > [1] > https://github.com/apache/nifi/blob/master/nifi-nar-bundles/nifi-standard-services/nifi-kerberos-credentials-service-api/src/main/java/org/apache/nifi/kerberos/KerberosCredentialsService.java#L22 > < > https://github.com/apache/nifi/blob/master/nifi-nar-bundles/nifi-standard-services/nifi-kerberos-credentials-service-api/src/main/java/org/apache/nifi/kerberos/KerberosCredentialsService.java#L22 > > > [2] > https://github.com/apache/nifi/blob/master/nifi-nar-bundles/nifi-standard-services/nifi-kerberos-credentials-service-bundle/nifi-kerberos-credentials-service/src/main/java/org/apache/nifi/kerberos/KeytabCredentialsService.java > < > https://github.com/apache/nifi/blob/master/nifi-nar-bundles/nifi-standard-services/nifi-kerberos-credentials-service-bundle/nifi-kerberos-credentials-service/src/main/java/org/apache/nifi/kerberos/KeytabCredentialsService.java> > > > Andy LoPresto > [email protected] > [email protected] > PGP Fingerprint: 70EC B3E5 98A6 5A3F D3C4 BACE 3C6E F65B 2F7D EF69 > > > On Jan 24, 2020, at 7:51 AM, Joe Witt <[email protected]> wrote: > > > > Hello > > > > We already have tons of support for PKI/mutual Auth connections. For the > > kerberos stuff where you'd rather supply username/pword than keytabs we > got > > you there too based on the JIRA highlighted elsewhere in this thread. > > > > Are you seeing/concerned about other gaps? > > > > Thanks > > > > On Fri, Jan 24, 2020 at 10:37 AM Paul Poulosky > > <[email protected]> wrote: > > > >> Hi, Shawn. > >> > >> This is a corporate mandate in order to migrate to best practice w.r.t. > >> security. > >> > >> Yahoo runs very large 5000+ node clusters (Primarily HDFS / HBase / > Hive / > >> Spark / Storm) that are multi-tenant. The worker processes run as > >> individual headless users per project / application. A given project had > >> been using keytabs on launcher boxes in order to get a TGT into their > >> workers that would allow that headless user to authenticate with > services. > >> Keytabs don't expire, and there is no way of tracking who has a copy. We > >> have to depend on our users to set the file permissions up properly to > not > >> have them get stolen, etc. > >> > >> Moving to PKinit and X509 certs (which expire after 30 days) gives us a > >> higher level of security in our environment. We have to do this > everywhere, > >> not just Nifi. > >> > >> We would prefer to hack up the processors in order to do this work. We'd > >> like to do it in a way that would be acceptable to push back to open > >> source. > >> > >> Any direction you could give us in meeting this objective would be > greatly > >> appreciated. > >> > >> Thanks, > >> Paul > >> > >> On Thu, Jan 23, 2020 at 4:52 PM Shawn Weeks <[email protected]> > >> wrote: > >> > >>> If you don’t mind, what is the use case where keytabs aren’t working > for > >>> you? I’ve always found them easier since I don’t think you can setup > >>> passwords for service principals only user principals. > >>> > >>> > >>> > >>> Thanks > >>> > >>> Shawn > >>> > >>> > >>> > >>> *From: *Pat White <[email protected]> > >>> *Date: *Thursday, January 23, 2020 at 4:46 PM > >>> *To: *Shawn Weeks <[email protected]> > >>> *Cc: *"[email protected]" <[email protected]>, Paul Poulosky < > >>> [email protected]> > >>> *Subject: *Re: Any work planned for adding Kerberos pkinit support? > >>> > >>> > >>> > >>> Wow, a lot of work on this! Thank you very much Shawn, and my apologies > >>> for completely missing the Jiras, thanks for the help. > >>> > >>> > >>> > >>> patw > >>> > >>> > >>> > >>> > >>> > >>> > >>> > >>> On Thu, Jan 23, 2020 at 4:23 PM Shawn Weeks <[email protected] > > > >>> wrote: > >>> > >>> Password based Kerberos is in the works and might have made it in 1.11. > >>> I’ve been seeing the pull requests for a while now. > >>> > >>> Thanks > >>> Shawn > >>> > >>> Sent from my iPhone > >>> > >>>> On Jan 23, 2020, at 11:22 AM, Pat White <[email protected] > >> .invalid> > >>> wrote: > >>>> > >>>> Hi Folks, > >>>> > >>>> Is there any support for Kerberos authentication using Pkinit versus > >>>> keytabs, now or planned? > >>>> > >>>> Don't believe i saw anything documented, in Jira or in the src yet, > but > >>>> wanted to ask in case i've missed something. Specifically looking at > >> use > >>> by > >>>> processors, such as a service like the KeytabCredentialsService, as > >>>> opposed to user or ZK authentication. > >>>> > >>>> If not, any thoughts on an implementation approach? It seemed as > though > >>>> creating a peer service, or adding an x509 API to the existing service > >>> was > >>>> reasonable, however it looks like significant work is needed to have > >>>> Kerberos aware processors support both credential schemes. > >>>> > >>>> patw > >>> > >>> > >> > >> -- > >> <http://www.verizonmedia.com> > >> > >> Paul Poulosky > >> > >> Sr Software Dev Engineer > >> Grid Utilities > >> M 217 621 6120 > >> 1908 S First Street > >> US - Champaign S. First Street > >> Champaign, IL 61801 > >> > >
