Open Stack

On 10/21/2015 06:36 AM, John Spray wrote:
> 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.

This is accurate. Manila presumes the existence of an external 
authentication mechanism which servers can use to identify clients, so 
that Manila's role can be limited to telling the server which clients 
should have access.

> 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.

The problem with the above statement is that you don't define who "I" 
am. The Manila API client is all-powerful when it comes to modifying 
access rules, insofar as a tenant has the power to add/remove any rule 
from any share that that tenant owns. Obviously if  you have access to 
modify the access rules then you have de-facto access to all the shares. 
The purpose of the access-allow/deny APIs is to delegate access to 
shares to identities that exist outside of Manila, such as to IP 
addresses, to users, or to x509 principles. These things need to be 
named somehow so that the file system server, the client, and manila can 
all talk about the same set of identities.

> 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.

I don't see why the driver should be the place where secrets are 
generated. It seems equally valid for the caller of the Manila API to 
generate the secret himself, and to ask Manila to grant access to a 
share to anyone knowing that secret. This would fit the existing model, 
and more importantly, it would allow granting of shares to multiple 
users with different secrets. I don't see in the above proposal how to 
grant access to a share to both Alice and Bob without telling the same 
secret to both Alice and Bob. The problem that creates is that I can't 
revoke access to the share from Alice without also revoking access from 
Bob. Maybe I'm misreading what you wrote above about key revocation, but 
it sounds like you have 1 key per share, and you can revoke access to 
each share individually, but if you have multiple users you cannot 
distinguish between them.

> 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".

I'm not opposed to the idea of modifying the Manila API to make your use 
case possible, but I want to make sure there's not a better way to solve 
the problem first, and I also want to make sure that the we're solving 
the problem in the right way. Supporting multiple users accessing 
multiple shares is an important use case and I'm not clear on how this 
proposal addresses that.

> Cheers,
> John
>
> __________________________________________________________________________
> 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