[ClusterLabs] Antw: Re: Encrypted passwords for Resource Agent Scripts
Ulrich Windl
Ulrich.Windl at rz.uni-regensburg.de
Mon Sep 24 08:27:02 EDT 2018
>>> Klaus Wenninger <kwenning at redhat.com> schrieb am 24.09.2018 um 14:20 in
Nachricht <035b8680-43d0-93b3-ad0a-4ae4b46e48f4 at redhat.com>:
> On 09/21/2018 10:32 PM, Ken Gaillot wrote:
>> On Fri, 2018-09-21 at 19:01 +0530, Dileep V Nair wrote:
>>> Hi,
>>>
>>> I have written heartbeat resource agent scripts for Oracle and
>>> Sybase. Both the scripts take user passwords as parameters. Is there
>>> a way to do some encryption for the passwords so that the plain text
>>> passwords are not visible from the primitive also.
>> One option is to put the password in a (plaintext) file and take the
>> file name as a resource parameter.
>>
>> There's also a (sadly undocumented) optional feature in pacemaker
>> called CIB secrets. If pacemaker is built with ./configure --with-
>> cibsecrets, you can put files under
>> /var/lib/pacemaker/lrm/secrets/<RESOURCE-NAME>/ with the secrets, and
>> they will be loaded from there rather than the CIB. I'm not familiar
>> enough to give any more detail than that. I believe they're enabled in
>> the SUSE packages, so maybe SUSE has some documentation.
>>
>> The topic has been discussed in the past without a better solution
>> being apparent. It would theoretically be possible to require a human-
>> entered password at boot for some sort of password manager daemon to
>> decrypt an encrypted file with sensitive parameters, and have the RA
>> query the daemon for the password as needed. However the daemon becomes
>> a single point of failure (though it could perhaps be managed by the
>> cluster), and the daemon needs to allow root (i.e. the RA) to get any
>> password at will (otherwise, requiring the RA to authenticate itself to
>> the daemon would just reintroduce the problem).
>>
> Remember some time ago we had a discussion on the list
> about introduction of a key-value-store living alongside cib.
Hi!
Sorry for joining this thread late, but I think any software that needs a cleartext password for automated commends in inherently broken, because if you have to specify the password on the command line or in environment, the password is no longer private! If the software permits reading the password from a file, it's safe and you don't need such "security" mechanisms.
> Don't remember if this use-case was discussed then but
> at least it would be a valid one.
> Anyway more or less the daemon Ken was talking about
> just with a broader variety of use-cases.
> Couldn't the issue with opening access to root in general
> be handled via SELinux security contexts?
Regards,
Ulrich
>
>>>
>>> Thanks & Regards
>>>
>>> Dileep Nair
>>> Squad Lead - SAP Base
>>> IBM Services for Managed Applications
>>> +91 98450 22258 Mobile
>>> dilenair at in.ibm.com
>>>
>>> IBM Services
>
> _______________________________________________
> Users mailing list: Users at clusterlabs.org
> https://lists.clusterlabs.org/mailman/listinfo/users
>
> Project Home: http://www.clusterlabs.org
> Getting started: http://www.clusterlabs.org/doc/Cluster_from_Scratch.pdf
> Bugs: http://bugs.clusterlabs.org
More information about the Users
mailing list