[ 
https://issues.apache.org/jira/browse/GUACAMOLE-1244?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17255408#comment-17255408
 ] 

Mike Jumper commented on GUACAMOLE-1244:
----------------------------------------

I encountered a case recently where the strict internal security requirements 
of a large company required database passwords to _never_ be stored on disk, to 
be automatically rotated regularly, and to only be retrievable from a key vault.

The above use case seems reasonable to me so long as either of the following 
are true:

* There are no secrets required to access the key vault (access is implicitly 
authorized through the identity of the server).
* There are locally-stored secrets required to access the key vault, but those 
secrets can be readily revoked in the event of a compromised server.

In the case where secrets are simply encrypted and the secret for decryption 
must also be stored somewhere locally, I agree with our past analysis that the 
use case is contrived (you end up with turtles all the way down until you reach 
an unencrypted secret and you're ultimately no better off). *BUT*, there are 
legitimate cases that align with vault support so long as the design of the 
vault provides greater security and control.

I have WIP changes to the (also WIP) vault support which allow arbitrary 
Guacamole properties to be retrieved from the vault rather than stored locally. 
We could expand the scope of that and consider this JIRA issue a duplicate.

> Provide secure way to add MySQL password in guacamole configuration file
> ------------------------------------------------------------------------
>
>                 Key: GUACAMOLE-1244
>                 URL: https://issues.apache.org/jira/browse/GUACAMOLE-1244
>             Project: Guacamole
>          Issue Type: Improvement
>    Affects Versions: 1.2.0
>            Reporter: leo las
>            Priority: Minor
>
> Provide secure way to add MySQL password in guacamole configuration file



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

Reply via email to