Open Stack

There has been some work to allow for "defaults" for these overrides at,
for example, the domain level (all users within a domain). Allowing such
defaults based upon ownership would solve the concerns.

On Thu, May 2, 2019 at 3:22 PM Pavlo Shchelokovskyy <
pshchelokovskyy at mirantis.com> wrote:

> 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/f20c4636/attachment.html>