Open Stack

Hello,

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

Just in case you hadn't already found it, the documentation for these features is here:

https://docs.openstack.org/keystone/latest/admin/configuration.html#security-compliance-and-pci-dss

Much less obviously, we document the way to override these features per-user here:

https://docs.openstack.org/keystone/latest/admin/resource-options.html

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,

Colleen