Сучасні інженерні команди все частіше впроваджують додатки Node.js і Next.js у контейнерах Docker. Хоча контейнери спрощують доставку коду, вони несуть специфічні ризики, які ідеально збігаються з категоріями OWASP Top 10. У цій статті ми представляємо модель загрози, механізми дії та практичні кроки хардінгу, щоб ваші образи Docker відповідали вимогам комплаєнсу та принципу найменших привілеїв.
Модель загрози – що може піти не так?
Базовий вектор атаки на контейнер – неправильно налаштований базовий образ, у якому є зайві пакети, типові облікові записи користувачів або відкриті порти. Такі уразливості призводять до кількох класів загроз, описаних у OWASP Top 10:
- A01 – Broken Access Control: запуск процесу від імені root дозволяє ескалацію за допомогою експлойтів у системних бібліотеках.
- A02 – Cryptographic Failures: відсутність шифрування змінних середовища та секретних даних в образі.
- A05 – Security Misconfiguration: типові налаштування Dockerfile, необмежені права до файлової системи.
Ця модель передбачає, що атакувальник має доступ до образу (наприклад, через публічний реєстр) або може інжектувати шкідливий код на етапі CI/CD. Тому кожен етап – від побудови образу до запуску в кластері Kubernetes – має бути під контролем.
Механізм хардінгу – як це працює?
Хардінг контейнерів базується на трьох стовпах: мінімалізм образу, обмеження привілеїв та постійний моніторинг вразливостей. Мінімалізм означає використання легких базових образів (наприклад, node:18‑alpine) і видалення всіх непотрібних інструментів. Обмеження привілеїв реалізується шляхом визначення не‑root користувача у Dockerfile та використанням прапорців --read-only і --cap-drop під час запуску. Моніторинг полягає у регулярному скануванні образів за допомогою інструментів типу Trivy, Anchore чи Clair.
Приклад: вразливий vs. виправлений фрагмент Dockerfile
# --- ВРАЗЛИВИЙ DOCKERFILE ---------------------------------------------------
FROM node:18
WORKDIR /app
COPY . .
RUN npm install
EXPOSE 3000
CMD ["node", "server.js"]
# запуск від root, повний доступ до файлової системи
У наведеному прикладі образ містить усі залежності проєкту, включно з інструментами розробки, і запускає процес від root – класичний випадок A05 – Security Misconfiguration.
# --- ВИПРАВЛЕНИЙ 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 .
# створення не‑root користувача
RUN addgroup -S appgroup && adduser -S appuser -G appgroup
USER appuser
EXPOSE 3000
# запуск у режимі read‑only, обмежені capabilities
CMD ["node", "server.js"]
У виправленій версії застосовано багатоступеневу збірку, видалено dev‑dependencies, визначено спеціального користувача та обмежено привілеї. Це безпосередньо вирішує A01, A02 і A05.
Чекліст хардінгу Docker для Node.js / Next.js
- Використовуйте легкі, офіційні базові образи (alpine, slim).
- Багатоступенева збірка – розділіть шар build від runtime.
- Встановлюйте лише продакшн‑залежності (
npm ci --only=production). - Визначайте не‑root користувача і обмежуйте capabilities (
--cap-drop ALL). - Запускайте контейнер у режимі read‑only, якщо додаток не потребує запису.
- Налаштуйте обмеження ресурсів (CPU, memory) у podspec Kubernetes.
- Увімкніть підсистеми AppArmor/SELinux та seccomp профіль.
- Регулярно скануйте образи на вразливості (OWASP Dependency‑Check, Trivy).
- Використовуйте секрети з менеджера (Kubernetes Secrets, HashiCorp Vault) – ніколи не зберігайте їх в образі.
- Аудитуйте логи контейнера і моніторьте поведінку додатка (Falco, OpenTelemetry).
Типові помилки та компроміси
На практиці команди часто відмовляються від деяких рекомендацій через зручність. Найпоширеніші пастки:
- Збереження повного dev‑образу у продакшн – збільшує площу атаки і призводить до A06 (Vulnerable & Outdated Components).
- Відсутність обмежень запису – додатки Next.js генерують тимчасові файли; розробники часто вимикають режим read‑only, що відкриває двері для ransomware.
- Використання типового користувача root – найпростіший вектор ескалації, особливо в середовищах multi‑tenant.
Рішенням є впровадження автоматичних тестів безпеки в pipeline CI/CD, які примушують дотримання критеріїв чекліста. Компроміси мають документуватись і затверджуватись командою безпеки.
Посилання на стандарти
Наші рекомендації базуються на визнаних рамках:
- OWASP Top 10 – класифікація найважливіших загроз веб‑застосункам.
- CWE‑250 – обмеження прав (principle of least privilege).
- Docker Bench for Security – набір тестів, що відповідає CIS Docker Benchmark.
- Kubernetes Hardening Guide – кращі практики для подів і кластерів.
«Безпека контейнерів – це не одноразова конфігурація, а безперервний процес верифікації та вдосконалення.»
Практичний приклад впровадження в CI/CD
Нижче схема простого pipeline в GitHub Actions, який збирає, сканує та публікує образ:
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 примушує, щоб кожна зміна коду проходила сканування вразливостей перед публікацією образу, що знижує ризик впровадження уразливості типу A06.
Підсумовуючи, hardening Docker‑контейнерів для застосунків Node.js і Next.js вимагає свідомого підходу до мінімізації образу, застосування принципу least‑privilege та регулярного моніторингу. Використання вищезгаданого чекліста та інтеграція сканування в CI/CD дозволяє ефективно усувати ризики OWASP Top 10. Якщо вам потрібна підтримка у впровадженні цих практик у вашій організації, зв’яжіться з Coderia.it – ми допоможемо створити безпечну та масштабовану контейнерну інфраструктуру.
