Bug 1566611

Summary:	Suboptimal wait_condition_handle password generator
Product:	Red Hat OpenStack	Reporter:	Zane Bitter <zbitter>
Component:	openstack-heat	Assignee:	Zane Bitter <zbitter>
Status:	CLOSED ERRATA	QA Contact:	Ronnie Rasouli <rrasouli>
Severity:	high	Docs Contact:
Priority:	high
Version:	12.0 (Pike)	CC:	adahms, astupnik, jamsmith, mburns, ramishra, rhel-osp-director-maint, rrasouli, sbaker, shardy, slinaber, srevivo, therve, zbitter
Target Milestone:	z3	Keywords:	Triaged, ZStream
Target Release:	12.0 (Pike)
Hardware:	All
OS:	All
Whiteboard:
Fixed In Version:	openstack-heat-9.0.4-1.el7ost	Doc Type:	Enhancement
Doc Text:	Keystone user passwords generated by Heat resources such as WaitConditionHandle now meet more stringent regular expression-based password complexity requirements. The new passwords are 32-character random strings containing at least one uppercase and one lowercase letter, one digit, and one of the characters '!@#%^&*'. These passwords should pass the standard of virtually any regular expression-based password validation. Previously, generated passwords took the form of 32 hexadecimal digits, and thus never contained uppercase letters or special characters.	Story Points:	---
Clone Of:	1566607
Clones:	1566612 (view as bug list)		Environment:
Last Closed:	2018-08-20 12:44:10 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:	1556946, 1566607
Bug Blocks:	1566612

Description Zane Bitter 2018-04-12 15:29:00 UTC

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

--- 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 1 Zane Bitter 2018-04-24 21:00:35 UTC

Patch is merged in upstream stable/pike branch.

Comment 5 Ronnie Rasouli 2018-07-19 12:27:38 UTC

tested wait condition and keystone regex compliance policy.
password_regex = ^(?=.*\d)(?=.*[a-z])(?=.*[A-Z])(?=.*[!@#$%^&*]).{7,}$
integration tests passed

Comment 12 errata-xmlrpc 2018-08-20 12:44:10 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:2520