[keystone][heat] security_compliance options and auto-created users

Pavlo Shchelokovskyy pshchelokovskyy at mirantis.com
Tue Apr 16 10:38:29 UTC 2019


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

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'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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-discuss/attachments/20190416/4beed7e4/attachment.html>


More information about the openstack-discuss mailing list