`Securitatea Containerelor Docker în Producție: Utilizatori Non-Root, Capabilități Linux și Modul Rootless` în Docker

Containere Standard Producție

Ghid complet de securizare (hardening) a containerelor Docker în producție: rularea proceselor ca utilizator non-root, eliminarea capabilităților nucleului cu --cap-drop=ALL, montarea sistemului de fișiere read-only și configurarea Docker Rootless.

Sintaxă comandă

docker run --cap-drop=ALL --cap-add=NET_BIND_SERVICE --read-only --user 1001:1001

În mod implicit, procesul principal dintr-un container Docker rulează ca utilizator root (UID 0). Dacă aplicația are o vulnerabilitate critică (cum ar fi Remote Code Execution – RCE) sau dacă există o vulnerabilitate la nivelul nucleului Linux (kernel exploit), atacatorul care obține acces la container are drepturi de root pe sistemul de fișiere și poate evada direct pe serverul gazdă (Container Escape). Securizarea containerelor în producție (Container Hardening) este o cerință esențială de conformitate și apărare în adâncime.

1. Regula #1: Crearea și Aplicarea Utilizatorului Non-Root

Nicio aplicație web, API sau worker de fundal nu trebuie să ruleze ca root în interiorul imaginii finale. Adăugați întotdeauna un grup și un utilizator dedicat în Dockerfile:

Configurarea utilizatorului neprivilegiat în Dockerfile

FROM node:20-alpine

WORKDIR /app

# Creăm un grup și un utilizator dedicat de sistem cu UID/GID fix (1001):
RUN addgroup -g 1001 -S appgroup && \
    adduser -u 1001 -S appuser -G appgroup

COPY package*.json ./
RUN npm ci --omit=dev

COPY --chown=appuser:appgroup . .

# COMUTARE OBLIGATORIE PE UTILIZATORUL NEPRIVILEGIAT:
USER appuser

EXPOSE 3000
CMD ["node", "server.js"]

2. Principiul Privilegiilor Minime cu Linux Capabilities

Chiar și atunci când un proces necesită anumite privilegii (de exemplu, un proxy Nginx care trebuie să asculte pe portul 80), nu trebuie să îi acordați toate drepturile de root. Utilizați mecanismul –cap-drop și –cap-add:

Eliminarea tuturor capabilităților și păstrarea strictă a celor necesare

# 1. Eliminăm complet toate cele 41+ de capabilități ale nucleului:
# 2. Adăugăm strict capacitatea de a deschide porturi sub 1024 (NET_BIND_SERVICE):
docker run -d \
  --name web-proxy \
  --cap-drop=ALL \
  --cap-add=NET_BIND_SERVICE \
  -p 80:80 \
  nginx:alpine

3. Sistem de Fișiere Read-Only la Runtime

Peste 90% din atacurile asupra containerelor implică descărcarea și execuția unui binar malițios (ex: crypto-miner sau reverse shell) în directoarele /tmp sau /var/tmp. Dacă montați sistemul de fișiere al containerului ca Read-Only, atacatorul nu poate salva absolut nimic pe disc:

Rularea unui container complet imuabil

docker run -d \
  --name api-securizat \
  --read-only \
  --tmpfs /tmp:rw,noexec,nosuid,size=64m \
  --tmpfs /app/cache:rw,noexec,nosuid,size=32m \
  -p 8080:8080 \
  my-api:latest

Directiva --read-only blochează scrierile pe tot discul, iar opțiunea --tmpfs montează foldere temporare strict în memoria RAM a gazdei, blocând explicit execuția de binare (noexec) și drepturile SUID (nosuid).

4. Limitarea Resurselor și Prevenirea Atacurilor DoS / Fork Bomb

Un container compromis sau un script recursiv defect poate genera mii de procese, blocând întregul server fizic. Limitați strict resursele la pornire:

docker run -d \
  --name worker-safe \
  --pids-limit 150 \
  --memory="512m" \
  --memory-swap="512m" \
  --cpus="1.0" \
  my-worker:v1

5. Modul Docker Rootless: Nivelul Suprem de Securitate

În modul standard, daemonul Docker (dockerd) rulează ca root pe serverul gazdă. Docker Rootless permite rularea atât a daemonului, cât și a tuturor containerelor ca un simplu utilizator Linux fără drepturi de sudo, folosind User Namespaces. În caz de compromitere totală a unui container, atacatorul este doar un utilizator limitat pe server, fără nicio cale de preluare a controlului asupra mașinii.