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" <jsp...@redhat.com> wrote: >On Tue, Oct 6, 2015 at 11:59 AM, Deepak Shetty <dpkshe...@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-requ...@lists.openstack.org?subject:unsubscribe >http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev __________________________________________________________________________ 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
