Open Stack

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