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 >>
