GrapheneDB Blog

Updates from the GrapheneDB team

Introducing Our New Secure and Flexible Authentication System

We are excited to announce a new authentication system that has been rolled out to all GrapheneDB databases last week (Feb 14th 2017).

Security

Background

Back in the days when we launched GrapheneDB in 2013, Neo4j did not support authentication.

Common patterns to deploy Neo4j included setting up a proxy to deal with SSL encryption and enforce HTTP basic authentication or installing an unmanaged server extension to take care of authentication.

We had to roll out our own authentication mechanism from scratch, if we were to provide a hosting service. From the beginnings until some days ago, we created a set of credentials including a random password upon database creation. These credentials would be up for display on the UI any time if the user needed them. This fact implied storing the credentials in plain text within our database.

Fast forward to 2015. In version 2.2.0, Neo4j introduced user management and secured the HTTP REST endpoint with HTTP basic authentication, which was at that point a standard for any Neo4j driver supporting authentication. Because HTTP basic authentication is a standard, our authentication was 100% transparent and compatible with all Neo4j drivers available.

Then, in Neo4j 3.0 user authentication was consolidated and integrated into the Bolt protocol as well. At GrapheneDB we implemented a Bolt-aware proxy layer, one of its purposes being to extend our authentication system to work with Bolt too.

Drawbacks of our legacy authentication system

The main drawbacks about GrapheneDB’s legacy authentication system come down to various risks related to, and ultimately the security of the database.

Exposing credentials

The credentials were stored in plain text in our database and up for display in the UI any time. It was easy to copy & paste credentials and accidentally expose them via unsafe channels: sending them in emails, posting them on Stackoverflow, on Github or in a support ticket.

We usually pay a lot of attention to this and reach out to users to rotate their credentials when we are aware that they have been exposed, but having credentials in front of you in plain text makes one automatically less concerned about protecting them.

Sharing credentials

When submitting support requests, our users have the option to allow GrapheneDB engineers to access their databases. In order to connect to a users’ database our engineers need valid credentials, so internally our engineers have been using the one set of credentials to connect.

While our engineers are very security concerned and well trained to never expose credentials, this is problematic in terms of auditing and might raise concerns with our users. As soon as a set of credentials is shared by several individuals, it becomes very challenging to keep track of who has copies of them and who might have used them to connect.

Credentials for one-off sessions

Another challenge is dealing with temporary connections. If you need to briefly connect to your Neo4j instance via Neo4j Browser or CLI, which credentials do you use?

It is extremely easy to accidentally store credentials in a web browser. In fact, most of modern browsers ask the user by default if they wish to store the credentials they have provided to log in.

When using CLI tools such as cycli, it is also extremely easy for credentials to land in your command line history. The history file is usually stored in plain text in your home directory, while the browsers at least tend to default to some sort of secure encryption to store credentials.

Our new secure and flexible authentication system

Our new authentication system addresses many of the issues with the legacy authentication system:

  • it’s compatible with any Bolt and HTTP REST drivers that support authentication
  • we only use strong passwords through lengthy, randomly generated tokens
  • all tokens are stored encrypted and are only visible once upon creation. After that no one (not even our engineers) can retrieve a password
  • should we need to connect to a user’s database (assuming we have been given permission by the owner) we will use specific internal temporary passwords that can be audited, not any of the database users
  • plain text passwords have been removed from the interface and sharing passwords is discouraged, because it’s much easier for any team member to create database users as needed
  • it supports temporary credentials for one-off connections, such as connecting from CLIs or with the Neo4j Browser
  • users can drop and rotate credentials anytime: unused credentials, when someone leaves the team or if you think a secret might have been compromised or leaked

Making your GrapheneDB databases safer

We are very excited to improve the security for all our databases and ultimately our users. Moving forward:

  • New databases support the new authentication system only, making them safer by default
  • Existing databases will continue to support the legacy password system to authenticate. Create pairs of credentials as needed and drop the legacy password as soon as you can to make them safer. You will find clear step by step instructions to guide in the transition process here.

Managing database users

GrapheneDB user management

You can find more information on the new database authentication system in the dedicated section of our developer docs.

Deployments Available in UK and Canada

We are proud to announce support for the UK and Canada regions recently launched by AWS. Customers in these regions can now serve their end-users better through low network latencies and are able to store data in any of the two countries.

All our Standard, Performance and Enterprise plans are available for deployment in these two new regions.

Map of supported AWS regions

Here is the updated list of regions GrapheneDB supports, by tiers.

Hobby:

  • US East (N. Virgina)
  • EU (Ireland)

Standard, Performance & Enterprise:

  • US East (N. Virgina)
  • US West (N. California)
  • US West (Oregon)
  • Canada (Central)
  • EU (Ireland)
  • EU (Frankfurt)
  • EU (London)
  • Asia Pacific (Tokyo)
  • Asia Pacific (Singapore)
  • Asia Pacific (Sydney)

We are excited to grow our list of supported regions and serve our world-wide customer base better. If you have any questions, please feel free to reach out to us.

Come Meet Us at AWS re:Invent 2016!

Meet GrapheneDB at AWS re:Invent 2016

Are you ready for AWS re:Invent? We are!

We are very excited to descend upon Las Vegas for what is now the largest cloud computing event in the world, and this year’s lineup is sure to not disappoint. We are looking forward to all of the sessions, workshops, and announcements of new features.

But most importantly, we’re looking forward to meeting you, our users!

Where can you find GrapheneDB?

GrapheneDB is a sponsor this year, so you will be able to find us at the exhibit hall. We will have plenty of swag items to give away, so come get your GrapheneDB sticker and t-shirts.

Find us at booth #541, in the Expo Hall, next to the Developer Lounge.

Want to get in touch beforehand?

The best way to get in touch with us during the event is to simply come by the booth. However, if you’d like to reach out to us beforehand to set-up a time to chat, feel free to email us at hello@graphenedb.com. We’re happy to set aside some time to talk to you and address any specific needs or questions you may have about the product.

Or if you just want to talk to us about how you’re using GrapheneDB, we’d love to hear about it. We specifically welcome feedback about some of our recently released features, such as our new Management API or Insights.

Announcement: New GrapheneDB Management API

The team at GrapheneDB has always been huge fan of how AWS and Heroku use APIs to enable developers to create new processes and tools. The API revolution is transforming the way in which software is written and deployed,creating opportunities for new business models.

Our customers frequently asked for an API to perform database management and operational tasks automatically. We have been working closely with certain customers to fine tune an API that, in the same manner as AWS and Heroku, would give developers the ability to automate tasks. After much work and testing, we are now proud to announce our upcoming Public API.

GraphneDB Management API

So far, we have seen our API help with some interesting use cases, including:

  • Syncing different environments periodically, such as restoring the QA database with a fresh copy of production every day.
  • Deploying databases, stored procedures, or extensions from automated tests or code branches.
  • Automatically downloading all production database backups onto infrastructure for business continuity.
  • Developing SaaS products that require one individual database per account.

Please take a look at our documentation to find out more about our API.

We’re eager to hear what you build with our public API! It’s currently in closed beta, so please contact us at support@graphenedb.com and we’ll provide you access.

Introducing Insights: Server Metrics and Slow Queries Analyzer

A couple of months ago we announced that our Metrics feature was out of beta and available for all of our customers on the Performance tier.

Today we’re excited to present Insights, a toolset that bundles Metrics together with a brand new slow query analyzer.

Insights is a great tool to help you troubleshoot issues when things go wrong or changes are introduced into your environment. The information you get from Insights should enable you to pinpoint if issues are due to external factors or caused by queries. This will greatly simplify the process of improving Neo4j’s performance.

Streaming of insights on GrapheneDB

Our new slow query analyzer registers all queries that hit the database, and aggregates the response times during a given time window. This allows us to offer you data like the slowest queries (highest median and 95th percentile response times), as well as the most time consuming queries (think highest median multiplied by the number of executions).

We strongly believe in providing tools for our customers that will empower them to make data-driven decisions to improve their business. While those tools were previously only available to our Performance tier customers, we’re proud to announce Insights as part of our Standard offering. We want to ensure all customers running production-ready databases on GrapheneDB can benefit from the power of this great toolset.

We’re determined to continue to offer you more tools to be successful with Neo4j. We’ve got many great announcements to make along the way, so stay tuned!

To learn more about Insights please take a look at our documentation.

How to Manage Neo4j Stored Procedures in GrapheneDB

Procedures are the preferred means for extending Neo4j. It allows Neo4j to be extended by writing custom code which can be invoked directly from Cypher.

At GrapheneDB, we provide a self-serviced and automated way to manage stored procedures. In a matter of seconds, you’ll be able to upload your own procedure and enable it on your database.

To add an extension, the database has to be restarted. Our admin interface facilitates this process by asking you to Enable/Disable extensions before applying changes. This allows you to configure your extensions before restarting your database.

In the example below, we’re adding APOC stored procedures, a great library that covers different aspects that are currently not available on Cypher. Extending your Neo4j database is just three click away!

Streaming of stored procedures on GrapheneDB

Extensions management is only available for Developer plans and higher. You can create a Developer database in a matter of seconds here:

Create a Developer database now

If you want to read further instructions on how to manage stored procedures please take a look at our documentation.

Neo4j 3.0 on GrapheneDB

Neo Technology recently released Neo4j 3.0. In addition to some optimizations to Cypher and other features, perhaps the most exciting new highlight of the latest release is Bolt, which is “a new network protocol designed for high-performance access to graph databases” (read the release notes here).

Bolt will seek to introduce a completely new way of working with Neo4j, one which seeks to “consolidate and refine” how you may already work with Neo4j. The spirit of Bolt is not only to improve performance, but also to improve the developer experience.

The goal of Bolt is to consolidate and refine all the ways of doing work with Neo4j, providing more consistent access with a pleasant separation of responsibility. If you want to learn more about Bolt, read this excellent interview with Neo4j’s Nigel Small.

Bolt

We are excited to announce that Neo4j 3.0 is available on all our plans. We’ve been working very hard these last weeks to enable support for it on every tier; self-service and automated, as you are used to from our service. If you want to give it a go for free, follow this link and you’ll be trying out Bolt in a matter of seconds.

GrapheneDB Now Offers Wider Support of AWS Regions

At GrapheneDB, we are committed to giving the best possible service through all of our deployment options.

We are happy to announce today support for 5 additional AWS regions on our Standard plans, and 3 additional regions on our Performances plans. Below, you can find our expanded list of supported AWS regions:

  • US East (N. Virginia)
  • US West (N. California) - NEW ON STANDARD AND PERFORMANCE TIER -
  • US West (Oregon) - NEW ON STANDARD TIER -
  • Europe (Ireland)
  • Europe (Frankfurt) - NEW ON STANDARD AND PERFORMANCE TIER -
  • Asia Pacific (Sydney) - NEW ON STANDARD TIER -
  • Asia Pacific (Tokyo) - NEW ON STANDARD AND PERFORMANCE TIER -

New AWS regions

If you want to change your existing database to one of these new regions, you can use our self-service clone feature and select the new AWS region of your choice when cloning.

Announcing Metrics General Availability

A select number of our Performance customers have been testing the beta of our new metrics dashboard for the last couple of months. We are very grateful for their valuable help in testing out this feature before officially rolling it out. We are excited to announce today that the new Metrics feature is out of beta and is now available for all of our customers on the Performance tier.

Our metrics dashboard will allow you to track server errors and see when errors are happening. You will also be able to track median and 95th percentile response times, as well as see incoming query and request throughput.

Metrics Dashboard

With our new Metrics dashboard, not only will you be able to see what is happening now, but you will be able to get historical information for the last few days by changing the time window of your reports.

No one operates more Neo4j database instances in the cloud than GrapehenDB. This gives our team great insight into how to best equip our customers for success. We understand that giving our customers knowledge about how their servers are performing in real time can help them diagnose key performance issues, keeping them on track for success.

We highly recommend you give our new Metrics dashboard a try and see how powerful it is for yourself. We have big plans for performance diagnoses in 2016, so you’ll want to stay tuned to this blog or our our Twitter page page for updates.

New: Introducing Flexible, On-demand Server Maintenance

GrapheneDB needs to perform maintenance on its servers from time to time. Maintenance procedures will vary depending on your database plan.

On Hobby databases, which are designed for development and testing, we might perform maintenance with downtime without prior notice.

On Standard databases, our entry-level production tier, we will usually send a notification a few days in advance with a specified time window during which we will perform maintenance and an estimated duration for the actual downtime.

Because of the multi-tenant architecture of the Standard tier, our schedule cannot accommodate preferences for maintenance windows.

Existing Performance and Enterprise customers might already know we offer 3 time windows to choose from for maintenance procedures. In order to accommodate customers who want to perform maintenance on specific periods of low traffic, we have been setting up custom time windows on special request.

In order to make this process even easier and more flexible, we’ve added a new on-demand maintenance feature. This feature allows customers on the Performance tier to trigger scheduled maintenance procedures on their database with the click of a button, when it’s more convenient to them. This provides customers with the flexibility to set downtimes when they are less damaging for their business.

When a database instance has a maintenance operation scheduled, a warning with some details will be displayed in the UI:

Databases

You will also see the a warning in the database overview with details about the maintenance, like a description, estimated downtime and a deadline.

Scheduled maintenance

Customers on the Performance tier can trigger the maintenance procedure by clicking on the Launch maintenance button.

While the operation is in progress, a dialogue will inform you of the state of the procedure.

Maintenance in progress

When the operation is complete, the pop-up will be dismissed, and any warning messages will no longer be displayed. At this point, no other changes will be necessary, but you may have to wait a few minutes for the DNS to propagate.

Please note: Unless a maintenance procedure is initiated by a user before the deadline, the maintenance will run automatically at the time specified in the maintenance warning.