this post was submitted on 18 Oct 2023
1 points (100.0% liked)

Self-Hosted Main

511 readers
1 users here now

A place to share alternatives to popular online services that can be self-hosted without giving up privacy or locking you into a service you don't control.

For Example

We welcome posts that include suggestions for good self-hosted alternatives to popular online services, how they are better, or how they give back control of your data. Also include hints and tips for less technical readers.

Useful Lists

founded 1 year ago
MODERATORS
[email protected]
1
How to prevent rogue docker containers from wreaking havoc? (alien.top)
submitted 1 year ago by [email protected] to c/[email protected]
25 comments fedilink hide all child comments
 

There was a recent post about whether to enable ufw and it made me ask: how protected I am from a rogue docker container? I have a single server with 15-20 docker containers running at any given time. Should one get hacked or be malicious from the get go, are there (hopefully easy to implement for an armchair sysadmin) best practices to mitigate such an event? Thanks!

you are viewing a single comment's thread
view the rest of the comments
[–] [email protected] 1 points 1 year ago (1 children)

What is a rogue docker container?

[–] [email protected] 1 points 1 year ago (1 children)

If the source of the image is getting hacked/ the maintainer does make a backdoor, etc

[–] [email protected] 1 points 1 year ago (1 children)

Doesn't make any sense since you can see all the code and what you are installing.

[–] [email protected] 1 points 1 year ago (1 children)

The people who read the source code of all their Docker containers and especially understand everything in there are probably around 1%.

[–] [email protected] 1 points 1 year ago (1 children)

For this sub maybe. It doesn't take to much to look at what you are copy and pasting.

[–] [email protected] 1 points 1 year ago

It's not limited to what you copy and paste. One of my containers has a pretty long starter script written by the container maintainer. That is needed because the application doesn't have an official Docker version and the starter script takes care of all the necessary work arounds to get the app running inside a container. There could be something malicious in there I don't know about, if I don't read the whole starter script, which is probably in a language I don't understand well.

Even more complicated : I could have been studying the starter script and made the decision it's fine and the author trustworthy, so I pull the container image with the tag "v1. 0" every few months a new version gets released, I take a look at the changelog, if no braking changes are mentioned I pull tag v1. 1 and replace my existing container. At some point the maintainer stops mainting the container and hands over the Repository to someone else. This person unfortunately now places malicious code in the starter script and releases an update. If I would now pull that new container image I now have a rougue container.