Immutable Resources

bug #1823258

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.

Problem Description

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.

Proposed Change

Keystone roles, users, projects, and domains will gain an immutable 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:

  1. Add an immutable resource option to the role model. This will be off by default, always.

  2. Add an opt-in flag --immutable-roles to the keystone-manage bootstrap command which sets the immutable resource option on the default roles (admin, member, reader) to true. The command should also log a warning that this will become default behavior in the future if they do not set it.

  3. Add a keystone-status check to alert operators if they have not made the default roles immutable.

  4. Change the keystone-manage bootstrap behavior to make roles immutable by default and opt-out available with --no-immutable-roles.

Alternatives

  • 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.

Security Impact

This doesn’t have a direct security impact.

Notifications 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.

Performance Impact

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.

Developer Impact

Developers of custom role backends will need to be aware of the new property.

Implementation

Assignee(s)

Primary assignee:

Colleen Murphy (cmurphy)

Work Items

Outlined in Proposed Change.

Dependencies

Requires resource options scaffolding to be implemented for the role driver.

Documentation Impact

This will require an update to the API reference and instructions in the administrator guide for upgrading and managing roles.

References