Excerpts from Dean Troyer's message of 2017-02-18 08:21:29 -0600: > 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. >
I'm certain there are people who do not change it immediately, and likely assert it at every boot because that's just the way it has always worked. > 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. > Your API now is that it's in the config drive every time the box boots. You break users by changing that. Let's follow the lead of the Linux kernel and not break userspace. __________________________________________________________________________ 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
