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@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
