Lead Image © lightwise, 123RF.com

Closing the CephFS Trust Gap

On the Right Path

OpenStack is a ubiquitous open source cloud computing platform. An undeniable necessity for applications running on OpenStack is secure, multitenant access to shareable and POSIX-compliant read-write-many (RWX) storage primitives. The OpenStack Shared File Systems (shares) service, code-named Manila, allows you to provision and manage the lifecycle of these RWX shares at scale. It abstracts the implementation details of more than 40 commercial and open source storage solutions. OpenStack users interact with consistent and simple self-service APIs while storage system drivers in Manila translate these requests and achieve a common outcome.

The Manila service itself isn't in the data path. It's a provisioner and, hence, the control plane, so a lot rides on the configuration of the data path. In most service provider or public clouds, the use of Manila is intentionally scoped down because of security implications. Virtiofs keeps the operator in control of the data path. It lets you attach shared storage the way block storage works in OpenStack: no gateways, no expensive isolated networks. End users get security and simplicity through direct attachment with OpenStack APIs.

Multitenant Security

To provide proper multitenant security guarantees, cloud providers have to ensure that two aspects are enforced for shares:

• Data isolation: Shares of a given tenant must have strict namespace isolation. The security model imposed in Manila is permissive. The owners control access to the shares. Any new share starts off without access. Access is explicitly granted by the share's owners with usernames (for CIFS, CephFS, Kerberized NFS, and others), IP addresses or subnets (for NFS), or TLS certificates (for GlusterFS and others). An additional expectation is that a "root escape" isn't possible (i.e., a user that mounts their share isn't able to walk the filesystem tree and get