Open Stack

Hi all,

to follow up on this, I created the following issues:
Heat story https://storyboard.openstack.org/#!/story/2005210 , first patch
is up https://review.opendev.org/#/c/656884/
Keystone bugs https://bugs.launchpad.net/keystone/+bug/1827431
https://bugs.launchpad.net/keystone/+bug/1827435

I'll work on patches to Keystone next, please review / comment on
bugs/stories/patches :-)

Cheers,

On Wed, Apr 17, 2019 at 9:42 AM Zane Bitter <zbitter at redhat.com> wrote:

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

-- 
Dr. Pavlo Shchelokovskyy
Principal Software Engineer
Mirantis Inc
www.mirantis.com
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-discuss/attachments/20190502/62965958/attachment-0001.html>