From: Josh Durgin <josh.durgin@inktank.com>
To: Vilobh Meshram <vilobhmm@yahoo-inc.com>,
"ceph-devel@vger.kernel.org" <ceph-devel@vger.kernel.org>
Cc: "ceph-users@ceph.com" <ceph-users@ceph.com>
Subject: Re: [ceph-users] Fwd: CEPH Multitenancy and Data Isolation
Date: Tue, 10 Jun 2014 16:30:39 -0700 [thread overview]
Message-ID: <5397951F.1000009@inktank.com> (raw)
In-Reply-To: <AE4D7541-2202-4A06-BBC6-DADEC88AE89D@yahoo-inc.com>
On 06/10/2014 01:56 AM, Vilobh Meshram wrote:
>> How does CEPH guarantee data isolation for volumes which are not meant
>> to be shared in a Openstack tenant?
>>
>> When used with OpenStack the data isolation is provided by the
>> Openstack level so that all users who are part of same tenant will be
>> able to access/share the volumes created by users in that tenant.
>> Consider a case where we have one pool named “Volumes” for all the
>> tenants. All the tenants use the same keyring to access the volumes in
>> the pool.
>>
>> 1. How do we guarantee that one user can’t see the contents of the
>> volumes created by another user; if the volume is not meant to be
>> shared.
OpenStack users or tenants have no access to the keyring. Cinder tracks
volume ownership and checks permissions when a volume is attached, and
qemu prevents users from seeing anything outside of their vm, including
the keyring.
>> 2. If someone malicious user gets the access to the keyring (which we
>> used as a authentication mechanism between the client/Openstack
>> and CEPH) how does CEPH guarantee that the malicious user can’t
>> access the volumes in that pool.
The keyring gives a user access to the cluster. If someone has a valid
keyring, Ceph treats them as a valid user, since there is no information
to say otherwise. Ceph can't tell whether the user of a keyring is
malicious.
>> 3. Lets say our Cinder services are running on the Openstack API
>> node. How does the CEPH keyring information gets transferred from
>> the API node to the Hypervisor node ? Does this keyring passed
>> through message queue? If yes can the malicious user have a look
>> at the message queue and grab this keyring information ? If not
>> then how does it reach from the API node to the Hypervisor node.
The keyring is static and configured by the administrator on the nodes
running cinder-volume and nova-compute. It's not sent over the network,
and is not needed by nova or cinder api nodes.
Josh
--
To unsubscribe from this list: send the line "unsubscribe ceph-devel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
prev parent reply other threads:[~2014-06-10 23:30 UTC|newest]
Thread overview: 2+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <CFBB8E65.E806%vilobhmm@yahoo-inc.com>
[not found] ` <CFBB8E65.E806%vilobhmm-ZXvpkYn067l8UrSeD/g0lQ@public.gmane.org>
2014-06-10 8:56 ` Fwd: CEPH Multitenancy and Data Isolation Vilobh Meshram
2014-06-10 23:30 ` Josh Durgin [this message]
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=5397951F.1000009@inktank.com \
--to=josh.durgin@inktank.com \
--cc=ceph-devel@vger.kernel.org \
--cc=ceph-users@ceph.com \
--cc=vilobhmm@yahoo-inc.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.