Security and access control in ArangoGraph

This guide explains which access control concepts are available in ArangoGraph and how to use them

The ArangoGraph Insights Platform 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 ArangoGraph, you can lock the resources to prevent accidental deletion. When a resource is locked, it cannot be deleted and must be unlocked first.

The hierarchical 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.

If you lock a backup policy of a deployment or an IP allowlist, CA certificate, and IAM provider of a project, it is still possible to delete the corresponding parent resource without unlocking those properties first.

Policy

Various actions in ArangoGraph 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. This is useful when, as an organization owner, you need to extend the permissions for an organization member.

Permissions linked to predefined roles vary between organization owners and organization members. If you need to extend permissions for an organization member, you can create a new role binding. The complete list of roles and their respective permissions for both organization owners and members can be viewed on the Policy page of an organization within the ArangoGraph dashboard.

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.

Currently, you cannot edit a role binding, you can only delete it.

ArangoGraph Project Policy

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.

ArangoGraph New Role Binding

Roles

Operations on resources in ArangoGraph 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, ArangoGraph 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.

ArangoGraph Roles

Predefined roles

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

Predefined roles cannot be deleted. Note that permissions linked to predefined roles vary between organization owners and organization members.

List of predefined roles and their permissions

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.

ArangoGraph New Role

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 ArangoGraph API.

APIKindVerbs
auditauditlogarchivedelete, get, list
auditauditlogattachmentcreate, delete, get
auditauditlogeventsget
auditauditlogeventdelete
auditauditlogcreate, delete, get, list, set-default, test-https-post-destination, update
backupbackuppolicycreate, delete, get, list, update
backupbackupcopy, create, delete, download, get, list, restore, update
backupfeatureget
billingconfigget, set
billinginvoiceget, get-preliminary, get-statistics, list
billingorganizationget
billingpaymentmethodcreate, delete, get, get-default, list, set-default, update
billingpaymentproviderlist
cryptocacertificatecreate, delete, get, list, set-default, update
dataloaderdeploymentimport
datacpusizelist
datadeploymentcredentialsget
datadeploymentfeaturesget
datadeploymentmodellist
datadeploymentpricecalculate
datadeploymentcreate, create-test-database, delete, full-access, get, list, pause, read-only-access, rebalance-shards, restore-backup, resume, rotate-server, update, update-scheduled-root-password-rotation
datadiskperformancelist
datalimitsget
datanodesizelist
datapresetslist
deploymentprofiledeploymentprofilelist
exampleexampledatasetinstallationcreate, delete, get, list, update
exampleexampledatasetget, list
iamgroupcreate, delete, get, list, update
iampolicyget, update
iamrolecreate, delete, get, list, update
iamuserget-personal-data, update
metricsendpointget
metricstokencreate, delete, get, list, revoke, update
mlmlservicesget
monitoringlogsget
monitoringmetricsget
networkprivateendpointservicecreate, get, get-by-deployment-id, get-feature, update
notebookmodellist
notebooknotebookcreate, delete, execute, get, list, pause, resume, update
notificationdeployment-notificationlist, mark-as-read, mark-as-unread
prepaidprepaiddeploymentget, list
replicationdeploymentmigrationcreate, delete, get
replicationdeploymentreplicationget, update
replicationdeploymentclone-from-backup
replicationmigration-forwarderupgrade-connection
resourcemanagerorganization-invitecreate, delete, get, list, update
resourcemanagerorganizationdelete, get, update
resourcemanagerprojectcreate, delete, get, list, update
scimuseradd, delete, get, list, update
securityiamprovidercreate, delete, get, list, set-default, update
securityipallowlistcreate, delete, get, list, update

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:

Role binding added to →
Role effective on ↓
Organization policyProject ABC’s policyDeployment X’s policy of project ABC
Organization, its projects and deployments
Project ABC and its deployments
Project DEF and its deployments
Deployment X of project ABC
Deployment Y of project ABC
Deployment Z of project DEF

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.
Note that users who do not meet the restrictions will not be granted permissions for any resource in the organization. These users can still be members of the organization.

Using the first option, you can limit which authentication providers are accepted for users trying to access an organization in ArangoGraph. 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 ArangoGraph 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.

    ArangoGraph audit log

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