Re: [keystone][heat] security_compliance options and auto-created users
On Tue, Apr 16, 2019, at 03:38, Pavlo Shchelokovskyy wrote:
> Hi all,
> I am currently looking at options defined in [security_compliance]
> section of keystone.conf  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
> - 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 
> 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
> I'd very like to hear opinion from Keystone community as most solutions
> I named are 'add new user option to Keystone' :-)
> - Pavlo
> Dr. Pavlo Shchelokovskyy
> Principal Software Engineer
> Mirantis Inc
Just in case you hadn't already found it, the documentation for these features is here:
Much less obviously, we document the way to override these features per-user here:
The security compliance feature isn't really meant to be applied to service users, it's for real human users, used for the sake of compliance with PCI-DSS requirements. If your organization requires your deployment to conform to PCI-DSS restrictions, service users should most likely be exempted.
In the case of temporary users, I wasn't aware that heat does that. In this case overriding the security compliance options per-user wouldn't work if the users are being deleted and recreated. The only advice I can think of is to not use this feature if you don't really need it in your organization, or to find a way to ensure heat can re-use a known user for these use cases.
Hope this helps,