Współczesne zespoły inżynierskie coraz częściej wdrażają aplikacje Node.js i Next.js w kontenerach Docker. Choć kontenery upraszczają dostarczanie kodu, niosą ze sobą specyficzne ryzyka, które idealnie pokrywają się z kategoriami OWASP Top 10. W niniejszym artykule przedstawiamy model zagrożenia, mechanizmy działania i praktyczne kroki hardeningu, aby Twoje obrazy Docker spełniały wymogi compliance i zasady least‑privilege.
Model zagrożenia – co może pójść nie tak?
Podstawowy wektor ataku na kontener to niewłaściwie skonfigurowany obraz bazowy, w którym znajdują się niepotrzebne pakiety, domyślne konta użytkowników lub otwarte porty. Tego typu luki prowadzą do kilku klas zagrożeń opisanych w OWASP Top 10:
- A01 – Broken Access Control: uruchamianie procesu jako root umożliwia eskalację przy wykorzystaniu exploitów w bibliotece systemowej.
- A02 – Cryptographic Failures: brak szyfrowania zmiennych środowiskowych i tajnych danych w obrazie.
- A05 – Security Misconfiguration: domyślne ustawienia Dockerfile, nieograniczone uprawnienia do systemu plików.
Model ten zakłada, że atakujący ma dostęp do obrazu (np. poprzez publiczny rejestr) lub może wstrzyknąć złośliwy kod w fazie CI/CD. Dlatego każdy etap – od budowania obrazu po uruchamianie w klastrze Kubernetes – musi być objęty kontrolą.
Mechanizm hardeningu – jak działa?
Hardening kontenerów opiera się na trzech filarach: minimalizm obrazu, ograniczenie uprawnień oraz ciągłe monitorowanie podatności. Minimalizm oznacza użycie lekkich bazowych obrazów (np. node:18‑alpine) i usunięcie wszystkich niepotrzebnych narzędzi. Ograniczenie uprawnień realizuje się przez definiowanie nie‑rootowego użytkownika w Dockerfile oraz stosowanie flag --read-only i --cap-drop przy uruchamianiu. Monitorowanie polega na regularnym skanowaniu obrazów przy użyciu narzędzi takich jak Trivy, Anchore czy Clair.
Przykład: podatny vs. poprawiony fragment Dockerfile
# --- PODATNY DOCKERFILE ---------------------------------------------------
FROM node:18
WORKDIR /app
COPY . .
RUN npm install
EXPOSE 3000
CMD ["node", "server.js"]
# uruchomienie jako root, pełny dostęp do systemu plików
W powyższym przykładzie obraz zawiera wszystkie zależności projektu, w tym narzędzia deweloperskie, oraz uruchamia proces jako root – klasyczny przypadek A05 – Security Misconfiguration.
# --- POPRAWIONY DOCKERFILE -----------------------------------------------
FROM node:18-alpine AS builder
WORKDIR /app
COPY package*.json ./
RUN npm ci --only=production
COPY . .
# ---------- final stage ----------
FROM node:18-alpine
WORKDIR /app
COPY --from=builder /app .
# utworzenie nie‑rootowego użytkownika
RUN addgroup -S appgroup && adduser -S appuser -G appgroup
USER appuser
EXPOSE 3000
# uruchomienie w trybie read‑only, ograniczone capabilities
CMD ["node", "server.js"]
W wersji poprawionej zastosowano wielostopniowe budowanie, usunięto dev‑dependencies, zdefiniowano dedykowanego użytkownika oraz ograniczono uprawnienia. To bezpośrednio adresuje A01, A02 i A05.
Checklista hardeningu Docker dla Node.js / Next.js
- Używaj lekkich, oficjalnych bazowych obrazów (alpine, slim).
- Wielostopniowe budowanie – oddziel warstwę build od runtime.
- Instaluj jedynie zależności produkcyjne (
npm ci --only=production). - Definiuj nie‑rootowego użytkownika i ogranicz capabilities (
--cap-drop ALL). - Uruchamiaj kontener w trybie read‑only, jeśli aplikacja nie wymaga zapisu.
- Skonfiguruj ograniczenia zasobów (CPU, memory) w podspecie Kubernetes.
- Włącz podsystem AppArmor/SELinux oraz seccomp profile.
- Regularnie skanuj obrazy pod kątem podatności (OWASP Dependency‑Check, Trivy).
- Używaj tajemnic z managera (Kubernetes Secrets, HashiCorp Vault) – nigdy nie zapisuj ich w obrazie.
- Audytuj logi kontenera i monitoruj zachowanie aplikacji (Falco, OpenTelemetry).
Typowe błędy i kompromisy
W praktyce zespoły często rezygnują z niektórych zaleceń ze względu na wygodę. Najczęstsze pułapki to:
- Utrzymywanie pełnego obrazu dev w produkcji – zwiększa powierzchnię ataku i prowadzi do A06 (Vulnerable & Outdated Components).
- Brak ograniczeń zapisu – aplikacje Next.js generują pliki tymczasowe; deweloperzy często wyłączają tryb read‑only, co otwiera drzwi dla ransomware.
- Używanie domyślnego użytkownika root – najłatwiejszy wektor eskalacji, szczególnie w środowiskach multi‑tenant.
Rozwiązaniem jest wprowadzenie automatycznych testów bezpieczeństwa w pipeline CI/CD, które wymuszają spełnienie kryteriów checklisty. Kompromisy powinny być dokumentowane i zatwierdzane przez zespół bezpieczeństwa.
Odwołania do standardów
Nasze rekomendacje opierają się na uznanych ramach:
- OWASP Top 10 – klasyfikacja najważniejszych zagrożeń aplikacji webowych.
- CWE‑250 – ograniczanie uprawnień (principle of least privilege).
- Docker Bench for Security – zestaw testów zgodnych z CIS Docker Benchmark.
- Kubernetes Hardening Guide – best practices dla podów i klastrów.
„Bezpieczeństwo kontenerów to nie jednorazowa konfiguracja, lecz ciągły proces weryfikacji i doskonalenia.”
Praktyczny przykład wdrożenia w CI/CD
Poniżej schemat prostego pipeline w GitHub Actions, który buduje, skanuje i publikuje obraz:
name: Build & Secure Docker Image
on:
push:
branches: [ main ]
jobs:
build:
runs-on: ubuntu-latest
steps:
- uses: actions/checkout@v3
- name: Set up Docker Buildx
uses: docker/setup-buildx-action@v2
- name: Build image
run: |
docker build -t myapp:${{ github.sha }} .
- name: Scan image with Trivy
uses: aquasecurity/trivy-action@master
with:
image-ref: myapp:${{ github.sha }}
exit-code: '1'
ignore-unfixed: true
- name: Push to registry
if: success()
run: |
echo ${{ secrets.REGISTRY_PASSWORD }} | docker login -u ${{ secrets.REGISTRY_USER }} --password-stdin
docker push myapp:${{ github.sha }}
Pipeline wymusza, że każda zmiana kodu musi przejść skanowanie podatności przed publikacją obrazu, co redukuje ryzyko wprowadzenia luki typu A06.
Podsumowując, hardening Docker kontenerów dla aplikacji Node.js i Next.js wymaga świadomego podejścia do minimalizacji obrazu, stosowania zasad least‑privilege oraz regularnego monitorowania. Zastosowanie powyższej checklisty i integracja skanowania w CI/CD pozwala skutecznie eliminować ryzyka OWASP Top 10. Jeśli potrzebujesz wsparcia przy wdrożeniu tych praktyk w Twojej organizacji, skontaktuj się z Coderia.it – pomożemy zbudować bezpieczną i skalowalną infrastrukturę kontenerową.
