Hi everyone.
I have recently deployed an installation of Open Nebula. Simple
background : we're running Xen on Debian, with a custom TM driver that
uses both NFS and iSCSI (sharing that TM driver is in our roadmap).
I have encountered a few shortcomings. Some I have simply accepted for
now, others I have bypassed as I could. One of them has to do with file
management.
I'll consider several types of files :
- VM images.
- kernels/initrd images.
- contextualization files.
Regarding VM images :
If a non-privileged user wants to use his own images, he needs either :
- a shell on the master host, and put his images as world readable.
- to put his images on a public http/ftp server
We found neither to be satisfying from the point of security.
Regarding kernels/initrds there is no way fo a user to upload his
kernels. Kernels must either be installed on all compute nodes, or on a
shared file system.
Regarding contextualization files, it's pretty much the same problem as
with images.
Basically, what I would like is the following :
- all files that may be used in a template by a non privileged users
are owned by oneadmin
- all files that may be used in a template by a non privileged users
are chmoded 600
- all files used in a template are referenced by a file ID.
Allowing end-users to manipulate system paths is a security nightmare.
Basically, what I want is :
- admins may manipulate images with a path
- users are only allowed to use file ids (e.g.
KERNEL="kernel-linux3.0.grsec" or an arbitrary id)
- users may upload files through the API, possibly through sunstone
I'm making the following proposition. This is not something I suggest
should simply be added to the roadmap. This is something I (or someone
else where I work) will be working on, and contribute back. Hence I'm
looking for feedback on what the community thinks about it.
There would be a new "file" API, with associated "onefile" command.
"onefile create" would take a file parameter, and upload that file
_through the API_.
Oned would then save that file in a directory (/srv/cloud/files).
Templates could then refer to those using their ids.
Files may have key-value pairs associated with them, and onefile can
manipulated these.
There would be a "onefile update" command, which would allow a user to
update a file, yet keep the same ID and key-value pairs.
A file is read-only. A file is never written to by a VM, or oned, or
anything.
Admins may create a file with a "--local" flag. In that case, the path
is sent to oned rather than the file, and oned copies the File. If the
file is a symlink, the symlink is copied, rather than the file it links to.
Anything parsing a template is updated to understand this idea of file
id, and replace it the right value. If the template contains paths and
was submitted by an untrusted user, a "permission denied" error is
returned. This can be disabled or enabled to ensure compatibility in the
oned.conf file.
Contextualization may be done by selecting all files that have a certain
value for a certain key (e.g. "role->mysql" or
"vhost->www.example.com"), or by specifying the file's id, or it's path if
An image may be created from a file. The image repository needs to know
how to import a file.
A file may be uploaded compressed. It would make sense to store it
compressed as well (or at least as a sparse file).
I welcome any remarks or questions on this idea.
--
Vivien Bernet-Rollande
Systems& Networking Engineer
Alter Way Hosting
_______________________________________________
Users mailing list
Users@lists.opennebula.org
http://lists.opennebula.org/listinfo.cgi/users-opennebula.org
