This is an RFE requesting a change in the way CephFS usernames work with Manila's access control process. 

An OpenStack user creates a Manila access rule to authorize a "user" to mount a CephFS subvolume (Manila share). 

To process this request:

• Ceph API first checks if the username exists on the Ceph cluster. If the username exists and it checks if the username was created by the OpenStack user's project. If it wasn't, the authorization fails and an asynchronous message is created via Manila.
• If the username doesn't exist, Ceph creates a client user account with the required ceph "caps" authorizing the new user to the subvolume. While doing this, it also records the OpenStack user's project name as "auth metadata". Doing this allows ceph to identify usernames henceforth

So, users within an OpenStack project can use a username as many times as they want to authorize their subvolumes. However, users from other OpenStack projects cannot use a username claimed by a project user. This is inconvenient; for example, if a user from project ACME requests access to a user called "alice", there can't be an "alice" in any other OpenStack project.

A further problem is that ceph doesn't allow manipulating the auth metadata associated with a username once it creates it. This means that a username created via OpenStack cannot be used by anyone else for usecases outside of OpenStack, even when it stops being used within OpenStack. 

See notes here: https://bugzilla.redhat.com/show_bug.cgi?id=2263529

The suggested resolution is to allow prefixing OpenStack project identity to all Ceph usernames created via Manila.

 

What are the use cases this RFE is solving?

Gives the ability to use a username across Openstack projects. Currently, if a project "A" has created an access rule for a user named "alice" in a cephfs share, and project "B" attempts to create an access rule for a user with the same name, the creation will fail and we will signalize a duplicity of users, even though they do not pertain to the same project.

 

High Level view on how the feature works

?

 

Is this feature driver dependent or driver related?

Yes, this is related to access rules created for shares created under the CephFS protocol.

 

Are there any known limitations? (e.g multi attach + encryption)

?

 

Is a CLI change required, does the openstack cmd support it?

No CLI changes might be required for this.

 

Does this RFE impact / need to be included into the control plane podification?

No.

 

Does this RFE benefit/impact DCN?

No.

 

Does this RFE benefit/impact shift on stack?

?

 

Can this feature be turned on or used in an existing environment?

Probably not, changing tenant-id o include project id prepend is not backwards compatible.

 

Does this feature affect another DFG or product?

Does this feature depend on another RFE?

No

 

How will the feature affect Upgrades?

Should have no effect, must test access rules

 

How will the feature affect performance or scaling?

No effect

 

What are the test cases for this RFE?

Ensuring user from project1 cannot access volumes authorized by user in project2, where usernames are the same, ensuring error log does not leak information.

Test before and after upgrade that user can still use the old access rule (no prepend to username).

 

Are there CI implications?

Test as part of regression suite?

 

Does it have documentation impact and require early planning with the doc team?

Yes.

 

Are there known packaging challenges?

No.

 

Are there any security considerations?

Currently, if we say the user already exists we "leak" the information about the user existing in another project. By fixing this, we will not run into this issue and "leak" this information anymore..

 

How much upstream resistance might there be to this feature?

None.

 

Will this feature require new or different support skills?

No.

 

Will this be required for knowledge transfer to GSS?

Yes. We will need to share with GSS the approach we decided to take and how we avoided the situation with the usernames being duplicated.

 

Will this feature impact existing partners or certification programs?

No.

 

API Deprecation/Compatibility?

No.

 

Are any GUI impact/changes required (Horizon)?

No.