Bug 1566612 - Suboptimal wait_condition_handle password generator
Summary: Suboptimal wait_condition_handle password generator
Alias: None
Product: Red Hat OpenStack
Classification: Red Hat
Component: openstack-heat
Version: 13.0 (Queens)
Hardware: All
OS: All
Target Milestone: beta
: 13.0 (Queens)
Assignee: Zane Bitter
QA Contact: Ronnie Rasouli
Depends On: 1556946 1566607 1566611
TreeView+ depends on / blocked
Reported: 2018-04-12 15:30 UTC by Zane Bitter
Modified: 2018-06-27 13:51 UTC (History)
10 users (show)

Fixed In Version: openstack-heat-10.0.1-0.20180404165313.825731d.el7ost
Doc Type: If docs needed, set a value
Doc Text:
Clone Of: 1566611
Last Closed: 2018-06-27 13:50:58 UTC
Target Upstream Version:

Attachments (Terms of Use)

System ID Private Priority Status Summary Last Updated
Launchpad 1444429 0 None None None 2018-04-12 15:30:26 UTC
OpenStack gerrit 555860 0 None stable/queens: MERGED heat: Generate user passwords with special characters (I7702d6ab550e4f1f53c4cea9f67ed0402afbd66d) 2018-04-16 13:03:45 UTC
Red Hat Product Errata RHEA-2018:2086 0 None None None 2018-06-27 13:51:40 UTC

Description Zane Bitter 2018-04-12 15:30:26 UTC
+++ This bug was initially created as a clone of Bug #1566611 +++

+++ This bug was initially created as a clone of Bug #1566607 +++

+++ This bug was initially created as a clone of Bug #1556946 +++

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
  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

--- Additional comment from Zane Bitter on 2018-03-19 13:17:04 EDT ---

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.

--- Additional comment from Zane Bitter on 2018-03-22 10:01:58 EDT ---

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,}$"

--- Additional comment from Zane Bitter on 2018-04-12 11:27:24 EDT ---

Patch has been backported upstream and is awaiting upstream review.

Comment 2 Zane Bitter 2018-04-12 15:31:47 UTC
Patch is merged in upstream stable/queens branch.

Comment 6 Ronnie Rasouli 2018-05-03 08:01:38 UTC
I was able to verify with wait condition and keystone regex compliance policy.

password_regex = ^(?=.*\d)(?=.*[a-zA-Z]).{7,}$

Comment 7 Zane Bitter 2018-05-29 20:57:27 UTC
(In reply to Ronnie Rasouli from comment #6)
> I was able to verify with wait condition and keystone regex compliance
> policy.
> password_regex = ^(?=.*\d)(?=.*[a-zA-Z]).{7,}$

That policy only checks that the password has at least one letter and one digit (which ~all UUIDs do anyway, so it would have passed before the fix too).

A more representative test might be something like:

password_regex = ^(?=.*\d)(?=.*[a-z])(?=.*[A-Z])(?=.*[!@#$%^&*]).{7,}$

Comment 9 errata-xmlrpc 2018-06-27 13:50:58 UTC
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.


Note You need to log in before you can comment on or make changes to this bug.