Permissions and Access Control

2011/09/22

As for access rights, until now there was only one possible difference between two users. A user was an admin, or he wasn't. As an admin, you had access to some features that you didn't as a normal user, like managing other users. Every newly created user had access to all existing clouds and every existing user had access to a new cloud. We wanted to let users manage access rights in their accounts per user and per cloud.

The distinction between admins and normal users still exists. You still need to be an admin in order to manage, for example, users, credentials or SSH keys, but access to clouds is handled with the new permission system.

Whenever you try to access a cloud or something that is a "child" of a cloud, your permissions are checked. In this respect applications, instances, roles and deployments are all children of clouds. This means that when you change a user's permissions for a cloud, you also change his permissions for any application, instance, role and deployment that belongs to that cloud.

Here's what the UI for managing permissions looks like.

There are a few things going on in this interface. Let's have a look at the details.

The tabs let you choose between "Clouds" and "Users". Inside these tabs you are able to change default permissions and concrete permissions.

When you are in the "Clouds" tab, the default permissions are the ones that existing users have to a new cloud. In the dropdown below you can select a cloud in order to see and edit every user's permissions to that cloud.

When you are in the "Users" tab, the default permissions are the ones that a new user has to existing clouds. In the dropdown below you can select a user in order to see and edit that user's permissions to every cloud.

For every combination of a user and a cloud we store a permission record. A permission record consists of a level and two flags. The level is something new and it can be one of "manage", "deploy", "show" and "none". The flags are not new, we just changed their scope.

In the past you could already decide whether SSH user handling was enabled for a user or not. On top of that, you could decide whether that user was also added to the sudoers file or not. Instead of making this decision per user, you can now make that decision per user and cloud. That's why we removed the according checkboxes from the user form.

But let's get back to that permission level. As stated above, it can be one of "manage", "deploy", "show" and "none".

The level "none"
prevents you from noticing a cloud. You won't see the cloud or any of it's children. And of course you can't trigger any actions or edit things.

The level "show"
lets you see a cloud and all its children, but you are not allowed to take any actions.

The level "deploy"
lets you deploy all applications belonging to this cloud as well as trigger cloud deployments like update cookbooks. You can't edit the cloud or any child.

The level "manage"
lets you do anything you were able to do before we introduced the permissions feature. So you can add, start/stop and remove servers, add, edit and remove roles and applications and so on.

As mentioned earlier, the distinction between admin and normal user still exists. Admins can change permissions, including their own ones. That's why we decided to not allow to restrict an admin's permissions at all.

Our API is also aware of permissions. When you try to access a cloud that just doesn't exist, we still respond with HTTP status code 404 and the message "Resource not found". However, an attempt to access a cloud that you don't have permission for results in a response with status code 403 and message "No permission".