امنیت Docker Desktop 4.97؛ بررسی دو اصلاح مهم

Docker Desktop چیست؟

این سرویس چیست؟ Docker Desktop محیطی برای ساخت و اجرای کانتینرها روی سیستم توسعه است و مدیریت imageها، سرویس‌های Compose و محیط‌های تست را ساده می‌کند.

توسعه‌دهنده با Docker Desktop image می‌سازد، سرویس‌های Compose را اجرا می‌کند و رفتار برنامه را پیش از استقرار روی سرور بررسی می‌کند. به همین دلیل، امنیت Docker Desktop فقط موضوع به‌روزرسانی یک برنامه نیست و به حفاظت از کلیدها، لاگ‌ها، imageها و شبکهٔ ماشین مجازی هم مربوط می‌شود.

در این راهنمای امنیت Docker Desktop ۴.۹۷، تمرکز روی اقدام‌هایی است که تیم‌های توسعه و مدیران زیرساخت می‌توانند بدون ایجاد اختلال انجام دهند.

نسخهٔ ۴.۹۷.۰ داکر دسکتاپ در ۲۶ اکتبر ۲۰۲۶ منتشر شد و دو مشکل امنیتی مهم را برطرف کرد. Docker Desktop محیطی برای ساخت، اجرا و مدیریت کانتینرها روی سیستم‌های دسکتاپ است؛ توسعه‌دهنده با آن می‌تواند image بسازد، سرویس‌های چندکانتینری را با Compose اجرا کند و رفتار برنامه را پیش از استقرار روی سرور بررسی کند. چون این محیط به فایل‌های محلی، شبکهٔ ماشین مجازی و گاهی اعتبارنامه‌های سرویس‌های دیگر دسترسی دارد، نگهداری امن لاگ‌ها و جداسازی کانتینرها اهمیت زیادی دارد.

در عمل، امنیت Docker Desktop ۴.۹۷ زمانی کامل‌تر می‌شود که نسخهٔ برنامه، اعتبارنامه‌های فعال و فایل‌های تشخیصی با هم بررسی شوند. برای همین، امنیت Docker Desktop ۴.۹۷ باید در برنامهٔ بازبینی دوره‌ای تیم ثبت و پیگیری شود.

مهم‌ترین اصلاح امنیت Docker Desktop ۴.۹۷

نقص نخست با شناسهٔ CVE-۲۰۲۶-۱۱۴۴۰۹ به نحوهٔ ثبت داده‌های IPC مربوط بود. در نسخه‌های پیش از ۴.۹۷.۰، کلیدهای API سرویس‌های ثالث و توکن‌های OAuth ممکن بود به‌صورت متن ساده در لاگ‌های محلی برنامه یا بسته‌های Diagnostics قرار بگیرند. فردی که به این فایل‌ها دسترسی خواندن داشت، می‌توانست اعتبارنامه‌ها را استخراج کند. این توکن‌ها لزوماً توکن حساب Docker نیستند، اما ممکن است برای دسترسی به سرویس‌هایی مانند رجیستری، ابزارهای CI یا APIهای ابری استفاده شوند.

Docker در نسخهٔ ۴.۹۴ و ۴.۹۵ مسیرهای شناخته‌شدهٔ ثبت اطلاعات را محدود کرده بود، اما لاگ‌ها و crash dumpهای قدیمی همچنان ممکن بود روی میزبان باقی بمانند. نسخهٔ ۴.۹۷ علاوه بر اصلاح مسیر ثبت، پاک‌سازی بخشی از لاگ‌ها و dumpهای موجود را انجام می‌دهد. اگر قبلاً با نسخهٔ ۴.۹۶.x یا قدیمی‌تر بستهٔ Diagnostics ساخته یا برای دیگران ارسال کرده‌اید، آن نسخه‌ها را حذف یا پیش از نگهداری، اطلاعات حساسشان را پاک‌سازی کنید.

به همین دلیل، امنیت Docker Desktop ۴.۹۷ شامل رسیدگی به داده‌های گذشته هم هست، نه فقط نصب فایل جدید.

نقص دوم؛ ریسک برای شبکهٔ ماشین مجازی

مشکل دوم با CVE-۲۰۲۶-۹۹۹۹۹ ثبت شده است. طبق اعلام Docker، یک کانتینر می‌توانست با سوءاستفاده از metadata نادرست checksum در IPv4 و مسیرهایی مانند TUN یا AF_PACKET، به پشتهٔ شبکهٔ ماشین مجازی Docker آسیب بزند. این موضوع نشان می‌دهد که حتی وقتی کانتینرها از میزبان جدا به نظر می‌رسند، نقص در لایهٔ شبکهٔ runtime یا VM می‌تواند مرزهای ایزوله‌سازی را تحت فشار قرار دهد.

چک‌لیست عملی برای تیم‌های توسعه

ابتدا نسخهٔ Docker Desktop را در همهٔ سیستم‌های توسعه و تست inventory کنید و دستگاه‌های پیش از ۴.۹۷.۰ را در اولویت ارتقا قرار دهید. سپس اعتبارنامه‌هایی را که در بازهٔ استفاده از نسخه‌های آسیب‌پذیر ساخته یا روی همان محیط استفاده کرده‌اید، بررسی و در صورت احتمال افشا rotate کنید. فقط حذف لاگ کافی نیست؛ کلید باید در سرویس صادرکننده نیز باطل یا جایگزین شود.

در مرحلهٔ بعد، پوشه‌های Diagnostics، crash dump و آرشیوهای پشتیبان را بررسی کنید. فایل‌هایی که برای پشتیبانی ارسال شده‌اند، ممکن است خارج از میزبان اصلی هم باقی مانده باشند. در محیط‌های تیمی، دسترسی خواندن به این فایل‌ها را محدود و نگهداری آن‌ها را زمان‌دار کنید.

اگر Docker Desktop در چرخهٔ CI یا روی لپ‌تاپ اعضای تیم استفاده می‌شود، نتیجهٔ بررسی را در inventory ثبت کنید. نسخهٔ سیستم‌عامل، نسخهٔ Docker Desktop، نوع imageهای مورد استفاده و محل نگهداری Diagnostics را کنار هم بنویسید. این کار کمک می‌کند بعداً مشخص باشد کدام کلیدها در چه بازه‌ای روی محیط آسیب‌پذیر استفاده شده‌اند. برای پروژه‌های حساس، بهتر است secretها از فایل‌های محلی و متغیرهای محیطی دائمی خارج شوند و از secret store یا توکن‌های کوتاه‌عمر استفاده شود.

برای Sandboxهای Docker نیز به‌روزرسانی CLI به‌تنهایی کافی نیست. Docker توصیه می‌کند imageهای cache‌شده با image جدید جایگزین شوند و Sandboxهای موجود با image به‌روزشده بازسازی یا به‌صورت داخل همان محیط به‌روزرسانی شوند. پیش از بازسازی، فایل‌های لازم و تغییرات محلی را ذخیره کنید؛ حذف Sandbox می‌تواند filesystem آن را از بین ببرد.

جمع‌بندی

امنیت Docker Desktop ۴.۹۷ فقط یک ارتقای نسخه‌ای نیست؛ فرصتی برای بازبینی چرخهٔ عمر secretها، لاگ‌ها و imageهای cache‌شده است. اقدام درست شامل ارتقا، چرخش کلیدهای مشکوک، پاک‌سازی Diagnostics قدیمی و بازسازی Sandboxهای قدیمی می‌شود. جزئیات CVEها و دستورالعمل‌های رسمی را از صفحهٔ اعلامیه‌های امنیتی Docker دنبال کنید و این تغییرات را ابتدا در محیط staging آزمایش کنید.

برای آشنایی با موضوعات مرتبط، راهنمای امنیت کانتینرها و به‌روزرسانی‌های زیرساختی در تکتاز مگ را هم ببینید. نکتهٔ مهم این است که امنیت Docker Desktop ۴.۹۷ را به یک تغییر منفرد محدود نکنیم: اعتبارنامه، لاگ، image و شبکه باید در یک بازبینی واحد بررسی شوند. اگر بخشی از تیم هنوز امکان ارتقا ندارد، دسترسی به Diagnostics را محدود کنید، imageهای غیرضروری را پاک‌سازی نکنید مگر اینکه نسخهٔ جایگزین آماده باشد، و زمان‌بندی مهاجرت را مستند کنید.

این رویکرد مرحله‌ای، اجرای امنیت Docker Desktop ۴.۹۷ را برای تیم‌هایی که زیرساخت قدیمی یا پنجرهٔ نگهداری محدود دارند، قابل‌کنترل‌تر می‌کند.

منبع: Docker Security Announcements