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