[openstack-dev] [Manila] Share allow/deny by shared secret
ben at swartzlander.org
Mon Oct 26 21:39:35 UTC 2015
On 10/21/2015 06:36 AM, John Spray wrote:
> (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
> 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.
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: OpenStack-dev-request at lists.openstack.org?subject:unsubscribe
More information about the OpenStack-dev