How should I use the SSLContext controller in a multi-tenant cluster?

[#1]

The Background:

I have multitenant clusters. My organization has delivered me a combined truststore and keystore jks file.

I will have users who need to hit various external-to-nifi services using SSL/TLS. It is tempting to create an sslcontext controller service at nifi root and let all my users use this service when they need SSL. One problem with this approach that I see is that if I let all my users use the hosts' certs, (keystore and truststore) they could just use a GetHTTP processor and talk to the nifi rest api with full priveleges (or at least whatever privs the node has)

So to prevent this I figure that I should get my root CA certs into a separate truststore that is not password protected, and only use this.

The question:

Should I create an sslcontext service at the root flow with only a truststore, and ask my users to all use the same controller service? Or should I just notify my users of the path to the truststore and have them create controllers within their process groups as needed, what are the pros and cons of each approach?

[#2 · Accepted solution]

David,

I would recommend you create an SSLContextService at root which only uses the truststore and ask your users to select that controller service when necessary. If they have requirements to connect to external services which require mutual authentication via TLS client certificates, you may have to create additional controller services with limited keystore access and provide those on a per-instance/user basis. If these are globally-accessible external services (aka not organizationally-signed), you could also provide a generic controller service which uses the Java CA truststore (something like $JAVA_HOME/jre/lib/security/cacerts with default password "changeit").