Access control in ArangoDB Oasis

Oasis has a level structured set of resources that are subject to access control:

• Organizations
• Projects
• Deployments

Each of these resources have a set of operations that can be invoked upon them. For example, you can create a project in an organization. This requires the respective permission, which can be granted to organization members via a role such as the pre-defined Project Administrator.

The association of a member with a role is called a role binding. All role bindings of a resource combined form the so called policy.

Roles can be bound on organization, project and deployment level. The lower levels inherit permissions from their parent resources.

Policy

To give a user (or a group of users) access to resources of Oasis, you assign a role to that user (or group). This is done in a policy.

A policy is the set of a bindings of roles to users (or groups) for a specific resource. This means that there is a unique policy per resource.

For example, the Oasis Introduction organization has exactly one policy, which binds roles to members of the organization. These bindings are used to give these users permissions to invoke operations on this organization.

How to view, edit or remove role bindings of a policy

Decide whether you want to edit the policy of the organization or of a project or deployment and navigate the resource’s Policy tab.

• Organization: Click on Access Control in the main navigation, then click on the Policy tab.
• Project: Click on the desired project in the main navigation, then click on the Policy tab.
• Deployment: Click on the desired project in the main navigation, then on the title or view button of the desired deployment and finally click on the Policy tab.

To delete a role binding, click on the Trash bin icon in the Actions column.

How to add a role binding to a policy

1. Navigate to the Policy tab of an organization, project or deployment.
2. Click on the New role binding button.
3. Select one or more users and/or groups.
4. Select the roles that you want to bind to the specified members.
5. Click the Create button.

Roles

Operations on resources in Oasis require zero or more permissions. Since the number of permissions is large and very detailed, it is not practical to assign permissions directly to users. Instead Oasis has roles.

A role is a set of permissions. Roles can be bound to groups (preferably) or individual members. These bindings contribute to the respective organization, project or deployment policy.

There are predefined roles, but you can also create custom roles.

Predefined roles

Predefined roles are created by Oasis and group permissions together in a logical role. An example of a predefine role is deployment-viewer. That role contains all permissions needed to view deployments in a project.

Predefined roles cannot be deleted.

How to create a custom role

1. Click on Access Control in the main navigation.
2. On the Roles tab, click on the New role button.
3. Enter a name and optionally a description for the new role.
4. Select the desired permissions.
5. Click the Create button.

How to view, edit or remove a custom role

1. Click on Access Control in the main navigation.
2. On the Roles tab, click on:
   • A role name or the eye icon in the Actions column to view the role.
   • The pencil icon in the Actions column to edit the role. You can also view a role and click the Edit button in the detail view.
   • The trash can icon to delete the role. You can also view a role and click the Delete button in the detail view.

Permissions

Each operation (invoked on a resource) requires zero or more permissions. A permission is a constant string such as resourcemanager.project.create, following the schema <api>.<kind>.<verb>.

Permissions are solely defined by the Oasis API.

Permission inheritance

Each resource has its own policy, but this does not mean that you have to repeat access control bindings on all these policies.

Once you assign a role to a user (or group of users) in a policy at one level, all the permissions of that role are inherited in lower levels. That is, permissions are inherited downwards from an organization to its projects and from a project to its deployments.

For more inclusive permissions, add the highest permission for a member or group at the at the organization level. For example, if you bind the role deployment-viewer to user John in the policy of an organization, John will have all the permissions contained in that role in all projects of that organization and all deployments in those projects as well.

For more restrictive permissions, add the highest permission at the project or even deployment level, and least permission at the organization level. For example, if you bind the role deployment-viewer to user John in a project, John will have all the permissions contained in that role in that project as well as in all deployments contained in that project, but not in other projects of the containing organization.

Inheritance example

• Imagine you have a group Deployers.
• That group holds all persons that deal with deployments.
• Further imagine you have a role Deployment Viewer, containing permission data.deployment.get and data.deployment.list.
• You could now add a role binding of Deployers to Deployment Viewer.
• If you add the binding to the organization policy, the members of this group will be granted the defined permissions for the organization, all its projects and all its deployments.
• If you add it project A’s policy, the members of this group will be granted the defined permissions for project A only and its deployments, but not for other projects and its deployments.
• If you add it to deployment X’s policy of project A, the members of this group will be granted the defined permissions for deployment X only, and not any other deployment of project A or any other project of the organization.

The role Deployment viewer is effective on the following entities depending on which policy the binding is added to: