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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox