Docker Security for SMEs: Running Containers in Production Without the Enterprise Overhead

Containers have established themselves in the small and medium business world over the past few years. What usually begins as a pragmatic tool for an internal application or a test environment gradually, almost unnoticed, makes its way into production. And this is precisely where the problem we regularly encounter when auditing server environments begins: the containers are running, they are doing their job - but nobody ever wrote a security concept.

That is understandable. Docker makes it easy to get something running. It does not, however, make it automatically secure. A container isolates an application, but that isolation is not a fortress wall - it is a technical boundary with clearly defined limits, and those limits can be undermined by misconfiguration. Below we describe the points we most often start with when hardening container environments for SMEs.

Why containers are not secure by default

The most common misconception we encounter is this: "It runs in a container, so nothing can happen." In reality, the default configuration of many setups is considerably more open than those responsible assume. Four patterns stand out:

• Containers with host access. A single wrongly set flag - such as --privileged or a mounted Docker socket - and the container effectively has full access to the host. Anyone who breaks into such a container is standing on the entire server.
• Unsafe images from the internet. Pulling an arbitrary image from Docker Hub is convenient. But many public images are outdated, poorly maintained or simply laced with malicious code. Whatever you have not vetted yourself runs on a leap of faith.
• Missing updates. An image built a year ago contains the vulnerabilities of a year ago. Containers are happily treated as "build once, run forever" - and that is exactly what turns them into a collection point for known CVEs.
• Secrets in the image or in Git. Passwords, API keys and database credentials baked directly into the image or checked into the repository are among our most frequent findings. They then sit in every copy of the image and throughout the entire Git history.

Secure images and your own registry

The foundation of any sensible container strategy is the images themselves. Discipline pays off here, because a clean image concept prevents many later problems from ever arising.

Rely on your own base images or trusted official ones. Reduce the number of sources you have to trust to a minimum. A lean, self-maintained base image beats a colourful collection of foreign images from dubious sources.

Scan images regularly for vulnerabilities. Tools such as Trivy can be integrated into the build process in a matter of minutes and report known CVEs before an image goes into production. What matters is not the one-off scan but the recurring one - vulnerabilities in already-running images become known after the fact.

Operate a private registry with access control. Whoever controls which images are distributed across the company has a clear overview of versions and origins. This is also the prerequisite for being able to say quickly, in an emergency, everywhere a vulnerable image is running.

Keep secrets out of the image. Credentials belong in a secret-management system or in environment variables injected at runtime - never in the Dockerfile and never in the Git repository.

Hardening the Linux host

A container is only as secure as the host it runs on. When securing server and network infrastructure, host operation is therefore a dedicated checkpoint for us.

• Minimally hardened hosts. Ideally, a container host runs only what it needs for container operation. Every additional service is an additional attack surface.
• Resource limits per container. Setting CPU and RAM limits prevents a single runaway container - whether through error or attack - from bringing down the entire host.
• Run rootless or restrict privileges. Containers very rarely need to run as root. Rootless Docker, or at least a dedicated, restricted user, dramatically reduces the damage a compromised container can do.
• Segment the network. Container networks should be furnished with firewall rules and sensible segments. Not every container needs to talk to every other one, and certainly not every one needs to be reachable from the internet.

Monitoring and logging - even in small environments

An argument we often hear at SMEs: "We surely do not need monitoring for our three containers." The opposite is true. It is precisely in small environments that, without monitoring, a problem only becomes apparent once the damage is already visible.

• Central logs for container and host. Logs that live only inside the container vanish when it restarts. Central collection ensures you can reconstruct afterwards what happened.
• Keep an eye on resource use and errors. Unusual CPU load or odd network traffic is often the first sign of a problem - long before a service fails.
• Alerting on suspicious behaviour. A simple alert that fires when a container restarts, generates unusually high traffic or terminates unexpectedly is quickly set up even in small environments and is enormously valuable.
• Regular review of running containers. What is actually running right now, in which version, and since when? You should be able to answer that question at any time.

From practice: a manufacturer in the Salzburg region

An example that stands for many: a manufacturing business with around 35 employees had, over the years, put several in-house tools into operation in Docker containers - spread across different servers, without a concept and without anyone holding the overall picture. It worked, until it did not: occasional outages, unclear version states, nobody able to say reliably which image came from where.

We consolidated the environment, hardened the Linux hosts, introduced a private registry and established lean monitoring. The result was not a high-security setup with enterprise overhead, but a transparent, controllable operation: fewer outages, clear version states, and the certainty of being able to act in an emergency. It is exactly this balance - enough security without excessive effort - that is the right path for most SMEs.

Do you need Kubernetes for this?

The short answer: usually not. For many mid-sized environments, classic Docker or simple orchestration with Docker Compose is entirely sufficient. Kubernetes only plays to its strengths in large, complex and heavily scaling environments - and brings an operational overhead that is wholly disproportionate for three or five containers. The question of which tool fits the need we settle, as part of our IT consulting, soberly along the actual requirements rather than along whatever happens to sound fashionable.

The next step

Containers are a powerful tool, including for SMEs. The risk that comes with unplanned sprawl can be reduced considerably with manageable effort: vetted images, hardened hosts, restricted privileges, monitoring. None of these steps requires a large budget or a dedicated DevOps team.

If your container environment has grown over the years and you can no longer say with confidence what is running where and in which version, taking stock is the sensible first step. We review Docker and container environments as part of our IT security consulting - with a focus on concrete, actionable measures rather than reports that end up in a drawer. For clients in the Berchtesgaden and Salzburg regions, we are happy to come on site.

---