Keystone is a critical part of a cloud deployment. Administrators should take special care with configuration changes in keystone to avoid cascading bad changes to the rest of the cloud deployment, but keystone should also be more robust against accidental footgunning.
Keystone is responsible for many resources that are used through out other services in an OpenStack deployment. For example, roles essentially map permissions to a string that can be associated to a user via a role assignment. Many roles are reused across OpenStack and some carry elevated authorization needed to manage the deployment. In some cases, the accidental removal of a role can be catastrophic to the deployment, since the deletion of a role triggers the deletion of all role assignments any user has in any scope for that role. This is particularly relevant to service users, which usually have an admin role assignment, without which they cannot perform basic operations needed for the cloud to be usable. The fix in such a case usually requires modifying database entries by hand, which is a terrible practice in production environments.
Keystone should implement a more robust mechanism that allows operators to lock specific resources, like important roles. A locked resource shouldn’t be deletable until it is unlocked, which adds a layer of protection for deployment critical API resources, especially from accidental mishaps from the command line or rogue/faulty administrator scripts.
Keystone roles, users, projects, and domains will gain an
flag as a resource option. An immutable resource may not be deleted or
altered except to turn off the immutable flag.
For most resources, users will opt into locking these resources by setting the flag. Eventually, the admin role should become immutable by default. However, hardcoding immutability would be extremely backwards incompatible, so we implement this in steps:
immutableresource option to the role model. This will be off by default, always.
Add an opt-in flag
keystone-manage bootstrapcommand which sets the
immutableresource option on the default roles (
true. The command should also log a warning that this will become default behavior in the future if they do not set it.
keystone-statuscheck to alert operators if they have not made the default roles immutable.
keystone-manage bootstrapbehavior to make roles immutable by default and opt-out available with
Make role more like domains, which must be disabled and then deleted. This is not backwards compatible.
Change roles to be soft-deleted. This doesn’t change the fact that role assignments are hard-deleted, but could make it easier to recover since the role ID still resides in the database.
Change horizon to give a visual alert for potentially destructive actions like deleting the admin role. This doesn’t protect against bad scripts.
This doesn’t have a direct security impact.
No notifications will be admitted with this new resource option.
Other End User Impact¶
Administrative users will need to unset the
immutable flag for a role if
they truly want to delete or alter the role. Client changes will be needed to
allow the adminitrator to set a role as immutable or mutable.
Non-administrative end users should see no difference.
Negligable performance impact. Keystone have to determine if resources are locked during writeable operations and act accordingly, which would be considered business-specific logic.
Other Deployer Impact¶
Deployers will be alerted to opt into the new behavior. Detailed upgrade instructions will be made available in the release notes and the command help output.
Developers of custom role backends will need to be aware of the new property.
- Primary assignee:
Colleen Murphy (cmurphy)
Outlined in Proposed Change.
Requires resource options scaffolding to be implemented for the role driver.
This will require an update to the API reference and instructions in the administrator guide for upgrading and managing roles.