Hi, (I wanted to put this in an email ahead of Tokyo, where I hope we'll find time to discuss it. This is a follow up to http://osdir.com/ml/openstack-dev/2015-10/msg00381.html)
With the current code, there doesn't appear to be a proper way to expose Ceph's native authentication system via Manila. This is because Ceph generates the shared secret needed to access a share, and Manila doesn't give us a path to expose such a driver-originated secret as part of a ShareInstanceMapping. The NFS-style process that Manila expects is: Caller> I know a credential (IP address, x509 certificate) and I want you to authorize it Driver> OK, I have stored that credential and you can now use it to access the share. The Ceph native process is more like: Caller> I want to access this share Driver> OK, I have generated a credential for you, here it is, you can now use it to access the share The important distinction is where the credential comes from. Manila expects it to come from the caller, Ceph expects to generate it for the caller. To enable us to expose ceph native auth, I propose: * Add a "key" column to the ShareAccessMapping model * Enable drivers to optionally populate this from allow() methods * Expose this to API consumers: right to see a share mapping is the right to see the key. The security model is that the key is a secret, which Manila API users (i.e. administrative functions) are allowed to see, and it is up to them to selectively share the secret with guests. The reason for giving them allow/deny rather than just having a key per share is so that the administrator can selectively revoke keys. The "key" column should be pretty short (255 chars is plenty) -- this isn't meant for storing big things like PKI certificates, it's specifically for shared secrets. I don't know of any other drivers that would use this, but it is a pretty generic concept in itself: "grant access by a shared key that the storage system generates". Cheers, John __________________________________________________________________________ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev