[
https://issues.apache.org/jira/browse/NIFI-13414?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
David Handermann updated NIFI-13414:
------------------------------------
Description:
NiFi and NiFi Registry have supported several strategies for encrypting and
decrypting application properties located in {{nifi.properties}} apart from
protection of sensitive values in the flow configuration. The initial
implementation supported property encryption using AES-GCM with the key located
in {{bootstrap.conf}}. Subsequent implementations provided integration with
external secret management services. Supporting each of these implementations
requires a large number of third-party libraries, and does not provide a public
method for extensible implementation. Issues with both the security and
maintainability of these existing approaches necessitates their deprecation and
removal from the current main branch.
The local AES-GCM implementation does not provide sufficient security from a
holistic perspective of the installation. Although values in
{{nifi.properties}} can be encrypted, the encryption key must be stored in
plaintext in {{bootstrap.conf}}, and both of these files are located in the
{{conf}} directory. Anyone with access to read the filesystem as the operating
system user can put these configurations together to read the values in
{{nifi.properties}}.
The service-based implementations provide externalization using property value
references or encrypted values that require interaction with the service for
reading. This approach is beneficial, but it requires maintaining separate
implementations for each service provider, and it also requires configuring
access credentials in supplementary bootstrap configuration files. These
service-based implementations have large dependency trees, the contents of each
is stored in the {{properties}} directory under the {{lib}} directory.
Incorporating copies of service provider libraries for all supported
implementations adds significant weight to the standard distribution, and makes
it more difficult to maintain, given the lack of dependency isolation.
The existing {{nifi-property-protection-api}} and provided implementations do
not support a maintainable pattern for application property security. The
{{nifi-toolkit-encrypt-config}} module also contains a significant amount of
code required to run out-of-band for encrypting application properties. The
{{encrypt-config}} command is packaged apart from the standard NiFi
distribution, making it less useful for common deployment scenarios.
Taking these issues together, existing property protection modules for
{{nifi.properties}} should be removed from the main branch. This will provide a
streamlined distribution in the short term, and also provide a better
foundation for considerating more robust approaches that are not subject to the
same types of security concerns.
was:
NiFi and NiFi Registry have supported several strategies for encrypting and
decrypting application properties located in {{nifi.properties}} apart from
protection of sensitive values in the flow configuration. The initial
implementation supported property encryption using AES-GCM with key located in
{{bootstrap.conf}}. Subsequent implementations provided integration with
external secret management services. Supporting each of these implementations
requires a large number of third-party libraries, and does not provide a public
method for extensible implementation. Issues with both the security and
maintainability of these existing approaches necessitates their deprecation and
removal from the current main branch.
The local AES-GCM implementation does not provide sufficient security from a
holistic perspective of the installation. Although values in
{{nifi.properties}} can be encrypted, the encryption key must be stored in
plaintext in {{bootstrap.conf}}, and both of these files are located in the
{{conf}} directory. Anyone with access to read the filesystem as the operating
system user can put these configurations together to read the values in
{{nifi.properties}}.
The service-based implementations provide externalization using property value
references or encrypted values that require interaction with the service for
reading. This approach is beneficial, but it maintaining separate
implementations for each service provider, and it also requires configuring
access credentials in supplementary bootstrap configuration files. These
service-based implementations have large dependency trees, the contents of each
is stored in the {{properties}} directory under the {{lib}} directory.
Incorporating copies of service provider libraries for all supported
implementations adds significant weight to the standard distribution, and makes
it more difficult to maintain, given the lack of dependency isolation.
The existing {{nifi-property-protection-api}} and provided implementations do
not support a maintainable pattern for integration application property
security. The {{nifi-toolkit-encrypt-config}} module also contains a
significant amount of code required to run out-of-band for encrypting
application properties. The {{encrypt-config}} command is packaged apart from
the standard NiFi distribution, making it less useful for common deployment
scenarios.
Taking these issues together, existing property protection modules for
{{nifi.properties}} should be removed from the main branch. This will provide a
streamlined distribution in the short term, and also provide a better
foundation for consideration more robust approaches that are not subject to the
same types of security concerns.
> Remove Property Protection Modules and Encrypt Config Tools
> -----------------------------------------------------------
>
> Key: NIFI-13414
> URL: https://issues.apache.org/jira/browse/NIFI-13414
> Project: Apache NiFi
> Issue Type: Improvement
> Reporter: David Handermann
> Assignee: David Handermann
> Priority: Major
>
> NiFi and NiFi Registry have supported several strategies for encrypting and
> decrypting application properties located in {{nifi.properties}} apart from
> protection of sensitive values in the flow configuration. The initial
> implementation supported property encryption using AES-GCM with the key
> located in {{bootstrap.conf}}. Subsequent implementations provided
> integration with external secret management services. Supporting each of
> these implementations requires a large number of third-party libraries, and
> does not provide a public method for extensible implementation. Issues with
> both the security and maintainability of these existing approaches
> necessitates their deprecation and removal from the current main branch.
> The local AES-GCM implementation does not provide sufficient security from a
> holistic perspective of the installation. Although values in
> {{nifi.properties}} can be encrypted, the encryption key must be stored in
> plaintext in {{bootstrap.conf}}, and both of these files are located in the
> {{conf}} directory. Anyone with access to read the filesystem as the
> operating system user can put these configurations together to read the
> values in {{nifi.properties}}.
> The service-based implementations provide externalization using property
> value references or encrypted values that require interaction with the
> service for reading. This approach is beneficial, but it requires maintaining
> separate implementations for each service provider, and it also requires
> configuring access credentials in supplementary bootstrap configuration
> files. These service-based implementations have large dependency trees, the
> contents of each is stored in the {{properties}} directory under the {{lib}}
> directory. Incorporating copies of service provider libraries for all
> supported implementations adds significant weight to the standard
> distribution, and makes it more difficult to maintain, given the lack of
> dependency isolation.
> The existing {{nifi-property-protection-api}} and provided implementations do
> not support a maintainable pattern for application property security. The
> {{nifi-toolkit-encrypt-config}} module also contains a significant amount of
> code required to run out-of-band for encrypting application properties. The
> {{encrypt-config}} command is packaged apart from the standard NiFi
> distribution, making it less useful for common deployment scenarios.
> Taking these issues together, existing property protection modules for
> {{nifi.properties}} should be removed from the main branch. This will provide
> a streamlined distribution in the short term, and also provide a better
> foundation for considerating more robust approaches that are not subject to
> the same types of security concerns.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
