Securing a NiFi 2.0 cluster

@jfs912 

NiFi 2.x is secured in the same way as NiFi 1.x was secured.  The Apache NIFi community made a decision to move away from providing a toolkit for generating TLS certificates since it did not make sense to have its own tool to manage certificate creation when there is nothing special the toolkit does (NIFI-12200)

.  You can create your own self signed certificates (simple web search will show many resources on how to do this), you can use a certificate service to create yoru certificates and sign them for you, you can setup your own certificate authority for signing your certificates, etc.    It really made no sense for Apache NiFi to maintain this code. 

The important parts to remember when creating your NiFi certificates are:
Keystore for NiFi:

• Must contain 1 and only 1 PrivateKey entry
• PrivateKey entry DN must NOT contain wildcards.  The DN is used as the client identity and use of wildcards in client identities is not a proper security practice.
• PrivateKey entry must have ExtendedKeyUsage with both ClientAuth and ServerAuth.  NiFi uses this certificate for both client and server authorizations
• PrivateKey entry must include at least one SAN entry that matches the hostname of the NiFi server on which the certificate will be used. During a TLS exchange hostname verification is performed to make sure the hostname accessed via the URL used matches a SAN entry in the Server certificate the target server responds with.  It is not uncommon for a certificate to contain more then one SAN entry.
• Recommend that PrivateKey password and Keystore password are the same.

Truststore for NiFi:

• The NiFi truststore contains one too many trusted cert entries.  Some choose to use the Java default cacerts (truststore) file and just add the NiFi additional trusted certs entries to it.  This same truststore is then used on every node in a NiFi cluster.
• Must contain the complete trusts chain for the NiFi certificates.  A NiFi certificate may be self signed meaning the issuer and signer are the same DistinquishedName (DN).  I this case the public cert for each of yoru NiFi node's certificates needs to be added to the truststore.  A NiFi certificate might be signed by an Intermediate Certificate Authority (CA).  An intermediate CA would be the signer DN for the NIFi certificate. An Intermediate CA will have a different Issuer and Signer DN.  The truststore must contain the public cert for this Intermediate CA.  There may be multiple levels of intermediate CAs before reaching the signer that is the root CA. The root CA public certificate can be identified  because it will have the same DN for issuer and signer.  The truststore must contain the public certificate for the root CA.  Having all the public certificates for every signer for the NiFi certificate to the Root CA makes up the complete trust chain required for trust of the signed NiFi certificate.

Please help our community grow. If you found any of the suggestions/solutions provided helped you with solving your issue or answering your question, please take a moment to login and click "Accept as Solution" on one or more of them that helped.

Thank you,
Matt

Matt, thanks for the response, unfortunately our deployment is a little more complicated than that. Its using a custom cetic helm chart and deployed in k8s. Considering what you said would you suggest not using the ca from cetic and just run this in a statefulset?