Andy LoPresto created NIFI-4881:
-----------------------------------

             Summary: Provide TLS "auto-secure" feature
                 Key: NIFI-4881
                 URL: https://issues.apache.org/jira/browse/NIFI-4881
             Project: Apache NiFi
          Issue Type: New Feature
          Components: Configuration Management, Core Framework
    Affects Versions: 1.5.0
            Reporter: Andy LoPresto
            Assignee: Andy LoPresto


As documented in the Apache NiFi Wiki Feature Roadmap (Security), I have wanted 
to implement for some time a feature where the administrator of a NiFi instance 
does not have to know the intricate details of TLS configuration in order to 
deploy a secure instance. What I propose is the following:
 * The administrator can set the TLS security settings to *high*, *medium*, and 
*low*
 * These settings have accompanying descriptions explaining that "*high* means 
most secure (with lower backwards compatibility", "*medium* tries to strike a 
balance between security and compatibility", and "*low* allows for more 
widespread legacy compatibility with less emphasis on security". 
 * The cipher suite lists and protocol versions for each would be downloaded 
from the [Mozilla TLS 
Observatory|https://wiki.mozilla.org/Security/Server_Side_TLS#Recommended_configurations],
 which publishes updated definitions for each of "modern", "intermediate", and 
"legacy" options at initial startup and at regular intervals. 
 * For deployments in an airgapped or other environment without desired 
connectivity to this service, or where the source is preferred to be controlled 
by an organizational entity, an alternate service endpoint can be configured 
(for proof of concept, this could even be the NiFi instance itself reading a 
file from disk and returning JSON over an HTTP endpoint). 
 * When a new definition is received or selected, the application framework 
would either:
 ** Restart the Jetty server automatically in a pre-configured timeframe
 ** Wait for all queues to empty and then restart
 ** Provide a visual alert (bulletin, etc.) that new definitions were received 
and a manual restart is required
 * This setting could be set in a variety of ways:
 ** Directly in {{nifi.properties}} before the first application launch 
 ** Given as an argument to an enhanced TLS Toolkit (i.e. 
{{./bin/tls-toolkit.sh standalone ... -S high}}) and then the resulting 
{{nifi.properties}} placed in the correct location
 ** Through a UI configuration option (this would need to be restricted to the 
appropriate NiFi permissions and would require a Jetty server restart)
 * The definitions would "grow" with the ecosystem (i.e. as a new vulnerability 
is discovered or a new protocol version/cipher suite is made available, it is 
automatically added/removed from the definition, thus continually improving the 
security stance of the application without requiring active monitoring and 
input from an administrator)



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

Reply via email to