DEV Community: Dong Nguyen

How to make your MongoDB container more secure?

Dong Nguyen — Sun, 13 Sep 2020 13:59:56 +0000

Start it with docker

The most simple way to get MongoDB instance in your machine is using docker to run mongodb image on docker hub as below:

docker run --name mongodb -p 27017:27017 mongo

By specifying -p 27017:27017, you can access to it with the connection string such as mongodb://localhost:27017 or mongodb://0.0.0.0:27017, as same as installed MongoDB server.

This database instance is only available locally. In the case you want to access to it from another computer, you have to overwrite the default config file with a custom MongoDB configuration file.

Allow to connect from outside

The command looks like below:

docker run --name mongodb -p 27017:27017 -v /path/to/custom/mongod.conf:/etc/mongod.conf mongo

In which, the mongod.conf file has been customized to allow to connect from outside:

# mongod.conf

# other settings

# network interfaces
net:
  port: 27017
  # bindIp: 127.0.0.1  # this is default setting
  bindIp: 0.0.0.0  # this is what changed

# other settings

But since now your database is public and no longer secure.

In my experience, the first thing we should do in this situation is change the default port.

Change default port

Let's map it to another free port:

docker run --name mongodb -p 27117:27017 -v /path/to/custom/mongod.conf:/etc/mongod.conf mongo

So that the connection string will become mongodb://IP_ADDRESS:27117, not default port.

As you know, there are many bots those automatically scan for public databases on the internet. They try to check the popular default ports, such as 3306 (mysql), 5432 (posgres), 6379 (redis), 27017 (mongo), etc. Changing to a strange port may help you in almost cases.

However, that's not enough.

Enable authentication

By default MongoDB will start with authentication disabled. We should enable it with a little bit change to entrypoint. In order to make things easier management, we create a docker-compose.yaml file as below:

version: "3"

services:
  mongodb:
    image: mongo
    container_name: mongodb
    ports:
      - 27117:27017
    volumes:
      - ./mongod.conf:/etc/mongod.conf
    entrypoint: ["mongod", "--auth", "--config", "/etc/mongod.conf"]

In the above .yaml file, we added our custom entrypoint to run mongodb with --auth flag. Now when we run it with docker-compose, we should get MongoDB within a container named mongodb similar to the docker run command earlier.

And the following is the most important parts of this article...

Create users with specific permissions

Until now, our MongoDB instance does not have any user yet. We will get into its container and create a few ones.

Firstly, let's get the interactive mongo shell by running:

docker exec -it mongodb mongo

With opening mongo shell, we can now run the commands to switch to admin database and create a user named boss with admin permission on any database:

use admin
db.createUser({
  user: 'boss',
  pwd: 'YourVeryComplexPassword',
  roles:['userAdminAnyDatabase']
})

Done, press Ctrl + C to exit the shell and leave that session.

Note that, at this time, we had already a MongoDB instance run with authentication mode enabled, and an admin user. The connection string for boss user now looks like:

mongodb://boss:YourVeryComplexPassword@IP_ADDR:27117

But that's power user, don't use it for regular applications. Instead, we should create more users for different purposes.

To create more user or database, we have to come back to mongo shell as boss user:

docker exec -it mongodb mongo -u boss

Enter password when asked and you should see something like:

Assume that we have a plan to use a database blogs to store our great blog posts. We should add a user named writer which can write to this database, and a user named reader which can read only.

Do that as below:

# go to database `admin`
use admin

# add writer
db.createUser({
  user: 'writer',
  pwd: 'YourComplexPassword',
  roles:[
    { 
      role: 'readWrite',
      db: 'blogs'
    }
  ]
})

# add reader
db.createUser({
  user: 'reader',
  pwd: 'YourSimplePassword',
  roles:[
    { 
      role: 'read',
      db: 'blogs'
    }
  ]
})

Done, press Ctrl + C to exit the shell and leave that session again.

Now we have 2 new users, one for read/write and other for read only action. Their connection strings are:

mongodb://writer:YourComplexPassword@IP_ADDR:27117
mongodb://reader:YourSimplePassword@IP_ADDR:27117

With the apps or API endpoints those only load and show blog posts, we just need to use the connection string for reader. Otherwise, when we need to add more blog posts, we will connect to database as writer.

That's it. Enjoy playing with docker and MongoDB :)

6 things I just learned after implementing my first Deno web service

Dong Nguyen — Sat, 22 Aug 2020 10:20:58 +0000

As I've shared yesterday about my list of microservices, today I try to implement an API Gateway with Deno. Because I've created Node.js version early, I though that it should be very simple to migrate to Deno, but not really. It taken about 3 hours of reading the documentation and some tutorials!

Here are some notes for reference later.

1. Server and HTTPOptions

Similar to Node.js, Deno provides http, a standard library to handle web server. I've played with it a little bit. Then I quickly found that there is a drop-in replacement for Express named opine.

So I switch to this lib. It works almost the same as Express, but incomplete, and the listen method is quite different.

With Express, to set host and port, we can just write:

app.listen(port, host, onServerReady);

But with Opine's app instance, the following ways didn't work:

app.listen(port, host, onServerReady);
app.listen(host, port, onServerReady);
app.listen({port, host}, onServerReady);

There is no docs/examples relating to this issue, so I have to look in the source code and see that they use HTTPOptions and HTTPSOptions from the standard http/server library. They didn't use the property name host as server.listen() in Node.js, but hostname. So, the correct way is:

app.listen({hostname: host, port}, onServerReady);

2. HTTP Proxy

As other API Gateway, I need to map some endpoints to the actual services behind the scene. In Node.js, I use http-proxy-middleware. In Deno, there is opine-http-proxy.

I haven't dig into these libs enough yet. But the basic method I'm using shows a little bit of a difference.

With express/http-proxy-middleware, if we write something like:

app.use('/login', createProxyMiddleware('https://abc.com'));

Then, any request to {API_GATEWAY_DOMAIN}/login will be forwarded to https://abc.com/login.

But, with opine/opine-http-proxy, we have to write exactly the path:

app.use('/login', createProxyMiddleware('https://abc.com/login'));

3. The flags

With Node.js, we simple run node script.js and everything should work well. But with Deno, deno run script.ts may not work as expected. Because, Deno does not grant any permission to running script by default. So, if the script needs to access to the network, it must be started with the flag --allow-net:

deno run --allow-net script.ts

If it also needs to load a file from hard disk, it must be started with the flag --allow-read:

deno run --allow-net --allow-read script.ts

There is also --allow-write to write files, --allow-env to get environment variables, --allow-run to run sub processes, and more here.

However we can use --allow-all to enable all the permission so it would work as same as Node.js, but we shouldn't - that is the unique value by Deno.

4. `readJson` and `--unstable` flag

Because in my service there is always a service.json file to define service settings, I need to parse JSON file.

Similar to Node.js, Deno provides a standard library called fs too. And I found that there is few familiar methods to deal with JSON content there.

However, the following does not work:

import { readJson } from "https://deno.land/std/fs/mod.ts";

As you see, it loads many unnecessary modules and requires to add --unstable to the command, for example:

deno run --allow-net --allow-read --unstable app.ts

In the case you don't like the unstable things, you can refer their read_json.ts and write your own method, for example:

const readJson = async (filePath: string) => {
  const content = await Deno.readTextFile(filePath);
  return JSON.parse(content);
};

5. Built-in logger

The log library in Deno looks quite similar to Python logging module. Because I also work with Python so this is not very hard to get familiar with.

This lib supports file rotating, custom format and handlers. So we don't need to use any third party module as with Node.js we must.

6. Which docker image for Deno should be chosen?

While Deno team didn't build any official docker image yet, I recommend to use hayd/deno-docker. Because it is updated regularly and there is a discussion about making it official.

Conclusion

Node.js is cool. Deno is cool too. There is no package.json, nor node_modules. That makes things look more simple and clean. The standard libraries and built-in tools are great. But this ecosystem will need more time to mature...

Would you like to play with microservices?

Dong Nguyen — Fri, 21 Aug 2020 14:34:51 +0000

Hello guys,

I just created a (quite long) list of services to implement, just for learning and practice more about microservices, node, deno, python, golang, vlang, and some new tools.

https://github.com/ndaidong/microservices

But studying alone is boring! If you have the same plan to learn the same things with me, feel free to fork and contribute. Together, we can build a set of useful sample source codes for reference.

Or, if you have any other opinion, please share to me :)

7 habits for better git usage

Dong Nguyen — Mon, 08 Jun 2020 15:16:10 +0000

everything begins with an issue
always check the current branch before making any changes
run "git pull" as often as possible
commit as soon as possible
commit should be referenced to the related issues
never push changes to the main branch directly
always keep the tree tidy by cleaning old branches