Comment 11 for bug 1554288

This seems like a security hardening opportunity. We already classify bugs which require access to service management networks or which need admin privileges as security hardening opportunities because we have so many possible avenues of attack against management interfaces (including but not limited to lack of SSL certificate validation, automatically trusting SSH host keys, a completely unsecured message bus) that we wouldn't ever have enough time to track and publish formal advisories for them all in OpenStack's current state. Instead we publish secure deployment recommendations in http://docs.openstack.org/sec/ to cover those sorts of challenges.

I have hopes this situation will change and eventually deployers might expect to be able to distribute OpenStack service backends across untrusted network links, expose management interfaces to the untrusted parties/the Internet without filtering, or have confident levels of privilege and trust separation between various service administrator roles... but getting there is a massive undertaking which should not be encumbered by bottlenecks like vulnerability management teams, embargoes or coordinated disclosures.

So with the above, I'm recommending we switch this bug to public and tag it as a security hardening opportunity consistent with a class D report in our taxonomy ( https://security.openstack.org/vmt-process.html#incident-report-taxonomy ).