Manila/design/manila-auth-access-keys
Blueprint: https://blueprints.launchpad.net/manila/+spec/auth-access-keys
Summary: Manila share authentication types are currently IP, user, cert. All of these rely on using an external authority to manage identities. For storage systems which have an identity/authorisation system built in, it is proposed to add a mechanism for these systems to feed back shared secrets via the Manila API.
Some storage systems might not use an external authority for their authentication. Ceph is one of these. For the Ceph native driver, clients are authenticated using Ceph's built-in authentication/authorization system. Rather than being an external authority, the storage system and the authentication system are on and the same. To provide users with a single point of contact for handling their shares, and avoid the need for users to install and use native ceph libraries to manage user IDs, it is desirable to expose enough information in the Manila API that users can set up their share and a user ID, and mount the filesystem, without having to do any out-of-band communication with Manila.
The traditional approach is:
- <generate an identity like a cert or IP to a guest instance, for example generate a cert alice.crt>
- Instruct Manila to allow share access to alice.crt
- Go put alice.crt on the guest instance that wants to access the share
The optional new pattern for use with Ceph is:
- Instruct Manila to allow share access to some particular identity ("alice")
- Look up the generated access key for alice in the Manila API
- Go put that generated access key on the guest instance that wants to access the share
The benefit of the second approach is that it avoids the need for client applications to know how to talk to the storage system out of band in order to configure an identity and learn their access key. In some systems (like Ceph), talking to the storage system out of band requires native client libraries installed, and also requires that the client application already have an authentication key with sufficient capabilities to create themselves a new identity. To get the benefit of an abstraction like Manila, it is very desirable to avoid imposing this kind of burden on client applications.
Caveats:
- This is optional -- only drivers that care about returning a key should return something, in all other cases the access_key field will be None
- The key is small -- a ceph key looks like this "AQCMIGBWa3kHKxAANWwCjrpfqdPuNJ/as2MfnQ==". This field is not for big things like X509 certificates.
- Drivers are responsible for security: for example, if a tenant asks for access using an ID that's already in use by another tenant/project, the first tenant/project's key should not be exposed to the second tenant/project
