add support for security_compliance in keystone config

Bug #1776688 reported by Ashley Lai
18
This bug affects 3 people
Affects Status Importance Assigned to Milestone
OpenStack Keystone Charm
Fix Released
Wishlist
Alex Kavanagh

Bug Description

This bug is a request to add a charm option in keystone to be able to add Security Compliance Options in the keystone.conf file.

Upstream documentation reference:

https://docs.openstack.org/keystone/pike/admin/identity-security-compliance.html

Tags: atos sts
Revision history for this message
James Page (james-page) wrote :

Worth noting that these options only apply to SQL backend domains; with LDAP backed domains its assumed that LDAP will provide these policy features, not keystone.

Options are enabled globally for all SQL backed domains, including the service domain for nova/cinder/glance/keystone accounts so its important to consider implications of this change; do the generated passwords for service accounts meet the requirements for the password complexity? how do we reset a service account password in the event that someone manages to DOS the account (because all backend services would be locked out in this case).

An action to reset a password for a service account would be an obvious choice.

Either way this is more that 'just add some config options' as it has wider implications for deployments so I'd like to see a spec drafted and reviewed before we embark on implementing this new feature.

Changed in charm-keystone:
status: New → Triaged
importance: Undecided → Wishlist
Revision history for this message
James Page (james-page) wrote :

We may also be able to override the policy defaults for service account users; either way needs careful consideration.

description: updated
Revision history for this message
James Page (james-page) wrote :

In order to enable this feature safely we'll need ensure that its not possible to lockout service accounts or force password changes otherwise it's possible to realise the DOS attack details in #1.

This is possible but will require that service accounts are setup with the correct options/updated on upgrade to allow application of security compliance constraints to end-user accounts.

Boggy (kowalczykb)
tags: added: atos
tags: added: sts
Changed in charm-keystone:
assignee: nobody → Alex Kavanagh (ajkavanagh)
status: Triaged → In Progress
Revision history for this message
OpenStack Infra (hudson-openstack) wrote : Fix merged to charm-keystone (master)

Reviewed: https://review.opendev.org/702684
Committed: https://git.openstack.org/cgit/openstack/charm-keystone/commit/?id=e83cb05bf86ab797c83964e4287b5879297ecda0
Submitter: Zuul
Branch: master

commit e83cb05bf86ab797c83964e4287b5879297ecda0
Author: Alex Kavanagh <email address hidden>
Date: Wed Jan 15 15:15:06 2020 +0000

    Implement Security Compiance option for password

    This feature adds a "password-security-compliance" option to the
    charm to enable setting of keys in the "[security_compliance]" section
    of the keystone.conf file. This section was added in the Newton
    release, and so this feature supports this from the Newton release.

    It also protects the service accounts from two of the PCI-DSS options
    but setting the user options 'ignore_password_expiry' and
    'ignore_change_password_upon_first_use' to True to prevent the cloud
    from being broken.

    Change-Id: If7c54fae73188284bd9b03a53626cdf52158b994
    Closes-Bug: #1776688

Changed in charm-keystone:
status: In Progress → Fix Committed
James Page (james-page)
Changed in charm-keystone:
milestone: none → 20.05
David Ames (thedac)
Changed in charm-keystone:
status: Fix Committed → Fix Released
To post a comment you must log in.
This report contains Public information  
Everyone can see this information.

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.