Open Stack

On Tue, Oct 6, 2015 at 11:59 AM, Deepak Shetty <dpkshetty at gmail.com> wrote:
>>
>> Currently, as you say, a share is accessible to anyone who knows the
>> auth key (created a the time the share is created).
>>
>> For adding the allow/deny path, I'd simply create and remove new ceph
>> keys for each entity being allowed/denied.
>
>
> Ok, but how does that map to the existing Manila access types (IP, User,
> Cert) ?

None of the above :-)

Compared with certs, the difference with Ceph is that ceph is issuing
credentials, rather than authorizing existing credentials[1]. So
rather than the tenant saying "Here's a certificate that Alice has
generated and will use to access the filesystem, please authorize it",
the tenant would say "Please authorize someone called Bob to access
the share, and let me know the key he should use to prove he is Bob".

As far as I can tell, we can't currently expose that in Manila: the
missing piece is a way to tag that generated key onto a
ShareInstanceAccessMapping, so that somebody with the right to read
from the Manila API can go read Bob's key, and give it to Bob so that
he can mount the filesystem.

That's why the first-cut compromise is to create a single auth
identity for accessing the share, and expose the key as part of the
share's export location.  It's then the user application's job to
share out that key to whatever hosts need to access it.  The lack of
Manila-mediated 'allow' is annoying but not intrinsically insecure.
The security problem with this approach is that we're not providing a
way to revoke/rotate the key without destroying the share.

So anyway.  This might be a good topic for a conversation at the
summit (or catch me up on the list if it's already been discussed in
depth) -- should drivers be allowed to publish generated
authentication tokens as part of the API for allowing access to a
share?

John


1. Aside: We *could* do a certificate-like model if it was assumed
that the Manila API consumer knew how to go and talk to Ceph out of
band to generate their auth identity.  That way, they could go and
create their auth identity in Ceph, and then ask Manila to grant that
identity access to the share.  However, it would be pointless, because
in ceph, anyone who can create an identity can also set the
capabilities of it (i.e. if they can talk directly to ceph, they don't
need Manila's permission to access the share).