Bug 1556946

Summary: Suboptimal wait_condition_handle password generator
Product: Red Hat OpenStack Reporter: Alex Stupnikov <astupnik>
Component: openstack-heatAssignee: Zane Bitter <zbitter>
Status: CLOSED ERRATA QA Contact: Ronnie Rasouli <rrasouli>
Severity: high Docs Contact:
Priority: high    
Version: 10.0 (Newton)CC: amcleod, astupnik, mburns, ramishra, rhel-osp-director-maint, sbaker, shardy, srevivo, therve, zbitter
Target Milestone: z9Keywords: Triaged, ZStream
Target Release: 10.0 (Newton)   
Hardware: All   
OS: All   
Whiteboard:
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.
Story Points: ---
Clone Of:
: 1566607 (view as bug list) Environment:
Last Closed: 2018-09-17 16:57:52 UTC Type: Bug
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Embargoed:
Bug Depends On:    
Bug Blocks: 1566607, 1566611, 1566612    

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