Hiding secrets in the log is something we decided to do, so that's a
straight bug - please raise it and we can look at fixing it.
As far as plain text passwords in the database, there has not been a
strong, well formed argument for doing it some other way. You could put
some shared secret in cinder.conf for all c-vol nodes maybe? The threat
analysis doesn't really work though - if you've got DB access then you can
arrange for any user to have any permissions to do anything, so the fact
that the secret is there is only useful if a) you only have read access to
the db and b) you have free access to the undercloud network. If you have
free access to the undercloud network then there are loads of attacks
(injecting into rabbit being a possibility). Basically, it is far enough
down the security issue risk list that it hasn't been worth the complexity
of solving.
On 16 April 2015 at 15:54, Yogesh Prasad <yogesh.pra...@cloudbyte.com>
wrote:
> Hi,
>
> I am wondering why screen-c-vol.log is displaying the CHAP secret.
>
> Logs:
>
> 2015-04-16 16:04:23.288 7306 DEBUG oslo_concurrency.processutils
> [req-23c699df-7b21-48d2-ba14-d8ed06642050 ce8dccba9ccf48fb956060b3e54187a2
> 4ad219788df049e0b131e17f603d5faa - - -] CMD "sudo cinder-rootwrap
> /etc/cinder/rootwrap.conf iscsiadm -m node -T
> iqn.2015-04.acc1.tsm1:acc171fe6fc15fcc4bd4a841594b7876e3df -p
> 192.10.44.48:3260 --op update -n* node.session.auth.password -v ***"
> returned:* 0 in 0.088s execute
> /usr/local/lib/python2.7/dist-packages/oslo_concurrency/processutils.py:225
>
> Above log hides the secret.
>
> 2015-04-16 16:04:23.290 7306 DEBUG cinder.brick.initiator.connector
> [req-23c699df-7b21-48d2-ba14-d8ed06642050 ce8dccba9ccf48fb956060b3e54187a2
> 4ad219788df049e0b131e17f603d5faa - - -] *iscsiadm ('--op', 'update',
> '-n', 'node.session.auth.password', '-v', u'fakeauthgroupchapsecret')*:
> stdout= stderr= _run_iscsiadm
> /opt/stack/cinder/cinder/brick/initiator/connector.py:455
>
> However, this one does not hide the secret.
>
> In addition, i find that the CHAP credentials are stored as plain string
> the database table (volumes).
>
> I guess these are security risks in the current implementation. Any
> comments ?
>
>
> Regards,
> Yogesh
> *CloudByte Inc.* <http://www.cloudbyte.com/>
>
> __________________________________________________________________________
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>
--
Duncan Thomas
__________________________________________________________________________
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
