Cloudera Docs

Securing communication between NiFi clusters using the Default Node SSL Context Service

Cloudera Data Flow automatically provisions a DefaultNodeSSLContextService controller service in the root process group of each NiFi cluster it manages. This controller service is an instance of StandardSSLContextService that references the node keystore and truststore generated by Cloudera Data Flow, making TLS credentials available to data flows and test sessions without requiring manual SSL configuration.

Cloudera Data Flow creates the DefaultNodeSSLContextService on initial deployment and checks it on every subsequent reconciliation.

  • If the service is missing, Cloudera Data Flow recreates it.
  • If the service is present, Cloudera Data Flowvalidates its configuration.

The service is configured with the following values:

You can reference the DefaultNodeSSLContextService in any processor that requires an SSL Context Service. For example, you can use it to secure communication between two NiFi clusters managed by the same operator instance, using an InvokeHTTP processor on the sending cluster and a ListenHTTP processor on the receiving cluster.

Ensure that:

  • You have an enabled and healthy Cloudera Data Flow environment.

  • You have been assigned the DFDeveloper role granting you access to the Flow Designer.

  • You have been assigned the DFCatalogAdmin or DFCatalogViewer role granting you access to the entire Catalog, or DFCollectionMember role granting you access to the specific collections where the flow definition is located. You will need this authorization to view and open flow definitions, and to publish your draft as a flow definition to the Catalog or a specific Catalog collection.

  • Both NiFi clusters are managed by the same Cloudera Data Flow instance.
  • The node certificates for both clusters are signed by the same root certificate authority, establishing a shared chain of trust.
  • The Kubernetes service for the receiving cluster exposes the port used by the ListenHTTP processor.
  1. On the receiving cluster, open the flow definition or draft for editing.
  2. Add a ListenHTTP processor and configure the following Properties.
    Base Path

    Enter the base path for the listener endpoint.

    For example: contentListener

    Listening Port

    Enter the port on which the processor listens for incoming requests.

    For example: 9999

    SSL Context Service

    Select DefaultNodeSSLContextService.

  3. On the sending cluster, open the flow definition or draft for editing.
  4. Add an InvokeHTTP processor to the draft and configure the following Properties.
    HTTP URL
    Enter the internal Kubernetes Service URL of the receiving cluster, using the following format: 
    https://[***NIFI-NAME***].[***NAMESPACE***].svc.cluster.local:[***PORT***]/[***BASEPATH***]

    Replace [***NIFI-NAME***], [***NAMESPACE***], [***PORT***], and [***BASEPATH***] with the actual values for the receiving cluster.

    SSL Context Service

    Select DefaultNodeSSLContextService.

Publish the updated drafts to the Catalog and deploy them, or start a test session. Send a FlowFile through the InvokeHTTP processor and verify that the ListenHTTP processor on the receiving cluster receives the request.