Hide Forgot
WaitCondition uses obsolete method to generate the passwords (uuid.uuid4().hex) [1]. As a result, generated passwords don't contain special characters or upper case letters, so it is impossible to validate them against keyston's strong password policies. Steps to reproduce: Enforce strong password policies in keystone. Use Heat templates with WaitConditionHandle. Expected result: Heat templates successfully deployed. Actual result: Heat fails with the following output: resource_type: OS::Heat::WaitConditionHandle physical_resource_id: status: CREATE_FAILED status_reason: | BadRequest: resources.saltmaster_wait_handle: The password does not match the requirements: Password must contain 8 characters and at least one uppercase letter, one lowercase letter, one number and one unique symbol.. (HTTP 400) (Request-ID: req-4e0d89b1-1ad2-420c-86a2-3bdbdf0a3581) PS. I have checked the heat code and it looks like we already implemented password generator [2], [3]. So we basically should just change the password generation methods. [1] https://github.com/openstack/heat/blob/master/heat/engine/resources/openstack/heat/wait_condition_handle.py#L138 [2] https://blueprints.launchpad.net/heat/+spec/random-string-resource [3] https://github.com/openstack/heat/blob/master/heat/engine/resources/openstack/heat/random_string.py
There's a related-but-not-identical bug opened upstream too: https://bugs.launchpad.net/heat/+bug/1666129 There was a patch proposed for that one that involved retrying in a loop until you found a successful password, but the author unfortunately abandoned it after I suggested using the password generator from RandomString just as you did. I agree that that's the right approach, especially now that https://bugs.launchpad.net/heat/+bug/1745931 is fixed. It will involve some refactoring, however, so it remains to be seen how much of a problem that poses for backporting.
I proposed patches upstream. It should be possible to eventually get these backported (the refactoring one includes a security improvement for OS::Heat::RandomString, which makes it a candidate for stable branch backporting even upstream) once they've been reviewed. In the meantime, the workaround posted in the upstream bug is a good one: modifying the Keystone password_regex to allow passwords without special characters if they are long enough: "< your original regex >|^(?=.*?[a-zA-Z])(?=.*?[0-9]).{30,}$"
Hi there, If this bug requires doc text for errata release, please set the 'Doc Type' and provide draft text according to the template in the 'Doc Text' field. The documentation team will review, edit, and approve the text. If this bug does not require doc text, please set the 'requires_doc_text' flag to -. Thanks, Alex
I have copied a doc text from Bug #1566611, but it is up to Zane to decide if this is appropriate text to put into release notes. BR, Alex.
Yes, it's the same bug and same patches, so we can use the same doc text.
Since the problem described in this bug report should be resolved in a recent advisory, it has been closed with a resolution of ERRATA. For information on the advisory, and where to find the updated files, follow the link below. If the solution does not work for you, open a new bug report. https://access.redhat.com/errata/RHBA-2018:2716