On Tue, Oct 27, 2015 at 6:39 AM, Ben Swartzlander <b...@swartzlander.org> wrote:
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.
I think my "I" concept here is the all-powerful (within his own
tenancy) manila API consumer who is taking on the responsibility to
know about the external entities (like guests, groups of guests).
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.
The thing making delegation of access control awkward here is that
Ceph is both the provider of the storage and also the provider of the
authentication: there is no external entity (an IP network, an x509
CA) that we defer to. If the authentication was to an external
system, it would make sense to say that clients should first configure
their identity externally, and then call into Manila to authorize that
identity. When the system of identities is built into the storage
system, having the API consumer call out to create their identity
would leave them talking directly to Ceph, in addition to talking to
Ceph via Manila.
I should point out that it would also be possible to extend the Ceph
interface to allow users to pass in their own generated key. In this
case we could have API consumers generate their own secrets, and pass
them into ceph. So your access id would be something like
"alice/a7df6d76d57f". The Ceph driver would then have to create the
alice identity in ceph if it didn't already exist, and throw an error
if the existing alice identity wasn't already using that particular
shared secret. This isn't ideal from a security POV, because it
relies on Manila API consumers to have a suitable source of
randomness, and it's less than ideal usability because they have to
know the expected size/format of the secret.
The usability part is a big concern for me: there's a huge leap
between "pick an ID and pass it into authorize" and "pick an ID, and
generate a cryptographically secure random number N bytes long,
concatenate it with the ID like so and pass it into authorize".
Either we rely on users to get it right (a bit optimistic) or we have
to give them a library for generating it (which isn't very RESTful).
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
Ah, no -- I think I wasn't clear enough about this part. We wouldn't
have one key per share. You can have as many keys as you want. In
the change I was proposing, callers could "allow alice to share X" and
get one key, then "allow bob to access share X" and you'll get a
second key. If you then "allow alice to share Y" you'll get Alice's
key again (same as for share X), but you'll now find that the key lets
you into share Y too. In this example, alice and bob are arbitrary
client names that the API caller has made up. In practice I would
imagine API callers' would use things like names of guest instances,
names of groups of guest instances associated with a particular
application.
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.
I think this probably comes down to a balance between the API purity
of delegating auth to external identities, and the Ceph case where the
"external" identity management is within the storage system. I'm
hoping we can define a sufficiently small change to make the Ceph case
slick without causing much disruption -- looking forward to discussing
face to face tomorrow (I noticed one of the work sessions has been
marked for "Access Allow/Deny Driver Interface").
