On Sat, Feb 18, 2017 at 7:11 AM, Artom Lifshitz <alifs...@redhat.com> wrote: > In reply to Michael: > I hadn't even thought of the security implication. That's a very good > point, there's no way to persist admin_pass in securely. We'll have to > read it at some point, so no amount of encryption will change > anything. We can argue that since we already store admin_pass on the > config drive, storing it in the database as well is OK (it's probably > immediately changed anyways), but there's a difference between having > it in a file on a single compute node, and in the database accessible > by the entire deployment.
Honestly I don't think a policy of "admin password is only available on first boot (initial config drive)" is a bad one. Any workflow that does not change that password immediately is broken security-wise, and I see no reason for us to enable that sort of workflow to get worse by extending the availability of that initial password. We do not break existing users by ignoring the admin password on subsequent config drive images. Of course I can always be misunderestimating the "innovation" of users making use of config drive in ways that none of us have imagined. dt -- Dean Troyer dtro...@gmail.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
