Security of Using Docker for MariaDB vs Bare Metal

Hello,

I’ve been researching how to set up a machine for the following services:

  1. Nextcloud
  2. GOGs
  3. Emby
  4. (Libre?)NMS

Originally I wanted to set up multiple Alpine VMs to run each service individually. This proved less feasible than I had the patience for, so I’m looking at using the more efficient & easier to use Docker option.

My concern, however, is that I’ll be running this machine 24/7–Are there any factors I should be aware of from a security perspective? The advantage to VMs in my mind was that I would be able to automate more frequent updates through them. With Docker you’re somewhat dependent on the image provider for that.

In the case of MySQL, would you run it on bare metal or under Docker? Why or why not?

Thanks!

Keep your firewall rules tight, don’t open ssh to the world, and if you want, run an ids/ips. Those are my recommendations.

I try not to run databases in docker. There are a few reasons, but the major one is that you kill the container, you can lose the database.

That shouldn’t be a concern, so long as you keep your datafiles, binlogs, relay logs, etc, outside the container.

I suggest checking out LXD. LXD works just like a VM, but consumes a ton less disk space and RAM.

2 Likes

I would run it under Docker and template the infrastructure in YAML utilizing Docker-Compose.

Assuming you had a /var/sql/storage or what have you, the template would look something like:

version: '3'
services:
  mysql:
    container_name: mysql
    restart: always
    image: mysql:alpine
    environment:
      MYSQL_ROOT_PASSWORD: 'noroot4u'
      MYSQL_USER: 'admin'
      MYSQL_PASS: 'noroot4me'
    volumes:
      - /var/sql/storage:/var/lib/mysql

Create a database and some tables and blow away the container and see if it works.

Shouldn’t be an issue, though. We have containers that are Redis and PostgreSQL and send data to S3.

LXD still shares kernel though, right? Not a huge problem in the long run, but some kernels don’t have important features, so it’s worth noting.

Yes, it runs the same kernel. It’s a container like docker, but instead of running a single application it has its own init and looks/works like a separate VM with persistent storage and so on.

1 Like

I don’t see any issues, like other people said keep the db out of the container, and if you follow regular security practices such as mysqld setup and have proper firewall rules you should be good :). The only thing I would add is that running docker in production is usually frowned upon unless if they have made huge strides to make it better and more secure.

Well that completely ignores stateful containers. If you have a problem with databases losing data on kill, you haven’t touched stateful containerization and your relying on stateless containers for a stateful program. That’s a setup and user problem, not a docker problem.

The question i’d ask is: Why do you want to use containers?
There is no Problem running Containers 24/7 and Updates are certainly easier than 4 seperate VM’s. I just don’t get the security question.

Docker Containers don’t enhance your security. Docker has various benefits, but i don’t think most of them are a thing if you plan on running one instance each on a single hardware machine and don’t plan to redeploy this thing regularly.
Docker is great when it comes to deploying reproducable builds across machines, Running many instances at once (docker swarms) and such.

If you just want to set up a machine with a certain setup and use it like that, i’d skip docker and just install what you need. Security concerns are the same for docker or “Bare Metal” (Docker is not Virtualization).

1 Like

You could make the argument that running these services in a virtual machine with some custom networking setup (nat rules and stuff) would be more secure and stable then running all this stuff in docker. (Docker networking is also confusing as fuck).

Please don’t run your db under docker unless if you are just developing. Bare metal or a virtual machine are the route to go here. Less chance of losing data in the event docker takes a dump.