Dockerfile-д ENV-ээр secret бүү хий: image дотор мөр нь үлдэнэ

Dockerfile-ийн ENV-д API түлхүүр эсвэл нууц үг бичвэл утга нь бэлэн имэжийн тохиргоонд үлдэнэ. Docker-ийн build-check заавар ENV болон ARG-д нууц өгөхийг аюултайд тооцож, угсралтын үед secret mount ашиглахыг зөвлөдөг. Угсралтад хэрэгтэй түлхүүрийг BuildKit-ээр тухайн алхамд түр өг; ажиллаж буй аппад хэрэгтэй түлхүүрийг контейнер асах үед файл эсвэл нууцын сангаас дамжуул.

Энгийн орчны хувьсагчийг нууц бус тохиргоонд үлдээж болно. Контейнер эхлүүлэхдээ -e сонголтоор өгсөн түлхүүр Dockerfile-ийн ENV шиг имэжид бичигдэхгүй ч контейнерийн тохиргоо, процессын орчинд харагдах эрсдэлтэй. Иймээс нууцыг хэзээ хэрэглэхээс гадна хаана хадгалах, хэн уншиж чадахыг тусад нь шийдэх шаардлагатай.

Угсралтын, ажиллах үеийн болон энгийн утгыг ялга

Угсралтын нууц нь хувийн багцын сангаас хамаарал татах зэрэг зөвхөн имэж бүтээхэд хэрэгтэй эрх юм. Хувийн npm бүртгэлийн түлхүүрээр багц суулгасны дараа тэр түлхүүр апп ажиллахад шаардлагагүй байж болно. Түүнийг дараагийн алхамд өвлүүлэх эсвэл бэлэн имэжийн тохиргоонд хадгалах хэрэггүй.

Ажиллах үеийн нууц нь апп ассан хойно өгөгдлийн сан, төлбөрийн үйлчилгээ эсвэл гадаад API-д холбогдоход хэрэглэгдэх эрх юм. Энэ утгыг имэж бүтээх үеийн secret mount-аас апп авахгүй: уг mount зөвхөн заасан угсралтын алхамд байдаг. Харин PORT, LOG_LEVEL зэрэг хандалтын эрх олгодоггүй утга орчны хувьсагчид тохиромжтой. Хувьсагчийн нэрнээс илүү бодит утга нь эрх олгож байгаа эсэхээр нууц мөн эсэхийг шийд.

Муу Dockerfile-д юу үлдэх вэ

Нөхцөлт муу жишээнд Dockerfile-ийн мөрүүдийг FROM alpine:latest, дараа нь ENV API_TOKEN=DEMO_ONLY гэж бичсэн гэж үзье. DEMO_ONLY бол жинхэнэ түлхүүр биш. Түүний оронд бодит утга тавивал имэжийн Env тохиргоонд орж, имэжийг шалгах эрхтэй хүн контейнерийг ажиллуулахгүйгээр уншиж чадна. Дараагийн хувилбарт ENV-ийг арилгалаа ч өмнө нь тараасан имэжийн хуулбар өөрөө засагдахгүй.

ENV-ийг ARG API_TOKEN болгож солих нь бас нууц дамжуулах арга биш. ENV-ийн утга бэлэн имэжийн орчны тохиргоонд хадгалагддаг бол ARG ердийн тохиолдолд контейнерийн орчинд өвлөгдөхгүй; гэхдээ build history болон provenance мэдээллээр илэрч болно. Эдгээр нь өөр механизмаар задардаг тул аудитад хоёуланг нь шалга. Нууц файл COPY командаар имэжид ороод дараагийн RUN командаар устсан бол өмнөх давхаргад агуулга нь үлдэж болзошгүй.

BuildKit-д нууцыг зөвхөн хэрэглэх алхамд холбо

Docker-ийн build secrets заавар нууцыг build командын --secret сонголтоор өгч, Dockerfile-ийн RUN --mount=type=secret заавраар тухайн алхамд уншихыг тайлбарладаг. Файлаар өгсөн нууцын үндсэн зам нь /run/secrets/<id>; шаардлагатай програм өөр зам хайдаг бол target сонголтоор өөрчилж болно. Mount-ийн утга өөрөө бэлэн имэжид үлдэхгүй, харин RUN доторх програм түүнийг файлд хуулж эсвэл логт хэвлэвэл тусдаа нэвчилт үүснэ.

Нөхцөлт жишээ болгон Node апп угсрахдаа хувийн npm багц татна гэж үзье. Dockerfile-д мөр тус бүрээр FROM node:alpine, WORKDIR /app, COPY package.json package-lock.json ./, RUN --mount=type=secret,id=npmrc,target=/root/.npmrc,required=true npm ci гэж бичнэ. Угсралтыг docker buildx build --secret id=npmrc,src=/secure/project.npmrc -t demo:secret . командаар эхлүүлнэ. Энд /secure/project.npmrc нь угсралтыг ажиллуулж буй талд байгаа credential файл; түүнийг эх кодын сан болон build context-оос гадуур хадгална.

required=true нь npmrc нууц ирээгүй үед RUN алхмыг зогсооно. npm ci дуусахад түр mount арилна, гэхдээ суулгах скриптүүд болон тэдгээрийн гаргах логийг энэ тохиргоо автоматаар хянахгүй. Хэрэв Dockerfile-д COPY . . байгаа бол .dockerignore-д .env болон бусад credential файлыг хас: тэгснээр тэд build context-оор дамжин санамсаргүй хуулагдах эрсдэл багасна. Secret mount нь оролтыг түр өгдөг; угсралтын команд тэр утгаар юу хийснийг орлох хамгаалалт биш.

Ажиллах үеийн түлхүүрийг файл эсвэл нууцын сангаас өг

OWASP-ийн нууц удирдах зөвлөмж контейнер ажиллах үед файлын mount эсвэл нууцын сангаас утга өгөх аргыг тайлбарлаж, орчны хувьсагч процессууд, лог болон dump-д харагдаж болзошгүйг анхааруулдаг. Файл ашиглахын тулд апп түлхүүрийн утгыг хувьсагчаас бус, заасан замаас уншдаг байх ёстой. Замыг орчны хувьсагчаар дамжуулж болно; зам өөрөө credential-ийн утга биш.

Нөхцөлт дан контейнерийн жишээ нь docker run --mount type=bind,source=/secure/api-token,target=/run/secrets/api_token,readonly -e API_TOKEN_FILE=/run/secrets/api_token app:latest. Энэ команд ажиллахын өмнө /secure/api-token файл Docker daemon ажиллаж буй хост дээр байх шаардлагатай. API_TOKEN_FILE хувьсагч зөвхөн файлын замыг заана; апп тэр замаас уншихаар хийгдээгүй бол тохиргоо үр дүнгүй. readonly нь контейнерээс mount-ийг өөрчлөхийг хориглох боловч хост дахь файлын унших эрх, хадгалах хугацаа болон нөөц хуулбарыг зохицуулахгүй.

Нууцын сан ашигладаг орчинд апп эсвэл туслах контейнер эрхээ ашиглан түлхүүрийг ажиллах үед авч болно. Kubernetes-ийн нэг загварт sidecar нууцын сангаас богино настай credential авч, үндсэн контейнертэй хуваалцах санах ойд байрлах volume-д бичээд үе үе шинэчилдэг. Үндсэн апп шинэ утгыг дахин унших эсвэл шинэчлэлтийн дараа дахин асах зохицуулалттай байх хэрэгтэй. Хуучин эрхийг хүчингүй болгох, шинэ эрхийн хүчинтэй хугацааг тогтоох нь файлын mount-оос тусдаа нууцын удирдлагын ажил юм.

Имэж, контейнер, логт мөр үлдсэн эсэхийг шалга

Аудитад Dockerfile-ийг харахаас гадна тараасан имэж болон ажиллаж буй контейнерийг хамруул. Доорх команд дахь ИМЭЖ, КОНТЕЙНЕР гэдэг тэмдэглэгээг өөрийн нэрээр солино. Шалгалтын гаралт өөрөө түлхүүр агуулж болзошгүй тул нийтлэг чат, тасалбар эсвэл CI логт хуулалгүй, зөвшөөрөлтэй орчинд үз.

• Dockerfile болон build context-д ENV, ARG, COPY, .env, багцын бүртгэлийн credential файл байгаа эсэхийг шалга. docker history --no-trunc ИМЭЖ командаар угсралтын түүхийг, docker image inspect ИМЭЖ командаар бэлэн имэжийн Env тохиргоог үз. Эдгээрт утга харагдахгүй байх нь бүх давхарга цэвэр гэсэн баталгаа биш.
• docker inspect КОНТЕЙНЕР-ийн Env хэсэгт түлхүүрийн бодит утга орсон эсэхийг үз. Контейнер дотор ажиллаж буй процессын орчин, алдаа оношлох dump болон аппын логийг мөн шалга; имэж цэвэр байсан ч ажиллах үеийн нууц эдгээр газарт илэрч болно.
• Угсралтын болон CI/CD-ийн логт бүтэн токен хэвлэгдээгүйг шалга. Хэрэв бодит түлхүүр илэрвэл түүнийг хүчингүй болгож шинээр гаргаад, өртсөн имэжийг зассан Dockerfile-ээр дахин угсарч түгээ. Шинэ имэж гаргаснаар хуучин хуулбар, build cache эсвэл өмнөх лог дахь утга автоматаар арилдаггүй.

Мөн уншаарай:

• DMARC-ийг шууд reject бүү болго: нэг mailto алдаа хамгаалалтыг чимээгүй унтраана
• AWS-ийн хөнгөлөлтөд шууд бүү түгж: ашиглаагүй цаг буцаад ирэхгүй
• Монголд компани бүртгүүлэх нь: 15 хоногийн мэдэгдлийг бүү март