Bug 1556946 - Suboptimal wait_condition_handle password generator
Summary: Suboptimal wait_condition_handle password generator
Keywords:
Status: CLOSED ERRATA
Alias: None
Product: Red Hat OpenStack
Classification: Red Hat
Component: openstack-heat
Version: 10.0 (Newton)
Hardware: All
OS: All
high
high
Target Milestone: z9
: 10.0 (Newton)
Assignee: Zane Bitter
QA Contact: Ronnie Rasouli
URL:
Whiteboard:
Depends On:
Blocks: 1566607 1566611 1566612
TreeView+ depends on / blocked
 
Reported: 2018-03-15 15:21 UTC by Alex Stupnikov
Modified: 2018-09-17 16:58 UTC (History)
10 users (show)

Fixed In Version: openstack-heat-7.0.6-4.el7ost
Doc Type: Bug Fix
Doc Text:
Previously, Heat resources such as 'WaitConditionHandle' generated passwords in the format of 32 hexadecimal digits. These passwords did not pass regular expression password validation standards. With this update, Heat resources generate passwords as random 32 characture strings that contain at least one uppercase letter, one lowercase letter, one digit, and one of the following characters: '!@#%^&*'. The new passwords pass any regular expression validation standards.
Clone Of:
: 1566607 (view as bug list)
Environment:
Last Closed: 2018-09-17 16:57:52 UTC
Target Upstream Version:


Attachments (Terms of Use)


Links
System ID Priority Status Summary Last Updated
Launchpad 1444429 None None None 2018-03-15 15:21:43 UTC
OpenStack gerrit 554745 None None None 2018-03-21 19:57:54 UTC
OpenStack gerrit 555017 None None None 2018-03-21 19:57:22 UTC
Red Hat Product Errata RHBA-2018:2716 None None None 2018-09-17 16:58:43 UTC

Description Alex Stupnikov 2018-03-15 15:21:43 UTC
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

Comment 1 Zane Bitter 2018-03-19 17:17:04 UTC
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.

Comment 2 Zane Bitter 2018-03-22 14:01:58 UTC
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,}$"

Comment 14 Alex McLeod 2018-09-03 08:03:05 UTC
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

Comment 15 Alex Stupnikov 2018-09-03 08:43:07 UTC
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.

Comment 16 Zane Bitter 2018-09-04 14:51:11 UTC
Yes, it's the same bug and same patches, so we can use the same doc text.

Comment 20 errata-xmlrpc 2018-09-17 16:57:52 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.

https://access.redhat.com/errata/RHBA-2018:2716


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