Security and access control in ArangoDB Oasis

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

• Organizations
• Projects
• Deployments

For each of these resources you can perform various operations. For example, you can create a project in an organization and create a deployment inside a project.

Locked resources

In ArangoDB Oasis, you can lock the resources to prevent accidental deletion. When a resource is locked, it cannot be deleted and must be unlocked first.

The hierarchial structure of the resources (organization-project-deployment) is used in the locking functionality: if a child resource is locked (for example, a deployment), you cannot delete the parent project without unlocking that deployment first.

Policy

Various actions in ArangoDB Oasis require different permissions, which can be granted to users via roles.

The association of a member with a role is called a role binding. All role bindings of a resource comprise a policy.

Roles can be bound on an organization, project and deployment level (listed in the high to low level order, with lower levels inheriting permissions from their parents). This means that there is a unique policy per resource (an organization, a project or a deployment).

For example, an organization has exactly one policy, which binds roles to members of the organization. These bindings are used to give the users permissions to perform operations in this organization.

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

Decide whether you want to edit the policy for an organization, a project or a deployment:

• Organization: In the main navigation menu, click Access Control, then open the Policy tab.
• Project: In the main navigation menu, click the name of the required project, then open the Policy tab.
• Deployment: In the main navigation menu, click the name of the required project, then click either the deployment name or the View button, and finally open the Policy tab.

To delete a role binding, click the Recycle Bin icon in the Actions column.

How to add a role binding to a policy

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

Roles

Operations on resources in Oasis require zero (just an authentication) 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 uses roles.

A role is a set of permissions. Roles can be bound to groups (preferably) or individual users. You can create such bindings for the respective organization, project or deployment policy.

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

Predefined roles

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

Predefined roles cannot be deleted.

How to create a custom role

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

How to view, edit or remove a custom role

1. In the main navigation menu, click Access Control.
2. On the Roles tab, click:
   • 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 recycle bin icon to delete the role. You can also view a role and click the Delete button in the detail view.

Permissions

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

Permissions are solely defined by the Oasis API.

Permission inheritance

Each resource (organization, project, deployment) has its own policy, but this does not mean that you have to repeat role bindings in 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 this role are inherited in lower levels - permissions are inherited downwards from an organization to its projects and from a project to its deployments.

For more general permissions, which you want to be propagated to other levels, add a role for a user/group at the organization level. For example, if you bind the deployment-viewer role to user John in the organization policy, John will have the role permissions in all projects of that organization and all deployments of the projects.

For more restrictive permissions, which you don’t necessarily want to be propagated to other levels, add a role at the project or even deployment level. For example, if you bind the deployment-viewer role to user John in a project, John will have the role permissions in this project as well as in all the deployments of it, but not in other projects of the parent organization.

Inheritance example

• Let’s assume you have a group called “Deployers” which includes users who deal with deployments.
• Then you create a role “Deployment Viewer”, containing data.deployment.get and data.deployment.list permissions.
• You can now add a role binding of the “Deployers” group to the “Deployment Viewer” role.
• If you add the binding to an organization policy, members of this group will be granted the defined permissions for the organization, all its projects and all its deployments.
• If you add the role binding to a policy of project ABC, members of this group will be granted the defined permissions for project ABC only and its deployments, but not for other projects and their deployments.
• If you add the role binding to a policy of deployment X, members of this group will be granted the defined permissions for deployment X only, and not any other deployment of the parent project or any other project of the organization.

The “Deployment Viewer” role is effective for the following entities depending on which policy the binding is added to:

Restricting access to organizations

To enhance security, you can implement the following restrictions via Oasisctl:

1. Limit allowed authentication providers.
2. Specify an allowed domain list.

Using the first option, you can limit which authentication providers are accepted for users trying to access an organization in Oasis. The following commands are available to configure this option:

• oasisctl get organization authentication providers - allows you to see which authentication providers are enabled for accessing a specific organization
• oasisctl update organization authentication providers - allows you to update a list of authentication providers for an organization to which the authenticated user has access
  • --enable-github - if set, allow access from user accounts authenticated via Github
  • --enable-google - if set, allow access from user accounts authenticated via Google
  • --enable-username-password - if set, allow access from user accounts authenticated via a username/password

Using the second option, you can configure a list of domains, and only users with email addresses from the specified domains will be able to access an organization. The following commands are available to configure this option:

• oasisctl get organization email domain restrictions -o <your_organization_id> - allows you to see which domains are in the allowed list for a specific organization
• oasisctl update organization email domain restrictions -o <your_organization_id> --allowed-domain=<domain_name1> --allowed-domain=<domain_name2> - allows you to update a list of the allowed domains for a specific organization
• oasisctl update organization email domain restrictions -o <your_organization_id> --allowed-domain= - allows you to reset a list and accept any domains for accessing a specific organization

Using an audit log

To have a better overview of the events happening in your Oasis organization, you can set up an audit log, which will track and log auditing information for you. The audit log is created on the organization level, then you can use the log for projects belonging to that organization.

To create an audit log

1. In the main navigation menu, click Access Control in the Organization section.
2. Open the Audit logs tab and click the New audit log button.

3. In the dialog, fill out the following settings:

   • Name - enter a name for your audit log.
   • Description - enter an optional description for your audit log.
   • Destinations - specify one or several destinations to which you want to upload the audit log. If you choose Upload to cloud, the log will be available on the Audit logs tab of your organization. To send the log entries to your custom destination, specify a destination URL with authentication parameters (the HTTP destination option).

   The Upload to cloud option is not available for the free-to-try tier.

   • Excluded topics - select topics that will not be included in the log. Please note, that some are excluded by default (for example, audit-document).

   Enabling the audit log for all events will have a negative impact on performance.

   • Confirmation - confirm that logging auditing events increases the price of your deployments.

   

4. Click Create to add the audit log. You can now use it in the projects belonging to your organization.