You are viewing a plain text version of this content. The canonical link for it is here.
Posted to issues@nifi.apache.org by "Andy LoPresto (JIRA)" <ji...@apache.org> on 2018/06/12 00:24:00 UTC
[jira] [Comment Edited] (NIFI-5296) Add EL Support with Variable
Registry scope on SSL context service
[ https://issues.apache.org/jira/browse/NIFI-5296?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16508990#comment-16508990 ]
Andy LoPresto edited comment on NIFI-5296 at 6/12/18 12:23 AM:
---------------------------------------------------------------
[~pvillard] can you describe the use case where you feel VR EL support is necessary for these fields? I am guessing you want to be able to specify a keystore and truststore path in the VR and allow an SSLContextService to reference it. I have a couple concerns with this approach:
# It allows any user with variable permissions to see the path to the keystore and truststore. In the current setup, the controller service can be deployed with literal paths by an administrator/trusted user, and the service can be referenced by dependent components without exposing the actual file system paths to a less-trusted user (given the proper absence of permissions on the controller service). Currently, a user who does not have view permission to the {{StandardSSLContextService}} cannot see the explicit path at all, even if they have view permission to the referencing {{InvokeHTTP}} processor (for example). In this new scenario, they would be able to see the explicit path in the Variables window, and see the UUID of the referencing SSLCS (see [https://nifi.apache.org/docs/nifi-docs/html/user-guide.html#unauthorized-referencing-components])
# It allows the keystore and truststore path to change without visibility on the configuration dialog. Given EL evaluation, the processor will evaluate not only VR-specific variables, but also system properties and OS-level environment variables. This means that a malicious or incidental occurrence could change the path used to locate the keystore and truststore without the NiFi user being aware
The original work that introduced the unit tests you reference was done in [NIFI-4274|https://issues.apache.org/jira/browse/NIFI-4274] because of a [Stack Overflow question|https://stackoverflow.com/a/45575232/70465] where the documentation (which said EL was not supported) and the behavior (incorrectly evaluating EL) did not match.
I appreciate the work you put into this PR. If you have a specific use case that really requires this behavior, let's discuss it. If this is just to bring these properties inline with the baseline EL evaluation, I would ask that we do not implement this at this time.
There is some ongoing work/discussion about how to handle the sensitive properties in conjunction with the VR, Registry, flow versioning, setting from external sources, etc. and I believe it requires a cohesive approach with substantial threat modeling to avoid introducing serious issues into NiFi. We have traditionally held to a "secure but severe" policy where some features are absent because of the strict principle that "sensitive properties are always protected/blocked". It may be time to re-evaluate that, but introducing these changes piecemeal is dangerous in my opinion.
was (Author: alopresto):
[~pvillard] can you describe the use case where you feel VR EL support is necessary for these fields? I am guessing you want to be able to specify a keystore and truststore path in the VR and allow an SSLContextService to reference it. I have a couple concerns with this approach:
# It allows any user with variable permissions to see the path to the keystore and truststore. In the current setup, the controller service can be deployed with literal paths by an administrator/trusted user, and the service can be referenced by dependent components without exposing the actual file system paths to a less-trusted user (given the proper absence of permissions on the controller service). Currently, a user who does not have view permission to the {{StandardSSLContextService}} cannot see the explicit path at all, even if they have view permission to the referencing {{InvokeHTTP}} processor (for example). In this new scenario, they would be able to see the explicit path in the Variables window, and see the UUID of the referencing SSLCS (see [https://nifi.apache.org/docs/nifi-docs/html/user-guide.html#unauthorized-referencing-components])
# It allows the keystore and truststore path to change without visibility on the configuration dialog. Given EL evaluation, the processor will evaluate not only VR-specific variables, but also system properties and OS-level environment variables. This means that a malicious or incidental occurrence could change the path used to locate the keystore and truststore without the NiFi user being aware
# The original work that introduced the unit tests you reference was done in [NIFI-4274|https://issues.apache.org/jira/browse/NIFI-4274] because of a [Stack Overflow question|https://stackoverflow.com/a/45575232/70465] where the documentation (which said EL was not supported) and the behavior (incorrectly evaluating EL) did not match.
I appreciate the work you put into this PR. If you have a specific use case that really requires this behavior, let's discuss it. If this is just to bring these properties inline with the baseline EL evaluation, I would ask that we do not implement this at this time.
There is some ongoing work/discussion about how to handle the sensitive properties in conjunction with the VR, Registry, flow versioning, setting from external sources, etc. and I believe it requires a cohesive approach with substantial threat modeling to avoid introducing serious issues into NiFi. We have traditionally held to a "secure but severe" policy where some features are absent because of the strict principle that "sensitive properties are always protected/blocked". It may be time to re-evaluate that, but introducing these changes piecemeal is dangerous in my opinion.
> Add EL Support with Variable Registry scope on SSL context service
> ------------------------------------------------------------------
>
> Key: NIFI-5296
> URL: https://issues.apache.org/jira/browse/NIFI-5296
> Project: Apache NiFi
> Issue Type: Improvement
> Components: Extensions
> Reporter: Pierre Villard
> Assignee: Pierre Villard
> Priority: Major
>
> Add EL support on Truststore and Keystore filename properties with Variable Registry scope.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)