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
- Make sure you replace
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
- Make sure to alter the
- 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
- Remove the
- Tell
systemd
to reload the Cockroach configurationsudo 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:
- How to secure the Nakama service with SSL
- Periodic database backups to Google Cloud Storage
- Accessing the Nakama and Cockroach dashboards via SSH tunnelling
I hope this series is useful so far! Let me know any feedback via Twitter.