[
https://issues.apache.org/jira/browse/NIFI-4881?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16523843#comment-16523843
]
Nathan Gough commented on NIFI-4881:
------------------------------------
For this point:
{quote}When a new definition is received or selected, the application framework
would
{quote}
I think the best option would be to provide a visual alert of some description
to indicate a manual restart is required.
NiFi restarting unexpectedly i.e when NiFi is empty or after a set time period
is confusing for administrators ("Why did NiFi just restart?"). This would be
unfavorable for mission critical systems that typically have planned
outage/maintenance windows. Some NiFi systems may never reach an empty state
once operational and the update would be delayed indefinitely.
However I would acknowledge that if we rely on a manual restart, the update
could still be delayed indefinitely due to laziness/toobusy-itis. Yet, I think
this would be preferred over automatic restarts.
> 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
> Priority: Major
> Labels: security, tls
>
> 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)
