<div dir="ltr">Hi all,<div><br></div><div>to follow up on this, I created the following issues:</div><div>Heat story <a href="https://storyboard.openstack.org/#!/story/2005210">https://storyboard.openstack.org/#!/story/2005210</a> , first patch is up <a href="https://review.opendev.org/#/c/656884/">https://review.opendev.org/#/c/656884/</a></div><div>Keystone bugs <a href="https://bugs.launchpad.net/keystone/+bug/1827431">https://bugs.launchpad.net/keystone/+bug/1827431</a> <a href="https://bugs.launchpad.net/keystone/+bug/1827435">https://bugs.launchpad.net/keystone/+bug/1827435</a></div><div><br></div><div>I'll work on patches to Keystone next, please review / comment on bugs/stories/patches :-)</div><div><br></div><div>Cheers,</div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Wed, Apr 17, 2019 at 9:42 AM Zane Bitter <<a href="mailto:zbitter@redhat.com">zbitter@redhat.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">On 16/04/19 6:38 AM, Pavlo Shchelokovskyy wrote:<br>
> Hi all,<br>
> <br>
> I am currently looking at options defined in [security_compliance] <br>
> section of keystone.conf [0] and trying to understand how enabling those <br>
> security features may affect other services.<br>
> <br>
> The first thing I see is that any project that auto-creates some <br>
> temporary users may be affected.<br>
> Of the top of my head I can recall only Heat and Tempest doing this.<br>
> For Tempest situation is easier as a) tempest can use static credentials <br>
> instead of dynamic ones so it is possible to craft appropriate users <br>
> beforehand and b) those users are relatively short-lived (required for <br>
> limited time).<br>
> In case of Heat though those users are used for deferred auth (like in <br>
> autoscaling) which for long lived stacks can happen at arbitrary time in <br>
> future - which is a problem.<br>
> <br>
> Below is breakdown of options/features possible to set and what problems <br>
> that may pose for Heat and ideas on how to work those around:<br>
> <br>
> - disable_user_account_days_inactive - this may pose a problem for <br>
> deferred auth, and it seems is not possible to override it via user <br>
> "options". IMO there's a need to add a new user option to Keystone to <br>
> ignore this setting for given user, and then use it in Heat to create <br>
> temporary users.<br>
<br>
+1<br>
<br>
> - lockout failure options (lockout_failure_attempts, lockout_duration) - <br>
> can be overridden by user option, but Heat has to set it first. Also the <br>
> question remains how realistically such problem may arise for an <br>
> auto-created internal user and whether Heat should set this option at all<br>
<br>
Sounds like a DoS waiting to happen if we don't override.<br>
<br>
> - password expiry options <br>
> (password_expires_days, unique_last_password_count, minimum_password_age) - <br>
> poses a problem for deferred auth, but can be overridden by user option, <br>
> so Heat should definitely set it IMO for users it creates<br>
<br>
+1<br>
<br>
> - change_password_upon_first_use - poses problem for auto-generated <br>
> users, can be overridden by a user option, but Heat must set it for its <br>
> generated users<br>
<br>
+1<br>
<br>
> - password strength enforcement <br>
> (password_regex, password_regex_description) - now this is an <br>
> interesting one. Currently Heat creates passwords for its temporary <br>
> users with this function [1] falling back to empty password if a <br>
> resource is not generating one for itself. Depending on regex_password <br>
> setting in keystone, it may or may not be enough to pass the password <br>
> strength check.<br>
<br>
This is technically true, although I implemented it so it should pass <br>
all but the most brain-dead of policies. So I feel like doing nothing is <br>
a valid option ;)<br>
<br>
> I've looked around and (as expected) generating a random string which <br>
> satisfies a pre-defined arbitrary regex is quite a non-trivial task, <br>
> couple of existing Python libraries that can do this note that they <br>
> support only a limited subset of full regex spec.<br>
<br>
Yeah. If we're going to do it I think a more achievable way is by making <br>
the current generator's rules (which essentially consist of a length <br>
plus minimum counts of characters from particular classes) configurable <br>
instead of hard-coded. I always assumed that we might eventually do <br>
this, but didn't build it in at the start because the patch needed to be <br>
backported.<br>
<br>
This is still pretty terrible because it's a configuration option the <br>
operator has to set to match keystone's, and in a different format to <br>
boot. Although, TBH a regex isn't a great choice for how to configure it <br>
in keystone either - it's trivial if you want to force the user to <br>
always use the password "password", but if you want to force the user to <br>
e.g. have both uppercase and lowercase characters then you have to do <br>
all kinds of weird lookahead assertions that require a PhD in Python's <br>
specific flavour of regexps.<br>
<br>
As long as we don't try to do something like <br>
<a href="https://review.openstack.org/436324" rel="noreferrer" target="_blank">https://review.openstack.org/436324</a><br>
<br>
Note that Heat has it's own requirements too - one that I discovered is <br>
that the passwords can't contain '$' because of reasons.<br>
<br>
> So it seems that a most simple solution would be to add yet another user <br>
> option to Keystone to ignore password strength enforcement for this <br>
> given user, and amend Heat to set this option as well for internal users <br>
> it creates.<br>
<br>
That also works.<br>
<br>
> We in Heat may also think as to whether it would have any benefit to <br>
> also set the 'lock_password' user option for the auto-created users <br>
> which will prohibit such users to change their passwords via API themselves.<br>
<br>
I can't think of any real benefit - or for that matter any real harm. <br>
Presumably Heat itself would still be able to change the account's <br>
password later, so it wouldn't stop us from implementing some sort of <br>
rotation thing in the future.<br>
<br>
> I'd very like to hear opinion from Keystone community as most solutions <br>
> I named are 'add new user option to Keystone' :-)<br>
> <br>
> [0] <br>
> <a href="https://opendev.org/openstack/keystone/src/branch/master/keystone/conf/security_compliance.py" rel="noreferrer" target="_blank">https://opendev.org/openstack/keystone/src/branch/master/keystone/conf/security_compliance.py</a><br>
> [1] <br>
> <a href="https://opendev.org/openstack/heat/src/branch/master/heat/common/password_gen.py#L112" rel="noreferrer" target="_blank">https://opendev.org/openstack/heat/src/branch/master/heat/common/password_gen.py#L112</a><br>
> <br>
> Cheers,<br>
> - Pavlo<br>
> -- <br>
> Dr. Pavlo Shchelokovskyy<br>
> Principal Software Engineer<br>
> Mirantis Inc<br>
> <a href="http://www.mirantis.com" rel="noreferrer" target="_blank">www.mirantis.com</a> <<a href="http://www.mirantis.com" rel="noreferrer" target="_blank">http://www.mirantis.com</a>><br>
<br>
<br>
</blockquote></div><br clear="all"><div><br></div>-- <br><div dir="ltr" class="gmail_signature"><div dir="ltr"><div><div dir="ltr"><div><div dir="ltr">Dr. Pavlo Shchelokovskyy<div>Principal Software Engineer</div><div>Mirantis Inc</div><div><a href="http://www.mirantis.com" target="_blank">www.mirantis.com</a></div></div></div></div></div></div></div>