[jira] [Commented] (NIFI-4881) Provide TLS "auto-secure" feature
[
https://issues.apache.org/jira/browse/NIFI-4881?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=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)
[jira] [Commented] (NIFI-4881) Provide TLS "auto-secure" feature
[
https://issues.apache.org/jira/browse/NIFI-4881?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16367636#comment-16367636
]
Andy LoPresto commented on NIFI-4881:
-
This is an opt-in feature, so the automatic updates would only occur on a
system where an administrator has explicitly enabled this feature.
NiFi would not restart and update without a new definition delivery, and the
current definition would be cached locally, so I do not foresee any issues
starting up if connectivity to the remote endpoint is unavailable.
> 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)
[jira] [Commented] (NIFI-4881) Provide TLS "auto-secure" feature
[
https://issues.apache.org/jira/browse/NIFI-4881?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16367423#comment-16367423
]
Michael Moser commented on NIFI-4881:
-
I have just a couple of observations that I wanted to share.
I feel that security definitions should not change in NiFi without an explicit
administrator action. Without that, I could see a definitions change could
cause clients to lose access to NiFi and the administrator would not know why
because in their mind they had changed nothing on the system.
I feel that once security definitions are in place, NiFi should be able to
startup and run properly even when access to an HTTPS endpoint where those
definitions are updated is not available.
> 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)
