[keystone][heat] security_compliance options and auto-created users
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/secur... [1] https://opendev.org/openstack/heat/src/branch/master/heat/common/password_ge... Cheers, - Pavlo -- Dr. Pavlo Shchelokovskyy Principal Software Engineer Mirantis Inc www.mirantis.com
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/secur... [1] https://opendev.org/openstack/heat/src/branch/master/heat/common/password_ge...
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... 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
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/secur... [1] https://opendev.org/openstack/heat/src/branch/master/heat/common/password_ge...
Cheers, - Pavlo -- Dr. Pavlo Shchelokovskyy Principal Software Engineer Mirantis Inc www.mirantis.com <http://www.mirantis.com>
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@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/secur...
[1]
https://opendev.org/openstack/heat/src/branch/master/heat/common/password_ge...
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
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@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@redhat.com> wrote:
Hi all,
I am currently looking at options defined in [security_compliance] section of keystone.conf [0] and trying to understand how enabling
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
On 16/04/19 6:38 AM, Pavlo Shchelokovskyy wrote: those 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
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
- lockout failure options (lockout_failure_attempts, lockout_duration)
Sounds like a DoS waiting to happen if we don't override.
- password expiry options
poses a problem for deferred auth, but can be overridden by user
(password_expires_days, unique_last_password_count, minimum_password_age) - 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/secur...
[1]
https://opendev.org/openstack/heat/src/branch/master/heat/common/password_ge...
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
participants (4)
-
Colleen Murphy
-
Morgan Fainberg
-
Pavlo Shchelokovskyy
-
Zane Bitter