Users roles in Xen Orchestra

This post is an introduction of our users roles implementation in Xen Orchestra. Our main goal is to provide you a way to optimize your workflow with VMs, and you'll see how we found the solution.

The need

A LOT of companies ask us for user roles for managing VMs.  Different cases, but the same need:

• assign a VM to a defined user
• hide everything else for him
• choose specific rights for him (only see the VM, or ability to modify it, or every rights)
• delegate VMs to developers or clients

The solution

Xen Orchestra, by design, can communicate with different pools with a single point of administration. Thus, you'll be able to delegate any VM in your whole  infrastructure to the authorized person. And as the central point of control is in xo-server (and not in xo-web), you are secure! We first started to think about permissions for every objects (VMs but also storage repositories etc.). A long task to accomplish, and not the real need. After all, there is two types of people using XO:

• administrators, with the need of a global and comprehensive view of the whole stuff, also capable to give rights to users on specific VMs
• users, with the need of a view of their assigned VMs, and limited rights accorded by their administrator
  After clearing this, we've got another question: what kind of user permissions are needed?

Here is the "right" model:

With it model, you can exploit your VM in many different cases:

• you can provide a view for "vm-guest" users: (answering to the question: "is my VM is running? how any RAM I have? what are IP attached to my VM? How many disk space I have?"). It will also display graphs in order to monitor their own load (cpu, disks usages etc.)
• for clients who need to start, shutdown or reboot their assigned VM, you can use "vm-operator". This kind of user can also access consoles. Furthermore, he can taking snapshot and revert it! In this case, your dev team can work without asking anything to your sysadmin. You can give them a proper environment to test and validate their entire deployment process, and they can re-do it anytime they want.
• for advanced users (maybe developers or other sysadmins) in a dedicated pool (e.g a "test pool"), you can give them more permissions: with "vm-admin", they can modify VM resources for testing best fit for their applications ("is 2vCPU and 2GB is enough for the new app?") before entering in production. Once that's done, as an admin, you can migrate this VM in a production pool and here you go! They can also rename the VM and its description.

Profiles, groups and permissions

Giving rights user per user can be useful, but sometimes painful in your workflow. That's why we will also offer Groups. Let's see with a simple example: you want to give "vm-operator" profile for 3 VMs to the whole developers team. Without groups, you'll need to add each user in each VMs. Boring.

Now, create a group named "dev-team", add each user you want in it. Now, for each VM, you just add the group "dev-team" and put the "vm-operator" right to it. You're done! But what happened if the lead developer needs more rights on the VM? Let's say "vm-editor", for rolling back when necessary. In this case, just add the user itself with higher permissions.

Even if in the "dev-team" group in the same time, the higher permissions will prevail.

Planned design

We'll use something close to the way how GitLab works: simple and efficient. Something like that, if you are an admin, on a VM page:

When clicking on the "Edit" icon in the corner of the Users panel:

When clicking on "Add User", you'll have a list with users and auto completion. Same stuff for Groups.

Authentication

Our goal is to allow multiple auth system, like "internal" (user account directly in Xen Orchestra) or with other external services (LDAP, Google Account, Twitter, GitHub etc).

In the last case, you can deliver VM access to your clients without the need to create a brand new account (with a password etc.)

Beyond user permissions

The other big plus about Xen Orchestra is its architecture:

"xo-web" is one element of XO, but not the only one. As you may know, we started to create "xo-cli".

After all, CLI is just an other interface. Now, just think about combining the power of CLI (scripts, automation, deployment) with user permissions:

• your developers/devops/clients can talk directly to xo-server with a simplified API
• connected to your whole Xen infrastructure (even between different pools) with their rights.
• without installing a complicated stack (XO works without any agent to install on your servers and can run in a minute with our appliance).

Cloud you say?

When?

As soon as we got the financial "green light". Want to speed up the process? Come here!