Open Stack

Hi, John.  If you want to discuss this in Tokyo, I suggest you add it to
the etherpad:

https://etherpad.openstack.org/p/manila-mitaka-summit-topics


I look forward to meeting you at the Summit.  It¹d be great to see a demo
of your Ceph driver.

Clinton


On 10/7/15, 6:56 AM, "John Spray" <jspray at redhat.com> wrote:

>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).
>
>__________________________________________________________________________
>OpenStack Development Mailing List (not for usage questions)
>Unsubscribe: OpenStack-dev-request at lists.openstack.org?subject:unsubscribe
>http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev