Projects
Below organizations in the ArangoGraph deployment hierarchy are projects. They can represent organizational units such as teams, product groups, environments (e.g. staging vs. production). You can have any number of projects under one organization.
Organizations → Projects → Deployments
Projects are a container for related deployments, certificates & IP allowlists. Projects also come with their own policy for access control. You can have any number of deployment under one project.
In essence, you can create whatever structure fits you for a given organization, its projects and deployments.
How to create a new project
- Click Overview in the Projects section of the main navigation.
- Click the New project button.
- Enter a name and optionally a description for your new project.
- Click the Create button.
- You will be taken to the project page.
- To change the name or description, click either at the top of the page.
Projects contain exactly one policy. Within that policy, you can define role bindings to regulate access control on a project level.
How to create a new deployment
See Deployments: How to create a new deployment
How to delete a project
Deleting a project will delete contained deployments, certificates & IP allowlists. This operation is irreversible.
- Click Overview in the Projects section of the main navigation.
- Click the recycle bin icon in the Actions column.
- Enter
Delete!
to confirm and click Yes.
Alternatively, you can also delete a project via the project page:
- Click a project name in the Projects section of the main navigation.
- Click the Danger zone tab.
- Click the Delete project… button.
- Enter
Delete!
to confirm and click Yes.
If the project has a locked deployment, you need to unlock it first to be able to delete the project.
How to manage IP allowlists
IP allowlists let you limit access to your deployment to certain IP ranges. It is optional, but strongly recommended to do so.
You can create an allowlist as part of a project.
- Click a project name in the Projects section of the main navigation.
- Click the Security tab.
- In the IP allowlists section, click:
- The New IP allowlist button to create a new allowlist.
When creating or editing a list, you can add comments
in the Allowed CIDR ranges (1 per line) section.
Everything after
//
or#
is considered a comment until the end of the line. - A name or the eye icon in the Actions column to view the allowlist.
- The pencil icon to edit the allowlist. You can also view the allowlist and click the Edit button.
- The recycle bin icon to delete the allowlist.
- The New IP allowlist button to create a new allowlist.
When creating or editing a list, you can add comments
in the Allowed CIDR ranges (1 per line) section.
Everything after
How to manage certificates
Certificates are utilized for encrypted remote administration. The communication with and between the servers of an ArangoGraph deployment is encrypted using the TLS protocol.
Each ArangoGraph deployment is accessible on two different port numbers:
- default port (8529)
- high port (18529)
Each ArangoGraph Notebook is accessible on the following port number:
- default port (8840)
Metrics are accessible on the following port number:
- default port (8829)
The distinction between these port numbers is in the certificate used for the TLS connection.
On the default port (8529), a well known X509 certificate created by Let’s Encrypt is being used. This certificate has a lifetime of 5 years and is rotated automatically. It is recommended to use Well known certificates, as this eases the access of a deployment in your browser.
On the high port (18529), a self-signed X509 certificate is being used. This certificate has a lifetime of one year and it is automatically created by the ArangoGraph platform. It is also rotated automatically before the expiration date.
Unless you switch off the Use well known certificate option in the certificate generation, both the default and high port serve the same self-signed certificate.
When using private endpoints, notebooks, and metrics, you can specify alternate domain names which are added to the self-signed certificate as Subject Alternative Name (SAN).
The Subject Alternative Name (SAN) is an extension to the X. 509 specification that allows you to specify additional host names for a single SSL certificate. The SAN is not included in the well known certificate generated by Let’s Encrypt.
Certificates that have the Use well known certificate option enabled do not need any installation and will be supported by almost all web-browsers automatically.
When creating a certificate that has the Use well known certificate option disabled, the certificate needs to be installed on your local machine as well. This operation slightly varies between operating systems.
- Click a project name in the Projects section of the main navigation.
- Click the Security tab.
- In the Certificates section, click:
- The New certificate button to create a new certificate.
- A name or the eye icon in the Actions column to view a certificate. The dialog that opens provides commands for installing and uninstalling the certificate through a console.
- The pencil icon to edit a certificate. You can also view a certificate and click the Edit button.
- The tag icon to make the certificate the new default.
- The recycle bin icon to delete a certificate.
Certificate Rotation
Every certificate has a self-signed root certificate that is going to expire. When certificates that are used in existing deployments are about to expire, an automatic rotation of the certificates is triggered. This means that the certificate is cloned and all affected deployments then start using the cloned certificate.
Based on the type of certificate used, you may also need to install the new certificate on your local machine. To prevent any downtime, it is recommended to manually create a new certificate and apply the required changes prior to the expiration date.
How to manage role bindings
See: