Docker konteynerlar xavfsizligi: non-root, Trivy bilan skanerlash

Qisqacha javob

Konteyner o‘z-o‘zidan ishonchli xavfsizlik chegarasi emas. U host yadrosidan foydalanadi, odatiy image esa standart capabilities to‘plami bilan root sifatida ishga tushadi. Himoyaning katta qismi beshta odatga tayanadi:

• jarayon non-root foydalanuvchi nomidan ishlaydi;
• image minimal bazada yig‘iladi;
• ildiz fayl tizimi faqat o‘qish uchun;
• keraksiz Linux capabilities olib tashlangan (odatda hammasi);
• Docker soketi hech qachon ilova konteyneriga ulanmaydi.

Bundan tashqari, har bir image CI’da ma’lum zaifliklar (CVE) bo‘yicha tekshiriladi, shunda zaif bog‘liqlik production’ga yetib bormaydi.

Non-root foydalanuvchi va minimal image

Agar hujumchi ilovadagi zaiflikdan foydalansa, u jarayon huquqlariga ega bo‘ladi. Konteyner ichidagi root hostdagi root’ga ko‘pchilik o‘ylagandan ancha yaqin, ayniqsa konfiguratsiya xatosi bilan birga.

FROM node:22-slim
WORKDIR /app
COPY package*.json ./
RUN npm ci --omit=dev
COPY . .
USER node
EXPOSE 3000
CMD ["node", "server.js"]

Bu yerda muhim jihatlar:

• USER imtiyozsiz hisobga o‘tkazadi. Rasmiy Node image’larida node foydalanuvchisi bor; boshqalarida uni useradd orqali yarating yoki raqamli UID ko‘rsating.
• Ilova fayllari root’ga tegishli va ilova foydalanuvchisi uchun faqat o‘qishga ochiq, shuning uchun jarayon o‘z kodini qayta yoza olmaydi.
• 1024 dan yuqori portni tinglang, shunda uni ochish uchun qo‘shimcha imtiyoz kerak bo‘lmaydi.
• Slim, Alpine yoki distroless bazalarni va multi-stage build’ni tanlang: kompilyatorlar, paket menejerlari va shell yig‘ish bosqichida qoladi. Paketlar kamroq bo‘lsa, CVE ham, hujumchi uchun vositalar ham kamroq.

Read-only fayl tizimi va capabilities’ni olib tashlash

Ko‘pchilik servislar faqat vaqtinchalik papkaga va ehtimol bitta ma’lumotlar tomiga yozadi. Qolgan hamma narsani read-only qilish mumkin.

docker run -d \
  --read-only \
  --tmpfs /tmp \
  --cap-drop ALL \
  --security-opt no-new-privileges \
  myapp:1.4.2

• --read-only binar fayl tashlab qo‘yish yoki konfiglarni o‘zgartirishga yo‘l qo‘ymaydi.
• --tmpfs /tmp ilovaga xotirada vaqtinchalik fayllar uchun joy beradi.
• --cap-drop ALL fayl egasini o‘zgartirish yoki tarmoqqa raw kirish kabi yadro imkoniyatlarini olib tashlaydi. Faqat asoslab bera oladiganingizni qaytaring.
• no-new-privileges setuid binar fayllar orqali huquqlarni oshirishni taqiqlaydi.

Kubernetes’da xuddi shu narsa konteynerning securityContext qismida beriladi:

securityContext:
  runAsNonRoot: true
  runAsUser: 1000
  allowPrivilegeEscalation: false
  readOnlyRootFilesystem: true
  capabilities:
    drop: ["ALL"]

Docker soketini hech qachon ulamang

/var/run/docker.sock ni ulash konteynerga Docker daemon ustidan to‘liq nazorat beradi. Daemon’ni boshqargan kishi host fayl tizimi ulangan imtiyozli konteynerni ishga tushira oladi — bu amalda hostdagi root. Soketga root paroli kabi munosabatda bo‘ling.

Agar vositaga Docker haqiqatan kerak bo‘lsa (CI runner’lar, log yig‘uvchilar), uni alohida hostga chiqaring, tor allowlist’li filtrlovchi proxy’dan foydalaning yoki daemon’siz image yig‘adigan vositalarga o‘ting. Xuddi shu mantiq --privileged va --pid=host uchun ham amal qiladi: ilova konteynerlarida ular bo‘lmasligi kerak.

CI’da Trivy bilan image’larni skanerlash

Trivy — image ichidagi tizim paketlari va til bog‘liqliklarini zaifliklar bazalari bilan solishtiradigan open-source skaner. U Dockerfile va Kubernetes manifestlarini konfiguratsiya xatolariga ham tekshira oladi.

# tuzatiladigan HIGH/CRITICAL zaifliklarda pipeline’ni to‘xtatish
trivy image --severity HIGH,CRITICAL --ignore-unfixed --exit-code 1 myapp:1.4.2

# Dockerfile va manifestlarni konfiguratsiya xatolariga tekshirish
trivy config .

Skanerlashni shovqinli emas, foydali qilish uchun:

• Severity bo‘yicha chegara: HIGH va CRITICAL’da merge’ni bloklang, qolganini hisobotda ko‘rsating.
• --ignore-unfixed patch’i yo‘q CVE’larni o‘tkazib yuboradi — hozircha ular bilan baribir hech narsa qilib bo‘lmaydi.
• Qabul qilingan risklarni .trivyignore faylida har bir yozuv uchun izoh va qayta ko‘rib chiqish sanasi bilan saqlang.
• Muntazam qayta skanerlang, faqat yig‘ishda emas: o‘zgarmagan image’lar uchun ham yangi CVE’lar paydo bo‘ladi.
• Uchinchi tomon CI action’larining versiyasi yoki commit’ini qat’iy belgilang: skaner ham yetkazib berish zanjiringizning bir qismi.

Ko‘p uchraydigan xatolar