Setting up a game server using Nakama on Google Compute Engine, part 3

· by Steve · Read in about 5 min · (1024 Words)
gamedev

This is the third instalment of a blog series I’m writing about Nakama, which I’ve been using for leaderboards in our first game Washed Up!.

  • Part 1 covers what Nakama is, and why I chose it over other options
  • Part 2 ran you through setting up a basic service you can use for development & testing

The configuration at the end of Part 2 is not ideal; it works, but the database is running in ‘insecure mode’ and there’s no SSL between clients and the server, which could leave it vulnerable to interception attacks. Let’s deal with the database first of all.

A note on Nakama versions

You’ll need to be running Nakama version 1.4.1 or newer to be able to follow these steps. I submitted a couple of PRs which enable some of these steps to work, including running Cockroach in secure mode and using SSL direct on the Nakama server, which were only merged in for this release.

To upgrade, assuming you followed Part 2:

  • mkdir ~/nakama-1.4.1; cd ~/nakama-1.4.1
  • wget -qO- https://github.com/heroiclabs/nakama/releases/download/v1.4.1/nakama-1.4.1-linux-amd64.tar.gz | tar xvz
  • sudo systemctl stop nakama
  • sudo cp nakama /usr/local/bin/
  • sudo systemctl start nakama

Running CockroachDB in secure mode

So far, we’ve run Cockroach in insecure mode, which means we haven’t had to worry about logins. It’s expedient but not recommended, because essentially anyone connecting to the database has root access, with no authentication required. Even though the database is not exposed to any external connections right now, we should enable proper authentication to prevent accidental damage, and then in future if we decide to run Cockroach in a multi-node configuration when we have to expose it to the network, we already know it’s running in secure mode and everything is already configured on the Nakama end.

There are 2 ways to authenticate with Cockroach, traditional user/passwords and certificates. The root user should always use certificates. You can read their full documentation on this to get a better overview but I’ll shortcut this below.

Creating the CA certificate

Let’s start by creating a CA certificate, which will act as the root certificate for our entire cluster:

  • cd
  • sudo mkdir /etc/cockroach-certs
  • sudo cockroach cert create-ca --certs-dir=/etc/cockroach-certs --ca-key=cockroach-ca.key

An important point: /etc/cockroach-certs will contain all the cert data except the private key for the root CA certificate, which is called cockroach-ca.key here and placed in the current dir. It’s really important that you keep this file secure and make backups of it. It’s used to generate and validate all other certificates and is therefore critical.

sudo chown root:root cockroach-ca.key; sudo chmod 400 cockroach-ca.key will make it read-only and only accessible by you when you’re sudoing. To back it up, it’s just text so you could copy its contents into a secure note store; I keep mine in my 1Password vault for example.

Create node & client certificates

Next, we need a certificate for the ‘node’ (instance of Cockroach running on this server), and for the root user.

  • sudo cockroach cert create-node micro-instance1 --certs-dir=/etc/cockroach-certs --ca-key=cockroach-ca.key
    • Make sure you replace micro-instance1 with the name you gave your server
  • sudo cockroach cert create-client root --certs-dir=/etc/cockroach-certs --ca-key=cockroach-ca.key

You can confirm the list of certificates currently present at any time like this:

  • sudo cockroach cert list --certs-dir=/etc/cockroach-certs

Let’s check we can log in as root using certificates now. We’ll have to shut down our current Cockroach install, which will in turn stop Nakama - if you remember, our systemd configuration for Nakama depends on Cockroach, and so gracefully shuts down whenever it does.

  • sudo systemctl stop cockroach
  • sudo cockroach start --store=attrs=ssd,path=/var/lib/cockroach-store --certs-dir=/etc/cockroach-certs

We’ll just run that in the terminal so it’s easy to see output as a test. Notice the lack of an --insecure argument; we’re doing things properly now.

Open another terminal and connect to our new secure instance:

  • sudo cockroach sql -u root --host micro-instance1 --certs-dir=/etc/cockroach-certs
    • Make sure to alter the --host micro-instance1 argument to match your actual hostname as when you created the certificate
  • If all goes well you should have a Cockroach SQL prompt

Creating a database user & granting permission

Now let’s create a user for the Nakama service. Nakama will log in with a user/password combination rather than certificates, just because that’s simpler to configure on the Nakama end.

In the root SQL prompt you have from the previous step:

  • CREATE USER nakama WITH PASSWORD 'some-password';
  • GRANT ALL ON DATABASE nakama TO nakama;
  • GRANT ALL ON TABLE nakama.* TO nakama;

Exit the SQL client with Ctrl+D, then check you can log in to Nakama:

  • sudo cockroach sql -u nakama --host micro-instance1 --certs-dir=/etc/cockroach-certs --database=nakama
  • Enter the password when prompted, you should be allowed in
  • SHOW TABLES; to confirm you can see everything, it should show about 13 tables.

Exit the SQL client with Ctrl+D, and also stop the Cockroach instance in your other terminal with Ctrl+C now.

Change the Cockroach service to run in secure mode

Time to make secure mode the official Cockroach configuration.

  • Edit the file /etc/systemd/system/cockroach.service in an editor
    • Remove the --insecure argument
    • Add an extra argument --certs-dir=/etc/cockroach-certs
  • Tell systemd to reload the Cockroach configuration
    • sudo systemctl daemon-reload
    • Wait 30s or so to be sure (this is a deferred action)
  • Start the service in its new config
    • sudo systemctl start cockroach
  • Check the service args really are correct (that daemon-reload worked):
    • ps aux | grep cockroach and check the --certs-dir argument is there

Now let’s tell Nakama how to connect to the new DB configuration:

  • Edit the file /etc/nakama/nakama-config.yml
  • Add login details to the database.address section like this:
  database:
    address:
      - "nakama:some-password@micro-instance1:26257"
  • Now restart Nakama: sudo systemctl nakama start

Test that Nakama is working as before. You’re now running a properly secured database instead of that horrible ‘anyone who can see the port can connect as root’ situation. Yay!

Next Steps

This post ran on a bit and I’m short of time, so I’m going to defer some of the other subjects to a future post. Still to come:

I hope this series is useful so far! Let me know any feedback via Twitter.