https://virgool.ir/feed/@sepehrfciDevOps Engineer | Telegram : @SepiFafa2026-11-10 18:43:10https://files.virgool.ir/upload/users/3642660/avatar/kLhPVd.jpghttps://virgool.ir/@sepehrfcihttps://virgool.ir/@sepehrfci/multi-tenancy-در-kubernetes-چرا-namespace-به-تنهایی-مرز-امنیتی-نیست-kukoybefwkypاستفاده از یک cluster مشترک برای چند تیم یا چند محصول، از نظر هزینه و سرعت توسعه جذاب است. تیم‌ها می‌توانند از nodeها، registry، monitoring و ابزارهای مشترک استفاده کنند و بدون ساختن زیرساخت جداگانه، workloadهای خود را deploy کنند.اما از لحظه‌ای که چند گروه مستقل روی یک cluster قرار می‌گیرند، سؤال مهمی مطرح می‌شود:اگر یکی از تیم‌ها یا workloadهای آن compromise شود، دقیقاً چه چیزی از تیم‌ها و سرویس‌های دیگر جدا می‌ماند؟اینجا با مفهوم چندمستاجری (Multi-Tenancy) روبه‌رو هستیم. منظور از tenant می‌تواند یک تیم داخلی، یک محصول، یک واحد سازمانی یا حتی مشتری مستقل باشد.چندمستاجری فقط ساختن namespaceهای جدا نیست. باید هویت، دسترسی، شبکه، منابع، secretها، nodeها، logها و مسیر deploy طوری طراحی شوند که هر tenant فقط به محدودهٔ خودش دسترسی داشته باشد.سه مدل اصلی چندمستاجریقبل از نوشتن policy باید مشخص کنیم چه نوع جداسازی لازم داریم. همهٔ محیط‌ها به یک سطح isolation نیاز ندارند.چند تیم در یک clusterدر این مدل، تیم‌های مختلف یک سازمان از cluster مشترک استفاده می‌کنند. معمولاً namespace، RBAC و NetworkPolicy بخش اصلی جداسازی هستند.این مدل برای تیم‌های داخلی مناسب است، به‌شرط اینکه همهٔ تیم‌ها سطح اعتماد تقریباً مشابهی داشته باشند و دسترسی administratorها کنترل شده باشد.چند محیط یا محصول در یک clusterبرای مثال، staging، development و production یا چند محصول مستقل در یک cluster اجرا می‌شوند. مشکل اصلی این است که خطای یک محیط نباید به محیط حساس‌تر سرایت کند.در این مدل، جداسازی production از development معمولاً باید بیشتر از یک namespace ساده باشد؛ مخصوصاً اگر توسعه‌دهندگان بتوانند کد دلخواه در محیط development اجرا کنند.چند مشتری مستقل روی یک clusterدر این مدل، tenantها ممکن است به یکدیگر اعتماد نداشته باشند. اگر یک مشتری compromise شود یا عمداً رفتار مخرب داشته باشد، isolation باید بسیار سخت‌گیرانه‌تر طراحی شود.برای مشتریان مستقل، استفاده از node pool جدا، cluster جدا یا حتی حساب cloud جدا ممکن است ارزش هزینهٔ اضافی را داشته باشد.Namespace چه چیزی را جدا می‌کند؟Namespace برای نام‌گذاری، اعمال RBAC، محدود کردن quota و سازمان‌دهی resourceها بسیار مفید است. اما namespace یک دیوار کامل بین workloadها نیست.اگر فقط namespace بسازیم و کنترل دیگری اعمال نکنیم، ممکن است هنوز این اتفاق‌ها ممکن باشند:Podها از namespaceهای دیگر به سرویس‌ها متصل شوند.یک Service Account به resourceهای خارج از namespace دسترسی داشته باشد.یک Pod منابع CPU و memory کل node را مصرف کند.secretهای حساس در namespace اشتباه قرار بگیرند.tenant بتواند workload را روی node مشترک با tenant حساس اجرا کند.developer بتواند تنظیمات privileged ایجاد کند.log یا metric یک tenant، دادهٔ tenant دیگر را نمایش دهد.پس namespace را باید یک لایه از isolation بدانیم، نه مرز نهایی اعتماد.مدل تهدید را قبل از policy مشخص کنیدامنیت چندمستاجری بدون مدل تهدید معمولاً به مجموعه‌ای از policyهای پراکنده تبدیل می‌شود. ابتدا باید مشخص کنیم از چه چیزی دفاع می‌کنیم.چند سؤال پایه:آیا tenantها به یکدیگر اعتماد دارند؟آیا tenant می‌تواند کد دلخواه deploy کند؟آیا tenant به node یا cloud credential دسترسی دارد؟آیا administratorهای cluster کاملاً قابل اعتماد و محدود هستند؟آیا هدف ما جلوگیری از خطای تصادفی است یا دفاع در برابر tenant مخرب؟آیا دادهٔ tenantها باید از نظر compliance کاملاً جدا باشد؟در صورت compromise شدن یک Pod، چه سطحی از خسارت قابل‌قبول است؟اگر tenantها کاملاً نامطمئن باشند، namespace مشترک و node مشترک ممکن است سطح isolation لازم را فراهم نکند. در این حالت باید به سمت cluster یا حساب cloud جدا حرکت کرد.الگوی پیشنهادی برای onboarding یک tenantبه‌جای اینکه هر تیم دستی namespace و permission بسازد، onboarding را به یک الگوی استاندارد تبدیل کنید.برای هر tenant می‌توان این resourceها را به‌صورت خودکار ایجاد کرد:namespace اختصاصیService Accountهای محدودRole و RoleBinding همان namespaceResourceQuotaLimitRangeNetworkPolicy پیش‌فرضpolicyهای admissionlabel و annotationهای مالکیتمسیر log و metric مشخصowner و زمان بازبینیدر این مدل، tenant جدید از روز اول baseline امنیتی دارد و مجبور نیست هر policy را به‌صورت دستی کشف کند.RBAC؛ tenant نباید administrator خودش باشددر محیط چندمستاجری، permission باید در محدودهٔ tenant باقی بماند. استفاده از ClusterRoleBinding برای تیم‌های application معمولاً باید exception باشد.نمونهٔ سادهٔ دسترسی محدود:apiVersion: rbac.authorization.k8s.io/v1 kind: Role metadata: name: orders-deployer namespace: tenant-orders rules: - apiGroups: ["apps"] resources: ["deployments"] verbs: ["get", "list", "watch", "create", "update", "patch"] - apiGroups: [""] resources: ["pods", "services", "configmaps"] verbs: ["get", "list", "watch"] این Role عمداً دسترسی‌هایی مثل موارد زیر را ندارد:خواندن همهٔ Secretهاتغییر RoleBindingایجاد Pod در namespace دیگردسترسی به Nodeهااجرای command در هر Podتغییر policyهای clusterحتی در namespace خودش هم باید permissionها را بر اساس نیاز واقعی محدود کنیم. اینکه تیم مالک namespace است، به معنی نیاز آن به cluster-admin نیست.Service Account را برای هر workload جدا کنیداستفاده از یک Service Account مشترک برای همهٔ deploymentهای tenant، دامنهٔ حادثه را بزرگ‌تر می‌کند. اگر یکی از applicationها compromise شود، token آن ممکن است برای سرویس‌های دیگر هم معتبر باشد.برای مثال، این سه workload بهتر است identity جدا داشته باشند:orders-apiorders-workerorders-reportingممکن است worker نیاز به خواندن queue داشته باشد، اما API نیازی به دسترسی به resourceهای Kubernetes نداشته باشد. هویت مشترک این تفاوت را از بین می‌برد.برای workloadهایی که به Kubernetes API نیاز ندارند، token را mount نکنید:spec: automountServiceAccountToken: false NetworkPolicy؛ جداسازی واقعی ارتباط‌هادر clusterهای چندمستاجری، policy شبکه باید از حالت «همه‌چیز مجاز است» به حالت «فقط ارتباط موردنیاز مجاز است» نزدیک شود.یک baseline مناسب معمولاً شامل این دو مرحله است:deny همهٔ ingress و egressهاباز کردن ارتباط‌های ضروری به‌صورت صریحنمونهٔ deny پیش‌فرض در یک namespace:apiVersion: networking.k8s.io/v1 kind: NetworkPolicy metadata: name: default-deny namespace: tenant-orders spec: podSelector: {} policyTypes: - Ingress - Egress بعد باید ارتباط‌های لازم را اضافه کنیم؛ مثلاً API فقط از ingress controller درخواست بگیرد و فقط به database یا cache مجاز متصل شود.اگر CNI مورد استفاده NetworkPolicy را enforce نکند، وجود YAML امنیت ایجاد نمی‌کند. باید در محیط واقعی تست شود که policy واقعاً ارتباط را قطع یا مجاز می‌کند.جداسازی بین tenantها را آزمایش کنیددر محیط تست، فقط به بررسی manifest اکتفا نکنید. باید سناریوهای ارتباطی را واقعاً امتحان کنید:Pod tenant A نباید به service tenant B وصل شود.Pod tenant A نباید به database tenant B دسترسی داشته باشد.DNS resolution سرویس‌های حساس باید محدود باشد.egress به اینترنت باید فقط برای مقصدهای لازم فعال باشد.Pod نباید بتواند به metadata service متصل شود.تست منفی به اندازهٔ تست مثبت مهم است. اگر فقط بررسی کنیم سرویس مجاز کار می‌کند، نمی‌فهمیم آیا ارتباط غیرمجاز هم باز مانده است یا نه.ResourceQuota؛ امنیت availability هم هستدر multi-tenancy، مصرف منابع فقط مسئلهٔ هزینه نیست. یک tenant می‌تواند با ایجاد Podهای زیاد یا مصرف memory بالا، سرویس tenantهای دیگر را مختل کند.نمونهٔ محدودیت:apiVersion: v1 kind: ResourceQuota metadata: name: tenant-orders-quota namespace: tenant-orders spec: hard: requests.cpu: "8" requests.memory: 16Gi limits.cpu: "16" limits.memory: 32Gi pods: "40" این quota جلوی همهٔ حملات denial of service را نمی‌گیرد، اما جلوی مصرف بی‌حدومرز منابع namespace را می‌گیرد و ظرفیت هر tenant را قابل‌پیش‌بینی‌تر می‌کند.LimitRange؛ جلوی Pod بدون محدودیت را بگیریداگر tenant بتواند Pod بدون requests و limits deploy کند، scheduler و nodeها تصویر دقیقی از مصرف آینده ندارند.apiVersion: v1 kind: LimitRange metadata: name: tenant-defaults namespace: tenant-orders spec: limits: - type: Container default: cpu: "1" memory: 1Gi defaultRequest: cpu: "100m" memory: 256Mi مقدارهای پیش‌فرض باید بر اساس رفتار واقعی سرویس‌ها انتخاب شوند. limit غیرواقعی می‌تواند باعث OOM یا throttling شود و تیم را به سمت خاموش کردن policy سوق دهد.Node مشترک یا Node اختصاصی؟حتی اگر RBAC و شبکه درست باشند، workloadهای چند tenant ممکن است روی یک node اجرا شوند. این موضوع برای تیم‌های داخلی با سطح اعتماد مشابه معمولاً قابل‌قبول است، اما برای tenantهای مستقل یا workloadهای بسیار حساس باید دقیق‌تر بررسی شود.گزینه‌ها:node مشترکهزینه کمتر و استفادهٔ بهتر از منابع، اما isolation ضعیف‌تر در برابر خطاهای runtime و حمله‌های سطح node.node pool جدابرای workloadهای حساس‌تر isolation عملیاتی بهتری می‌دهد، اما هزینه و پیچیدگی بیشتری دارد.cluster جداقوی‌ترین جداسازی زیرساختی، اما با هزینهٔ بیشتر در مدیریت، مانیتورینگ و upgrade.قاعدهٔ مهم این است که level of trust و حساسیت داده باید انتخاب معماری را تعیین کند، نه صرفاً راحتی deploy.Taint و Toleration ابزار جداسازی هستند، نه مجوز امنیتیمی‌توان nodeهای حساس را با taint علامت‌گذاری کرد و فقط workloadهای مجاز را روی آن‌ها schedule کرد. اما taint به‌تنهایی یک مرز امنیتی کامل نیست.اگر tenant بتواند خودش toleration اضافه کند یا روی node label مورداعتماد اثر بگذارد، جداسازی بی‌معنی می‌شود. بنابراین scheduling policy باید با admission control و RBAC همراه باشد.همچنین باید بررسی شود که tenant امکان ایجاد DaemonSet یا workloadی را ندارد که روی تعداد زیادی node اجرا شود.Secretها در محیط چندمستاجریقرار دادن همهٔ secretها در یک namespace یا استفاده از credential مشترک، حادثه را بزرگ می‌کند. هر tenant باید فقط secretهای خودش را ببیند.برای محیط‌های حساس‌تر:secret manager مسیر tenant جدا داشته باشد.identity workload به namespace و application محدود شود.secretهای database، queue و API جدا باشند.log و trace مقدار secret را چاپ نکنند.rotation tenantها مستقل انجام شود.اگر tenant A بتواند credential tenant B را بخواند، دیگر با multi-tenancy واقعی مواجه نیستیم؛ فقط resourceها را نام‌گذاری کرده‌ایم.Admission Control؛ جلوگیری از تنظیمات خطرناکدر cluster مشترک، باید قبل از اجرای workload موارد پرخطر کنترل شوند:privileged: truehostPath حساسhostNetwork یا hostPIDcapabilityهای غیرضروریimage خارج از registry مجازService Account پیش‌فرضنداشتن owner و tenant labelنداشتن resource limitpolicy باید tenant را هم بشناسد. برای مثال، tenant معمولی نباید بتواند workloadی بسازد که روی node اختصاصی امنیتی اجرا شود یا به namespace دیگر دسترسی دارد.خطای policy باید قابل‌فهم باشد. پیام «admission denied» برای توسعه‌دهنده کافی نیست؛ باید گفته شود کدام rule نقض شده و چگونه اصلاح شود.مثال عملی: پلتفرمی شبیه دیجی‌کالافرض کنید تیم‌های catalog، orders و recommendation در یک cluster مشترک کار می‌کنند. سرویس سفارش به دادهٔ حساس‌تری دسترسی دارد و نباید با recommendation در یک سطح اعتماد قرار بگیرد.طراحی پیشنهادی:namespace جدا برای هر تیمRBAC محدود به namespaceNetworkPolicy با deny پیش‌فرضdatabase مستقل یا حداقل credential مستقلnode pool جدا برای workloadهای سفارش در صورت نیازadmission policy سخت‌گیرانه‌تر برای namespace سفارشlog و metric با tenant label و کنترل دسترسیاگر recommendation compromise شود، باید نتواند به database سفارش، Secret پرداخت یا Kubernetes API سرویس orders دسترسی پیدا کند.مثال عملی: پلتفرمی شبیه فیلیموفرض کنید workloadهای api، transcoder و media-worker نیازهای متفاوتی دارند. transcoder ممکن است CPU و disk زیادی مصرف کند و media-worker به object storage دسترسی داشته باشد.اگر همهٔ آن‌ها در namespace و Service Account مشترک اجرا شوند:محدود کردن مصرف یک workload دشوار می‌شود.credentialها بیش از نیاز توزیع می‌شوند.تشخیص رفتار غیرعادی سخت‌تر می‌شود.یک compromise می‌تواند چند مسیر را باز کند.با namespace، quota، identity و policy جدا، هر workload دامنهٔ محدودتری خواهد داشت. transcoder می‌تواند به منابع پردازشی دسترسی داشته باشد، اما نباید token media-worker یا API مدیریتی را ببیند.مثال عملی: سرویس‌های حمل‌ونقل شبیه اسنپ و تپسیفرض کنید سرویس‌های trip، driver-location و notification releaseهای متفاوت و مقیاس‌های متفاوت دارند.یک tenant boundary خوب باید مشخص کند:هر تیم چه resourceهایی را deploy می‌کند.چه سرویس‌هایی به هم ارتباط دارند.کدام workloadها اینترنت خروجی لازم دارند.کدام secretها کوتاه‌عمر هستند.سقف مصرف CPU و memory هر تیم چقدر است.در زمان incident کدام تیم مالک isolate کردن workload است.اگر این موارد فقط در ذهن افراد باشد، با تغییر اعضای تیم یا ایجاد یک deployment اضطراری، مرزهای امنیتی از بین می‌روند. باید در policy، Git و runbook ثبت شوند.log و metric هم باید چندمستاجری باشندگاهی خود Kubernetes درست ایزوله شده، اما observability کل دادهٔ tenantها را به همه نشان می‌دهد.مواردی که باید بررسی شوند:آیا developer tenant A می‌تواند logهای tenant B را ببیند؟آیا metricها نام سرویس‌ها یا customerها را افشا می‌کنند؟آیا trace شامل token یا دادهٔ حساس tenant دیگر است؟آیا dashboardها access control دارند؟آیا alert routing به تیم درست ارسال می‌شود؟لاگ مرکزی باید tenant label داشته باشد، اما label به‌تنهایی access control نیست. سیستم log و metric نیز باید permission و retention مناسب داشته باشد.Backup و disaster recovery را فراموش نکنیددر چندمستاجری، backup می‌تواند دادهٔ همهٔ tenantها را کنار هم نگه دارد. اگر دسترسی به backup بیش از حد گسترده باشد، شکست یک account می‌تواند دادهٔ چندین tenant را افشا کند.باید مشخص شود:backupها چگونه رمزنگاری می‌شوند.چه کسی می‌تواند restore کند.آیا restore tenant جدا امکان‌پذیر است.آیا backup شامل Secret و دادهٔ حساس است.retention هر نوع داده چقدر است.آزمایش restore با چه دوره‌ای انجام می‌شود.Backup امن فقط داشتن نسخهٔ کپی نیست؛ باید بتوانیم آن را با کمترین دسترسی لازم restore کنیم.ارتقا و تغییر policy بدون ایجاد اختلالدر cluster مشترک، تغییر policy روی یک tenant می‌تواند روی tenantهای دیگر اثر بگذارد. برای همین باید تغییرات را مرحله‌ای اجرا کرد:policy را در audit mode فعال کنید.violationها را براساس tenant دسته‌بندی کنید.workloadهای ناسازگار را اصلاح کنید.policy را روی یک namespace آزمایشی enforce کنید.نتیجه را بررسی کنید.rollout را تدریجی انجام دهید.exceptionها را owner و تاریخ انقضا بدهید.تغییر مستقیم policy سراسری در ساعت شلوغی، بدون rollback، ریسک عملیاتی بزرگی ایجاد می‌کند.چه زمانی cluster مشترک انتخاب بدی است؟cluster مشترک همیشه اقتصادی‌تر یا بهتر نیست. جدا کردن tenantها در clusterهای مستقل ممکن است منطقی باشد اگر:tenantها به هم اعتماد ندارند.داده‌ها حساس یا مشمول الزامات جدی هستند.تیم‌ها administrator مستقل دارند.workloadها به capabilityهای پرخطر نیاز دارند.تفاوت نسخه و چرخهٔ upgrade زیاد است.یک حادثهٔ tenant نباید روی دیگری اثر بگذارد.مشتریان بیرونی باید مرز اعتماد جدا داشته باشند.هزینهٔ cluster جدا را باید با هزینهٔ incident، توقف سرویس و پیچیدگی policy مقایسه کرد؛ نه فقط با هزینهٔ VM یا node.چک‌لیست ارزیابی چندمستاجریآیا هر tenant namespace مستقل دارد؟آیا tenant به cluster-admin یا ClusterRoleBinding غیرضروری دسترسی دارد؟آیا Service Accountها بین workloadها مشترک نیستند؟آیا token غیرضروری automount نمی‌شود؟آیا NetworkPolicy deny پیش‌فرض وجود دارد؟آیا ارتباط بین tenantها تست منفی شده است؟آیا ResourceQuota و LimitRange اعمال شده‌اند؟آیا tenant نمی‌تواند privileged یا hostPath حساس ایجاد کند؟آیا secretها با identity و مسیر جدا مدیریت می‌شوند؟آیا node pool جدا برای workloadهای حساس لازم است؟آیا log، metric و trace access control دارند؟آیا backup و restore tenantها قابل تفکیک است؟آیا exceptionها owner و تاریخ انقضا دارند؟آیا انتخاب cluster مشترک با مدل تهدید سازگار است؟جمع‌بندیچندمستاجری در Kubernetes یک feature نیست؛ یک تصمیم معماری است. Namespace شروع خوبی است، اما برای ایجاد مرز واقعی باید RBAC، Service Account، NetworkPolicy، quota، admission، secret management، node isolation و observability کنار هم قرار بگیرند.هدف این نیست که همهٔ tenantها را از یکدیگر کاملاً جدا کنیم، بدون اینکه نیاز واقعی و هزینه را در نظر بگیریم. هدف این است که سطح isolation با سطح اعتماد و حساسیت داده متناسب باشد.برای تیم‌های داخلی با اعتماد مشابه، namespace و policyهای مناسب ممکن است کافی باشد. برای مشتریان مستقل یا workloadهای حساس، node pool یا cluster جدا تصمیم منطقی‌تری است.قاعدهٔ نهایی این است:اگر در یک cluster مشترک نمی‌توانیم توضیح دهیم compromise شدن tenant A دقیقاً تا کجا می‌تواند پیش برود، هنوز مرزهای چندمستاجری را درست طراحی نکرده‌ایم.سپهر فصیحی - Sepehr Fassihiسپهر فصیحی - Sepehr FassihiThu, 08 Oct 2026 12:00:55 +0330https://virgool.ir/@sepehrfci/secret-در-kubernetes-secret-را-کجا-نگه-داریم-که-فردا-دردسر-نشود-op8cnotuhotuخیلی از پروژهها با یک اشتباه کوچک شروع میکنند:env: - name: DATABASE_PASSWORD value: "P@ssw0rd-Production" این manifest شاید در محیط آزمایشی سریع جواب بدهد، اما اگر وارد Git، لاگ CI/CD یا registry شود، رمز عبور دیگر secret نیست؛ فقط یک رشتهٔ قابلکپی است که ممکن است مدتها در تاریخچهٔ سیستم باقی بماند.در Kubernetes، مدیریت Secret فقط به این سؤال محدود نمیشود که «رمز را کجا بنویسیم؟». باید بدانیم چه کسی آن را میخواند، چگونه به Pod میرسد، کجا log میشود، چه زمانی rotate میشود و بعد از افشا چگونه سریع بیاعتبارش کنیم.Secret در Kubernetes دقیقاً چیست؟کوبر resourceای به نام Secret دارد که برای نگهداری دادههایی مثل این موارد استفاده میشود:رمز عبور databasetoken سرویسهای بیرونیcredential مربوط به registryکلید خصوصی TLSAPI keycredential اتصال به message brokerنمونهٔ ساده:apiVersion: v1 kind: Secret meta "list", "watch"] اگر این Role به Service Account یک application داده شود، application میتواند Secretهای زیادی را بخواند. تا جای ممکن باید دسترسی به Secretها در سطح معماری محدود شود؛ نه اینکه صرفاً به همهٔ Podهای namespace اعتماد کنیم.همچنین permissionهای list و watch را با دقت بررسی کنید. یک application ممکن است فقط به خواندن یک مقدار مشخص نیاز داشته باشد، اما list کردن میتواند نام و metadata تمام Secretها را در اختیارش قرار دهد.اگر application واقعاً نیازی به Kubernetes API ندارد، automountServiceAccountToken: false را فعال کنید:spec: automountServiceAccountToken: false کم کردن credentialهای غیرضروری یکی از سادهترین راههای کاهش دامنهٔ حمله است.Encryption at Rest برای etcdSecretهای Kubernetes در نهایت در etcd نگهداری میشوند. اگر encryption at rest فعال نباشد، دسترسی مستقیم یا backup نامناسب etcd میتواند مقدار Secretها را در معرض خطر قرار دهد.چند اقدام مهم:encryption at rest را فعال کنید.کلید encryption را در محل امن نگهداری کنید.دسترسی مستقیم به etcd را محدود کنید.backupها را رمزنگاری و دسترسی آنها را audit کنید.restore backup را آزمایش کنید.فعال کردن encryption at rest به این معنی نیست که administrator دارای دسترسی API دیگر نمیتواند Secret را بخواند. این کنترل بیشتر برای حفاظت از دادهٔ ذخیرهشده و backupهاست.rotation؛ تعویض رمز بدون خاموشی سرویسRotation باید از ابتدا در طراحی application دیده شود. اگر application فقط هنگام startup Secret را بخواند، تغییر Secret ممکن است تا restart شدن Pod اعمال نشود.قبل از rotation در production مشخص کنید:application تغییر credential را بدون restart میپذیرد یا نه.نسخهٔ قدیمی و جدید چه مدت همزمان معتبر هستند.آیا connection pool باید دوباره ساخته شود.چه کسی rotation را اجرا و تأیید میکند.در صورت شکست، rollback چگونه انجام میشود.یک روش معمول:credential جدید ایجاد شود.application بتواند همزمان credential جدید را مصرف کند.rollout تدریجی انجام شود.مصرف credential قدیمی monitor شود.credential قدیمی revoke شود.ترتیب مهم است. اگر اول credential قدیمی را revoke کنیم و هنوز همهٔ Podها مقدار جدید را نگرفته باشند، downtime ایجاد میشود.اگر Secret لو رفت، چه کار کنیم؟در زمان افشا، هدف اصلی پاک کردن متن secret از صفحه نیست؛ هدف بیاعتبار کردن آن است.runbook پیشنهادی:مشخص کنید چه secretی و در کجا افشا شده است.credential را فوراً revoke یا rotate کنید.log، Git history، artifact و backupهای در معرض خطر را بررسی کنید.usage و access log مربوط به credential را بررسی کنید.workloadهای مصرفکننده را شناسایی کنید.مقدار جدید را deploy و rollout کنید.secret قدیمی را از همهٔ منابع حذف و بیاعتبار کنید.علت ریشهای را اصلاح کنید تا تکرار نشود.اگر secret مربوط به registry باشد، باید image pull، pipeline و runnerها هم بررسی شوند. اگر secret مربوط به database باشد، audit query و loginهای مشکوک هم اهمیت پیدا میکنند.Secret در لاگها؛ مشکل پنهان و رایجگاهی Secret در manifest نیست، اما در لاگ دیده میشود:Connecting to database with password=P@ssw0rd-Productionاین مشکل باید در چند لایه کنترل شود:application نباید credential را log کند.خطاها نباید URL حاوی token را چاپ کنند.tracing باید headerهای حساس را mask کند.log collector باید الگوهای secret را شناسایی کند.دسترسی به logها باید مانند دادهٔ حساس کنترل شود.Mask کردن در سیستم log مفید است، اما جایگزین اصلاح application نیست؛ ممکن است secret قبل از رسیدن به collector در یک فایل یا agent ثبت شده باشد.چکلیست عملی قبل از productionآیا هیچ secret واقعی در Git یا Dockerfile وجود ندارد؟آیا Secretها با Base64 با رمزنگاری اشتباه گرفته نشدهاند؟آیا encryption at rest برای etcd فعال است؟آیا backupهای etcd محافظت میشوند؟آیا هر workload فقط Secretهای لازم خودش را میخواند؟آیا list و watch روی Secretها واقعاً ضروریاند؟آیا Service Account غیرضروری حذف شده است؟آیا secretها در log، trace و error response mask میشوند؟آیا rotation بدون downtime آزمایش شده است؟آیا credential قدیمی بعد از rotation revoke میشود؟آیا برای افشای secret runbook آماده وجود دارد؟آیا access log مربوط به خواندن Secret بررسی میشود؟جمعبندیSecret Management فقط ساختن یک resource با نام Secret نیست. باید کل چرخهٔ عمر credential را مدیریت کنیم: تولید، ذخیرهسازی، انتقال، مصرف، rotation، audit و revoke.برای سرویسهای ساده شاید Kubernetes Secret با RBAC محدود و encryption at rest کافی باشد. برای سرویسهای حساستر، secret manager خارجی، هویت workload، token کوتاهعمر و rotation خودکار انتخاب بهتری است.سه قاعدهٔ ساده را همیشه در نظر بگیرید:Secret را در Git و image قرار ندهید.هر workload فقط به credential موردنیاز خودش دسترسی داشته باشد.هر credential باید قابل rotation و revoke باشد.اگر یک رمز عبور را نمیتوان سریع عوض کرد، احتمالاً آن را بهعنوان یک وابستگی دائمی طراحی کردهایم، نه یک secret قابلمدیریت.سپهر فصیحی - Sepehr Fassihiسپهر فصیحی - Sepehr FassihiTue, 29 Sep 2026 13:14:07 +0330https://virgool.ir/@sepehrfci/امنیت-زمان-اجرا-در-kubernetes-وقتی-image-سالم-است-اما-container-مشکوک-رفتار-می-کند-hkcy6okhksorفرض کنید یک image تمام اسکن‌های امنیتی را با موفقیت پشت سر گذاشته، signature معتبر دارد و با digest مشخص در production deploy شده است. چند ساعت بعد، یکی از containerها رفتاری نشان می‌دهد که در زمان build قابل مشاهده نبوده است:process جدیدی مثل curl یا bash اجرا می‌شود.container تلاش می‌کند از داخل به metadata service وصل شود.فایلی در مسیر حساس host یا container تغییر می‌کند.یک Pod به‌صورت غیرمنتظره به Kubernetes API درخواست می‌فرستد.process اصلی application یک shell فرزند ایجاد می‌کند.در این نقطه، image scanning و admission control دیگر کافی نیستند. باید بدانیم در زمان اجرا چه اتفاقی داخل cluster می‌افتد.این حوزه را معمولاً امنیت زمان اجرا یا Runtime Security می‌نامیم. هدف آن این نیست که فقط بعد از وقوع حادثه گزارش تهیه کنیم؛ هدف این است که رفتار غیرعادی را سریع ببینیم، دامنهٔ حادثه را محدود کنیم و شواهد لازم برای پاسخ‌گویی داشته باشیم.چرا امنیت زمان اجرا لازم است؟کنترل‌های قبل از deploy دربارهٔ چیزی صحبت می‌کنند که انتظار داریم اجرا شود. Runtime Security دربارهٔ چیزی صحبت می‌کند که واقعاً در حال اجراست.یک image scanner ممکن است بگوید packageهای image آسیب‌پذیری شناخته‌شده‌ای ندارند. اما scanner معمولاً نمی‌بیند که:application در اثر یک ورودی مخرب command اجرا کرده است.یک مهاجم credential داخل process را استخراج کرده است.container در حال برقراری ارتباط با مقصدی ناشناخته است.یک shell از داخل process اصلی ایجاد شده است.یک workload در حال خواندن فایل‌هایی خارج از رفتار معمول خود است.این‌ها رفتارهای runtime هستند و باید در زمان اجرا مشاهده شوند.یک سناریوی قابل لمسفرض کنید سرویس order-api در یک فروشگاه آنلاین بزرگ اجرا می‌شود. این سرویس در حالت عادی باید:process اصلی application را اجرا کند.به database و سرویس پرداخت دسترسی داشته باشد.روی پورت مشخص listen کند.log تولید کند.به registry یا اینترنت عمومی دسترسی مستقیم نداشته باشد.حالا یک آسیب‌پذیری در endpoint جست‌وجو باعث می‌شود مهاجم بتواند command دلخواه اجرا کند. مهاجم ابتدا sh اجرا می‌کند، سپس با curl یک فایل دانلود می‌کند و در نهایت تلاش می‌کند به metadata service یا Kubernetes API متصل شود.اگر فقط image را اسکن کرده باشیم، احتمالاً این زنجیره را نمی‌بینیم. اما اگر برای order-api baseline رفتاری داشته باشیم، این چند رویداد به‌سرعت مشکوک می‌شوند:اجرای sh توسط process اصلی applicationاجرای curl داخل containerایجاد فایل اجرایی در /tmpاتصال خروجی به مقصد جدیدتلاش برای خواندن token یا metadataهر رویداد به‌تنهایی ممکن است false positive باشد؛ کنار هم قرار گرفتن آن‌ها می‌تواند نشانهٔ جدی compromise باشد.Runtime Security فقط لاگ جمع کردن نیستسه قابلیت را باید از هم جدا کنیم:مشاهدهچه processهایی اجرا شدند؟ چه فایل‌هایی خوانده یا تغییر داده شدند؟ چه اتصال‌هایی ایجاد شد؟تشخیصآیا رفتار مشاهده‌شده با رفتار مورد انتظار workload سازگار است؟پاسخپس از تشخیص، آیا می‌توانیم workload را isolate، متوقف یا credentialهای آن را revoke کنیم؟سیستمی که فقط log تولید می‌کند اما alert قابل‌استفاده ندارد، در زمان incident کمک محدودی می‌کند. از طرف دیگر، سیستمی که هر رفتار را به‌عنوان حمله اعلام کند، alert fatigue ایجاد می‌کند و تیم به هشدارها بی‌اعتماد می‌شود.Falco چه کاری انجام می‌دهد؟Falco یک ابزار تشخیص رفتار مشکوک در Linux و Kubernetes است. ایدهٔ اصلی آن بررسی eventهای سیستم و مقایسهٔ آن‌ها با ruleهای امنیتی است.برای مثال می‌توان ruleای تعریف کرد که اجرای shell داخل container production را گزارش کند:- rule: Shell Spawned in Production Container desc: Detect a shell started inside a production container condition: > container_started and evt.type in (execve, execveat) and proc.name in (sh, bash, zsh) and k8s.ns.name = "production" output: > Shell spawned in production container (user=%user.name command=%proc.cmdline container=%container.name pod=%k8s.pod.name namespace=%k8s.ns.name image=%container.image.repository) priority: WARNING tags: [container, kubernetes, shell] این rule به‌تنهایی نمی‌گوید حمله قطعی رخ داده است. ممکن است تیم عملیات برای debug وارد container شده باشد. اما باید event ثبت شود و در صورت production بودن workload، بررسی شود.Rule خوب باید context داشته باشدهشدار «shell اجرا شد» به‌تنهایی اطلاعات کمی دارد. برای تصمیم‌گیری بهتر باید بدانیم:نام Pod و namespace چیست؟image و digest کدام است؟process والد چه بوده است؟چه کاربری command را اجرا کرده است؟command از طریق kubectl exec آمده یا application آن را ساخته است؟مقصد شبکه‌ای بعدی کجاست؟آیا این رفتار قبلاً هم دیده شده است؟برای مثال، اجرای shell در یک Pod ابزار debug ممکن است عادی باشد، اما اجرای bash از داخل process یک payment API در production، severity متفاوتی دارد.قانون detection باید تا حد امکان context داشته باشد؛ وگرنه تیم با حجم زیادی از هشدارهای مبهم مواجه می‌شود.چند رفتار مهم که باید پایش شونداجرای process غیرمنتظرهاگر container فقط باید Java یا Node.js اجرا کند، اجرای bash، nc، curl، wget، python یا ابزارهای مشابه باید بررسی شود.تغییر فایل‌های حساستغییر فایل‌هایی مثل این‌ها می‌تواند مهم باشد:فایل‌های تنظیمات applicationفایل‌های startupمسیرهای credentialفایل‌های مربوط به SSHفایل‌های mountشده از Secretمسیرهای حساس host در صورت وجود mountایجاد فایل اجرایی در مسیر موقتنوشتن و اجرای binary از /tmp یا مسیرهای قابل‌نوشتن همیشه حمله نیست، اما در کنار download از شبکه یا اجرای shell باید severity بالاتری بگیرد.اتصال شبکه‌ای غیرمنتظرهیک سرویس داخلی ممکن است فقط به database و چند API مشخص نیاز داشته باشد. اتصال به IP ناشناخته، اینترنت عمومی یا metadata service باید alert ایجاد کند.دسترسی به Kubernetes APIاگر application به Kubernetes API نیاز ندارد، هر request از داخل آن به API Server باید بررسی شود؛ به‌خصوص اگر با token مربوط به Service Account همراه باشد.تلاش برای escape یا دسترسی به hostاستفاده از runtime socket، mountهای حساس، capabilityهای پرخطر یا دسترسی به namespaceهای host باید به‌عنوان رویدادهای با اولویت بالا دیده شوند.همه‌چیز را با یک severity گزارش نکنیدیک مدل ساده برای severity می‌تواند این باشد:سطح پایینرفتار غیرمعمول اما کم‌خطر؛ مثلاً اجرای یک ابزار debug در namespace staging توسط تیم مجاز.سطح متوسطرفتار غیرمنتظره در production؛ مثلاً اجرای curl داخل containerای که نباید به اینترنت دسترسی داشته باشد.سطح بالاترکیب چند رفتار مشکوک؛ مثلاً اجرای shell، دانلود binary و اتصال به مقصد ناشناس.سطح بحرانینشانهٔ دسترسی به host، tokenهای حساس، Kubernetes API با permission بالا یا تلاش برای ایجاد workload جدید.severity باید با context workload و اثر احتمالی event تعیین شود، نه فقط بر اساس نام command.baseline رفتاری چیست؟Baseline یعنی تصویری از رفتار معمول یک workload. برای order-api می‌توان ثبت کرد:processهای مجازمقصدهای شبکه‌ای مجازمسیرهای قابل‌نوشتنaccount و Service Account مورد انتظارnamespace و nodeهای مجازپورت‌های مورد استفادهcommandهای عملیاتی قابل‌قبولBaseline نباید آن‌قدر سخت‌گیرانه باشد که هر deploy جدید را خراب کند. بهتر است ابتدا در حالت مشاهده جمع‌آوری شود، رفتارهای عادی از رفتارهای غیرعادی جدا شوند و بعد ruleها به‌تدریج enforce شوند.مثال عملی برای سرویس شبیه فیلیموفرض کنید سرویس transcoder برای پردازش فایل ویدئو به چند ابزار مشخص نیاز دارد. این سرویس ممکن است ffmpeg اجرا کند، اما نباید:shell تعاملی باز کند.به Kubernetes API متصل شود.به metadata service دسترسی داشته باشد.فایل اجرایی ناشناخته از اینترنت دانلود کند.به database پرداخت متصل شود.در این حالت، ruleها باید بین رفتار مورد انتظار و رفتار مشکوک تفاوت بگذارند. اجرای ffmpeg alert نیست؛ اجرای bash -c و سپس curl به یک IP ناشناخته alert است.اگر rule بدون context نوشته شود، تیم امنیت با صدها هشدار مربوط به اجرای عادی ffmpeg مواجه می‌شود. اگر context درست باشد، فقط زنجیرهٔ غیرعادی برجسته می‌شود.مثال عملی برای سرویس شبیه اسنپ یا تپسیفرض کنید سرویس driver-location در تعداد زیادی Pod اجرا می‌شود و releaseهای متوالی دارد. این سرویس باید به message broker و cache دسترسی داشته باشد، اما نباید command اجرایی جدید داخل container بسازد.در این سناریو، detection زیر ارزشمند است:اجرای processی که در image وجود نداشته است.ارتباط با مقصدی خارج از allowlist.اجرای shell توسط process اصلی.تلاش برای خواندن Service Account token.باز شدن پورت جدید داخل container.اگر یک Pod compromise شود، تیم باید بتواند همان Pod را isolate کند بدون اینکه کل سرویس location را خاموش کند. اینجا پاسخ مرحله‌ای مهم است.پاسخ به incident؛ اول شواهد را حفظ کنیدواکنش عجولانه می‌تواند شواهد مهم را از بین ببرد. حذف فوری Pod ممکن است حمله را متوقف کند، اما اطلاعاتی مثل process tree، connectionهای فعال و فایل‌های موقت را هم از بین می‌برد.یک روند مناسب می‌تواند این باشد:alert را با logهای application و Kubernetes تطبیق دهید.Pod، namespace، node، image digest و Service Account را ثبت کنید.مشخص کنید event از چه زمانی شروع شده است.ارتباط شبکه‌ای و process tree را بررسی کنید.در صورت امکان ابتدا workload را network-isolate کنید.credentialهای در معرض خطر را revoke یا rotate کنید.سپس Pod را terminate و از image سالم redeploy کنید.همهٔ workloadهایی را که همان image یا credential را داشته‌اند بررسی کنید.در محیط‌های بسیار حساس، snapshot یا forensic collection ممکن است قبل از حذف workload لازم باشد. این تصمیم باید با توجه به اثر سرویس و برنامهٔ incident response از قبل مشخص شده باشد.Isolation بهتر از خاموش کردن کل cluster استاگر فقط یک Pod مشکوک شده است، خاموش کردن کل node یا cluster معمولاً اولین انتخاب خوبی نیست. می‌توان دامنهٔ حادثه را محدود کرد:اعمال NetworkPolicy موقتقطع دسترسی خروجی Podحذف Service Account tokencordon کردن node در صورت نیازانتقال workload سالم به node دیگرblock کردن digest مشکوک در registry یا admissionاین اقدامات باید از قبل تمرین شده باشند. در زمان incident، تیم نباید برای اولین بار دنبال این باشد که چگونه یک namespace را isolate کند.لاگ‌ها را در سه سطح جمع کنیدلاگ applicationبرای فهمیدن رفتار business و خطاهای application لازم است.لاگ Kubernetesشامل eventهای Pod، تغییرات deployment، ایجاد Secret، تغییر RoleBinding و درخواست‌های API است.لاگ node و runtimeبرای دیدن processها، syscallها، اتصال‌ها و رفتار container لازم است.ترکیب این سه سطح مهم است. مثلاً لاگ application می‌گوید یک request خاص خطا داده، لاگ runtime نشان می‌دهد بعد از همان request یک shell اجرا شده و audit log نشان می‌دهد credential دیگری خوانده شده است.هشدار بدون فرایند پاسخ ارزشی نداردبرای هر alert مهم باید مشخص باشد:مالک بررسی اولیه چه تیمی است؟severity چگونه تعیین می‌شود؟چه زمانی باید incident اعلام شود؟چه کسی اجازهٔ isolate کردن workload را دارد؟credentialها چگونه rotate می‌شوند؟چه زمانی Pod حذف می‌شود؟چه اطلاعاتی باید در گزارش نهایی ثبت شود؟این موارد باید در runbook نوشته و با یک تمرین کوچک آزمایش شوند. یک rule عالی بدون runbook ممکن است فقط یک پیام دیگر در سیستم مانیتورینگ باشد.خطاهای رایج در Runtime Securityفعال کردن همهٔ ruleها بدون tuningاین کار معمولاً alert fatigue ایجاد می‌کند. ruleها باید با رفتار واقعی workloadها تنظیم شوند.حذف Pod بدون بررسی دامنهٔ حادثهحذف Pod ممکن است فقط نشانه را پاک کند. قبل از terminate باید image، digest، credential، node و workloadهای مشابه بررسی شوند.اعتماد به نام processمهاجم می‌تواند binary یا process را با نامی شبیه ابزارهای عادی اجرا کند. مسیر فایل، parent process، hash و context شبکه هم مهم هستند.نادیده گرفتن رفتارهای عادی اما پرخطراگر تیم‌ها برای debug دائماً با kubectl exec وارد production شوند، تشخیص استفادهٔ مهاجم از همان مسیر دشوار می‌شود. دسترسی عملیاتی باید محدود و audit شود.نداشتن زمان‌بندی برای نگهداری ruleهامعماری application تغییر می‌کند. ruleی که شش ماه قبل دقیق بوده ممکن است امروز false positive یا false negative زیادی تولید کند.یک برنامهٔ عملی برای شروعاگر Runtime Security هنوز در سازمان شما جدی پیاده نشده است، از این ترتیب شروع کنید:workloadهای حیاتی را مشخص کنید.image، digest، namespace و Service Account آن‌ها را فهرست کنید.processها و ارتباط‌های معمول را در حالت مشاهده ثبت کنید.ruleهای high-signal مثل shell در production و دسترسی به metadata را فعال کنید.alertها را به runbook مشخص متصل کنید.یک سناریوی compromise را در staging تمرین کنید.isolation و credential rotation را آزمایش کنید.بعد از tuning، ruleهای مهم را enforce کنید.لازم نیست از روز اول همهٔ syscallها و تمام namespaceها را زیر نظر بگیرید. چند detection دقیق و قابل‌پاسخ بهتر از صدها هشدار بی‌استفاده است.جمع‌بندیامنیت container فقط قبل از اجرا اتفاق نمی‌افتد. image ممکن است اسکن شده، sign شده و با policy درست deploy شده باشد، اما application در زمان اجرا همچنان compromise شود.Runtime Security کمک می‌کند رفتار واقعی workload را ببینیم: چه processی اجرا شده، چه فایلی تغییر کرده، به کجا متصل شده و با چه هویتی به Kubernetes API درخواست داده است.ابزارهایی مثل Falco زمانی ارزش واقعی دارند که با baseline درست، alertهای دارای context، لاگ‌های متمرکز و runbook پاسخ به incident همراه شوند.قاعدهٔ عملی این است:اگر نمی‌دانیم workload در حالت عادی چگونه رفتار می‌کند، تشخیص رفتار غیرعادی آن تقریباً غیرممکن است.هدف نهایی خاموش کردن همهٔ containerها نیست؛ هدف این است که یک رفتار مشکوک را زود ببینیم، دامنهٔ آن را محدود کنیم و قبل از تبدیل شدن یک Pod آلوده به حادثهٔ گسترده‌تر، واکنش درست نشان دهیم.سپهر فصیحی - Sepehr Fassihiسپهر فصیحی - Sepehr FassihiTue, 29 Sep 2026 12:41:03 +0330https://virgool.ir/@sepehrfci/admission-control-در-kubernetes-آخرین-دروازه-قبل-از-اجرای-workload-hmaydqok5ijjدر یک محیط Kubernetes، ممکن است image در CI اسکن شده باشد، تست‌ها موفق شده باشند و pipeline هم با وضعیت سبز تمام شده باشد؛ اما هنوز یک سؤال مهم باقی می‌ماند:چه چیزی جلوی اجرای یک workload ناامن را در خود cluster می‌گیرد؟اینجا Admission Control اهمیت پیدا می‌کند. Admission Control را می‌توان آخرین دروازهٔ تصمیم‌گیری قبل از ثبت یا اجرای بعضی resourceها در Kubernetes دانست. این لایه می‌تواند درخواست‌های API را بررسی کند، آن‌ها را تغییر دهد یا در صورت رعایت نشدن policy، رد کند.این موضوع برای امنیت container حیاتی است؛ چون حتی اگر همهٔ تیم‌ها آموزش دیده باشند، یک manifest اشتباه، chart ناامن یا تغییر عجولانه می‌تواند workloadی را وارد cluster کند که با privileged، دسترسی root، image نامعتبر یا secret ناامن اجرا می‌شود.Admission Control دقیقاً کجای مسیر قرار دارد؟وقتی کاربر یا یک ابزار automation در Kubernetes درخواستی برای ایجاد یا تغییر resource ارسال می‌کند، این درخواست از API Server عبور می‌کند. قبل از اینکه resource در وضعیت نهایی پذیرفته شود، کنترل‌های admission می‌توانند آن را بررسی کنند.به‌صورت ساده، مسیر شبیه این است:کاربر یا pipeline درخواست را به Kubernetes API می‌فرستد.احراز هویت و مجوزهای RBAC بررسی می‌شوند.admission policyها درخواست را بررسی یا تغییر می‌دهند.اگر policyها رعایت شده باشند، resource پذیرفته می‌شود.در غیر این صورت، درخواست رد می‌شود.این یعنی policy می‌تواند در نقطه‌ای اعمال شود که همهٔ مسیرهای ورود workload را پوشش می‌دهد؛ چه deploy از طریق kubectl انجام شود، چه Helm، Argo CD، Terraform یا یک ابزار داخلی.تفاوت Authorization با Admission ControlRBAC پاسخ می‌دهد که «چه کسی اجازه دارد چه کاری انجام دهد؟» اما Admission Control بررسی می‌کند که «آیا خود درخواست با policyهای امنیتی و عملیاتی سازگار است؟»فرض کنید یک developer مجوز ایجاد Deployment در namespace خودش را دارد. این مجوز الزاماً نباید به او اجازه دهد هر نوع Deploymentی بسازد. Admission policy می‌تواند جلوی موارد زیر را بگیرد:استفاده از imageهای خارج از registry مجازاجرای container با privileged: trueاستفاده از tag متحرک مثل latestنداشتن resource limitmount کردن مسیرهای حساس hostاستفاده از Service Account پیش‌فرضنداشتن labelهای ضروری برای auditبنابراین RBAC و Admission Control جایگزین هم نیستند؛ این دو کنترل، دو سؤال متفاوت را پاسخ می‌دهند.چرا فقط به CI/CD اعتماد نکنیم؟کنترل‌های CI/CD ضروری‌اند، اما کافی نیستند. در محیط واقعی همیشه فقط یک مسیر برای deploy وجود ندارد. ممکن است:یک تیم با kubectl تغییر دستی ایجاد کند.یک chart جدید policyهای قبلی را دور بزند.pipeline اشتباه پیکربندی شده باشد.یک حساب automation دسترسی بیش از حد داشته باشد.resource از یک مسیر اضطراری یا ابزار داخلی وارد cluster شود.اگر policy فقط در CI اجرا شود، هر مسیری که خارج از CI باشد می‌تواند یک نقطهٔ دور زدن ایجاد کند. Admission Control این شکاف را در مرز خود cluster پوشش می‌دهد.رویکرد بهتر این است که policyها در چند لایه اعمال شوند: feedback سریع در زمان توسعه، کنترل در CI و enforcement نهایی در API Server.دو نوع اصلی policy در زمان admissionAdmission policyها معمولاً دو رفتار اصلی دارند.Validation؛ بررسی و رد کردندر این مدل، درخواست بررسی می‌شود و اگر با قواعد سازگار نباشد، رد می‌شود. برای مثال:image باید از registry مشخصی باشد.container نباید privileged باشد.هر container باید resource limit داشته باشد.tag نباید latest باشد.این نوع policy برای کنترل‌های امنیتی سخت‌گیرانه مناسب است؛ چون manifest ناامن اصلاً وارد cluster نمی‌شود.Mutation؛ اصلاح یا تکمیل درخواستدر این مدل، policy بخشی از manifest را قبل از ثبت تغییر می‌دهد. برای مثال می‌تواند:label استاندارد اضافه کند.یک security context پایه تنظیم کند.مقدار پیش‌فرض برای resource limit قرار دهد.image را به registry داخلی redirect کند.Mutation برای استانداردسازی مفید است، اما نباید باعث شود تیم‌ها از وضعیت واقعی workload بی‌خبر بمانند. اگر policy به‌صورت پنهان تنظیمات مهمی را تغییر دهد، عیب‌یابی و audit دشوارتر می‌شود.در کنترل‌های حساس بهتر است به‌جای اصلاح خاموش، درخواست رد شود و دلیل روشن به صاحب workload نشان داده شود.چه policyهایی بیشترین ارزش امنیتی را دارند؟قرار نیست از روز اول صدها قانون بنویسیم. بهتر است با policyهایی شروع کنیم که ریسک بالا و ارزش عملی مشخصی دارند.محدود کردن منبع imageاجازه ندهید workload از هر registry عمومی image دریافت کند. registryهای مجاز را مشخص کنید و برای imageهای حساس، signature و digest را هم بررسی کنید.جلوگیری از tagهای متحرکاستفاده از latest یا tagهایی که مرتب تغییر می‌کنند، بازتولیدپذیری و audit را دشوار می‌کند. در محیط production بهتر است image با version مشخص و در صورت امکان digest ثابت استفاده شود.جلوگیری از تنظیمات privilegedprivileged: true باید یک exception نادر و مستند باشد، نه تنظیم پیش‌فرض. همین موضوع دربارهٔ host namespaceها، mountهای حساس و قابلیت‌های ویژه هم صدق می‌کند.الزام security contextpolicy می‌تواند workload را ملزم کند که مواردی مثل runAsNonRoot، allowPrivilegeEscalation: false و حذف capabilityهای غیرضروری را رعایت کند.الزام resource request و limitنبودن limit فقط مسئلهٔ پایداری نیست؛ یک workload بدون محدودیت می‌تواند منابع node را مصرف کند و روی availability سرویس‌های دیگر اثر بگذارد.کنترل Service Accountاستفاده از Service Account پیش‌فرض یا mount خودکار token باید با نیاز واقعی workload سازگار باشد. policy می‌تواند workloadها را مجبور کند هویت مشخص و کنترل‌شده داشته باشند.Pod Security Standards چه نقشی دارد؟Kubernetes برای کنترل برخی رفتارهای پرخطر، Pod Security Standards را ارائه می‌کند. این استانداردها سطح‌هایی مانند Privileged، Baseline و Restricted دارند و می‌توانند برای namespaceها اعمال شوند.در محیط‌های حساس، سطح Restricted معمولاً نقطهٔ شروع مناسب‌تری است، اما application ممکن است برای اجرا به اصلاحات نیاز داشته باشد. اعمال policy سخت‌گیرانه بدون بررسی compatibility می‌تواند deploymentهای معتبر را هم متوقف کند.رویکرد عملی این است که ابتدا policy در حالت audit یا warning اجرا شود، workloadهای ناسازگار شناسایی شوند و پس از اصلاح تدریجی، enforcement فعال شود.Kyverno و OPA؛ ابزار مهم است، policy مهم‌تر استبرای پیاده‌سازی policy as code ابزارهایی مانند Kyverno و Open Policy Agent با Gatekeeper استفاده می‌شوند. این ابزارها امکان تعریف قواعد قابل version control، review و audit را فراهم می‌کنند.اما نباید تصور کنیم نصب ابزار به‌تنهایی امنیت ایجاد می‌کند. policy ضعیف یا بیش از حد پیچیده می‌تواند فقط احساس امنیت کاذب ایجاد کند.یک policy خوب باید ویژگی‌های زیر را داشته باشد:هدف امنیتی مشخص داشته باشد.دلیل وجود آن قابل توضیح باشد.پیام خطای قابل‌فهم ارائه دهد.در Git version control شود.قبل از enforcement در محیط آزمایشی بررسی شود.owner و روند exception مشخص داشته باشد.اثر آن بر developer experience اندازه‌گیری شود.policy باید به‌عنوان کد مدیریت شودPolicy بخشی از زیرساخت امنیتی است و باید مانند کد application مدیریت شود. یعنی:تغییرات آن pull request داشته باشند.حداقل یک نفر دیگر آن را review کند.تست‌های مثبت و منفی داشته باشد.نسخهٔ policy قابل ردیابی باشد.rollback آن مشخص باشد.گزارش violationها نگهداری شود.اگر policyها فقط در پنل یک ابزار و بدون تاریخچهٔ تغییرات نگهداری شوند، در زمان incident پاسخ به این سؤال دشوار می‌شود که چه قانونی در چه زمانی فعال بوده است.از Audit به Enforce؛ مرحله‌ای حرکت کنیدیکی از رایج‌ترین خطاها این است که policyهای سخت‌گیرانه بدون inventory و بدون اطلاع قبلی فعال شوند. نتیجه معمولاً شکستن deploymentهای قدیمی، فشار روی تیم‌ها و ایجاد exceptionهای عجولانه است.یک مسیر مناسب می‌تواند این‌گونه باشد:policy را در حالت audit فعال کنید.violationها را دسته‌بندی و اولویت‌بندی کنید.workloadهای حساس را اصلاح کنید.برای تیم‌ها پیام خطای واضح و راهنمای اصلاح فراهم کنید.policy را ابتدا در namespaceهای جدید enforce کنید.exceptionهای محدود و زمان‌دار تعریف کنید.enforcement را به‌تدریج به محیط‌های دیگر گسترش دهید.هدف این نیست که هر deploymentی را بدون توضیح متوقف کنیم. هدف این است که مسیر ساخت workload امن، آسان‌تر از مسیر ساخت workload ناامن باشد.Exception باید موقت و قابل‌مشاهده باشدگاهی یک workload واقعاً به permission یا تنظیم خاصی نیاز دارد. مشکل از جایی شروع می‌شود که exception بدون زمان پایان، owner یا دلیل مشخص ایجاد شود.هر exception بهتر است شامل این موارد باشد:نام workload و namespacepolicy نقض‌شدهدلیل فنی و مستندowner پاسخ‌گوزمان ایجاد و تاریخ بازبینیکنترل‌های جبرانیزمان انقضا یا برنامهٔ حذف exceptionexception دائمی در عمل تبدیل به مسیر عادی می‌شود و ارزش policy را کاهش می‌دهد.مراقب policyهای بیش از حد سخت‌گیر باشیدامنیت ضعیف مشکل‌ساز است، اما policy غیرقابل‌استفاده هم باعث می‌شود تیم‌ها به دنبال دور زدن کنترل‌ها بروند. چند نشانهٔ policy نامناسب عبارت‌اند از:تعداد زیادی exception تکراریاستفادهٔ گسترده از accountهای اضطراریتغییر دستی خارج از مسیر استانداردخطاهای مبهم و بدون راهکارطولانی شدن غیرضروری چرخهٔ deploypolicy باید بر اساس ریسک واقعی طراحی شود، نه بر اساس میل به کنترل همه‌چیز. هر قانون باید بین کاهش ریسک و هزینهٔ عملیاتی تعادل ایجاد کند.مانیتورینگ و پاسخ به violationهارد شدن درخواست پایان کار نیست. باید بدانیم چه کسی، چه چیزی و چند بار policy را نقض کرده است.گزارش violationها می‌تواند الگوهای مهمی را نشان دهد:تیمی که دائم image نامعتبر استفاده می‌کند.chartی که هنوز تنظیمات قدیمی و پرخطر دارد.accountی که به‌طور غیرعادی درخواست privileged می‌فرستد.namespaceی که مرتب exception دریافت می‌کند.این اطلاعات هم برای امنیت و هم برای بهبود فرایند توسعه ارزشمند هستند. هدف audit فقط پیدا کردن مقصر نیست؛ باید منبع تکرار خطا را هم اصلاح کرد.یک baseline عملی برای شروعاگر بخواهید از تعداد محدودی rule شروع کنید، این baseline معمولاً ارزش بالایی دارد:image فقط از registry مورد اعتماد دریافت شود.tagهای متحرک در production ممنوع باشند.container با root اجرا نشود مگر با exception.privileged و host namespaceها ممنوع یا محدود باشند.capabilityهای غیرضروری حذف شوند.resource request و limit تعریف شده باشد.Service Account صریح و محدود استفاده شود.mount کردن secret و volumeهای حساس بررسی شود.labelهای مالکیت و محیط اجباری باشند.policy violationها قابل گزارش و پیگیری باشند.این baseline را می‌توان با توجه به معماری و نیاز سازمان توسعه داد؛ اما بهتر است با قوانین قابل‌فهم و قابل‌اجرا شروع شود.سپهر فصیحی - Sepehr Fassihiسپهر فصیحی - Sepehr FassihiSat, 26 Sep 2026 14:13:01 +0330https://virgool.ir/@sepehrfci/وقتی-یک-container-در-kubernetes-هک-می-شود-مهاجم-تا-کجا-می-تواند-پیش-برود-mlnnhwrcgjylدر بسیاری از تیم‌ها، امنیت Kubernetes با این سؤال شروع می‌شود که آیا image آسیب‌پذیری دارد یا نه. این سؤال مهم است، اما کافی نیست.اگر یک application داخل cluster compromise شود، مسئلهٔ اصلی فقط همان container نیست. باید بدانیم آن workload چه هویتی دارد، به چه APIهایی دسترسی دارد، چه secretهایی را می‌بیند و آیا می‌تواند از namespace یا service دیگری اطلاعات بگیرد یا نه.به این مسیر گسترش دسترسی، معمولاً حرکت جانبی (Lateral Movement) گفته می‌شود. مهاجم ابتدا از یک نقطهٔ ضعیف وارد می‌شود و بعد تلاش می‌کند با استفاده از دسترسی‌های موجود، به منابع ارزشمندتری برسد.هدف امنیت Kubernetes این نیست که فرض کنیم هیچ containerای compromise نمی‌شود. هدف این است که اگر چنین اتفاقی افتاد، دامنهٔ خسارت محدود بماند.نقطهٔ شروع حمله همیشه خود Kubernetes نیستیک مهاجم ممکن است از مسیرهای مختلف به container برسد:آسیب‌پذیری در applicationdependency مخرب یا آسیب‌پذیرsecret افشاشدهimage آلودهendpoint عمومی با احراز هویت ضعیفتنظیمات اشتباه ingress یا APIدسترسی بیش از حد یک کاربر یا سرویسبعد از ورود، مهاجم معمولاً به‌سرعت محیط را شناسایی می‌کند. او به دنبال پاسخ این سؤال‌هاست:این container با چه کاربری اجرا می‌شود؟چه environment variableهایی وجود دارد؟آیا token مربوط به Service Account در دسترس است؟چه سرویس‌هایی در شبکه قابل دسترسی هستند؟آیا این workload به metadata یا cloud credential دسترسی دارد؟آیا container به host یا Docker Socket متصل است؟هرچه اطلاعات و دسترسی اولیه بیشتر باشد، احتمال حرکت به سمت منابع حساس‌تر افزایش پیدا می‌کند.Service Account؛ هویت workload در clusterدر Kubernetes، هر Pod می‌تواند با یک Service Account اجرا شود. این هویت برای برقراری ارتباط با Kubernetes API و بعضی سرویس‌های دیگر استفاده می‌شود.مشکل زمانی ایجاد می‌شود که workload بدون نیاز واقعی، از Service Accountای با دسترسی گسترده استفاده کند. اگر application compromise شود، مهاجم ممکن است بتواند از credential همان Service Account برای خواندن یا تغییر منابع cluster استفاده کند.یک اشتباه رایج این است که تصور کنیم Service Account فقط برای سرویس‌های پیچیده یا controllerها لازم است. در حالی که اگر application شما به Kubernetes API نیاز ندارد، بهتر است این دسترسی به‌صورت صریح غیرفعال شود.برای workloadهایی که نیازی به API ندارند، تنظیم زیر می‌تواند از mount شدن خودکار token جلوگیری کند:apiVersion: v1 kind: Pod metadata: name: web spec: automountServiceAccountToken: false containers: - name: web image: example/web:1.4.2این تنظیم به‌تنهایی همهٔ ریسک‌ها را از بین نمی‌برد، اما یک credential غیرضروری را از داخل container حذف می‌کند.RBAC باید بر اساس نیاز واقعی نوشته شودکنترل دسترسی در Kubernetes با RBAC انجام می‌شود. در این مدل، Role یا ClusterRole مشخص می‌کند چه عملیاتی روی چه resourceهایی مجاز است و RoleBinding یا ClusterRoleBinding این مجوز را به یک هویت متصل می‌کند.اصل مهم در RBAC، حداقل دسترسی (Least Privilege) است.برای مثال، اگر یک controller فقط باید ConfigMapهای یک namespace را بخواند، نباید مجوز خواندن همهٔ Secretهای کل cluster را داشته باشد. همچنین دسترسی به resourceهایی مثل pods/exec، nodes، secrets و clusterrolebindings باید با حساسیت بسیار بیشتری بررسی شود.این دو مجوز شبیه هم نیستند:خواندن وضعیت Podها در یک namespaceاجرای command داخل هر Pod در کل clusterدومی می‌تواند مسیر بسیار قدرتمندتری برای دسترسی به applicationها و credentialهای دیگر ایجاد کند.قبل از دادن هر permission، سه سؤال بپرسید:این سرویس واقعاً به این resource نیاز دارد؟آیا فقط به یک namespace محدود می‌شود؟آیا فقط read لازم است یا write هم ضروری است؟اگر پاسخ دقیق نداریم، نباید permission را به‌صورت پیش‌فرض اضافه کنیم.چرا دسترسی به Secretها اهمیت زیادی دارد؟Secretها معمولاً شامل credentialهایی هستند که برای ارتباط با database، registry، API خارجی یا سرویس‌های داخلی استفاده می‌شوند. اگر یک Service Account بتواند Secretهای بیشتری از نیاز خود بخواند، compromise شدن یک workload می‌تواند به افشای credential چند سرویس دیگر منجر شود.نکتهٔ مهم این است که Secret در Kubernetes به معنی رمزنگاری کامل و خودکار نیست. نحوهٔ ذخیره‌سازی، دسترسی به API، encryption at rest، لاگ‌ها و روش mount شدن secret همگی اهمیت دارند.چند اقدام پایه‌ای برای کاهش ریسک:دسترسی خواندن Secretها را فقط به سرویس‌های ضروری بدهید.Secret را در image، Git و log قرار ندهید.credentialها را کوتاه‌عمر و قابل‌تعویض طراحی کنید.در صورت افشا، rotate کردن را بخشی از فرایند incident response بدانید.دسترسی تیم‌ها و automationها به Secret را جداگانه بررسی کنید.اگر application فقط یک credential محدود برای یک database لازم دارد، نباید به همهٔ Secretهای namespace دسترسی داشته باشد.Namespace مرز امنیتی کامل نیستNamespace برای نظم‌دهی و جداسازی منابع بسیار مفید است، اما به‌تنهایی یک مرز امنیتی کامل محسوب نمی‌شود.اگر network policy وجود نداشته باشد، یک Pod در namespace عمومی ممکن است بتواند به سرویس‌های namespaceهای دیگر متصل شود. اگر RBAC درست تنظیم نشده باشد، یک Service Account ممکن است همچنان به منابع خارج از namespace دسترسی داشته باشد.برای جداسازی واقعی‌تر باید چند لایه کنار هم قرار بگیرند:namespaceهای جداگانهRBAC محدود به همان namespaceNetworkPolicy برای کنترل ارتباطمحدودیت‌های resource و quotaadmission policynode pool جدا برای workloadهای حساس، در صورت نیازهیچ‌کدام از این موارد به‌تنهایی کافی نیستند. امنیت با ترکیب چند کنترل مستقل قوی‌تر می‌شود.شبکهٔ باز، حرکت مهاجم را ساده می‌کنددر بعضی clusterها، Podها بدون محدودیت می‌توانند با تعداد زیادی از سرویس‌های داخلی ارتباط برقرار کنند. این وضعیت برای توسعه ساده است، اما در زمان compromise شدن یک application، دامنهٔ حمله را بزرگ می‌کند.NetworkPolicy کمک می‌کند ارتباط‌های مجاز را صریح تعریف کنیم. برای مثال، یک frontend ممکن است فقط اجازهٔ اتصال به API داشته باشد و API نیز فقط بتواند به database متصل شود.سؤال مناسب این نیست که «آیا این Pod به شبکه دسترسی دارد؟»؛ سؤال بهتر این است:این Pod دقیقاً باید با کدام سرویس‌ها ارتباط داشته باشد و چرا؟هر ارتباطی که در policy تعریف نشده باشد، باید با دقت بررسی شود. البته باید مطمئن شد CNI مورد استفاده از NetworkPolicy پشتیبانی واقعی می‌کند؛ صرفاً وجود فایل policy به معنی enforce شدن آن نیست.دسترسی به Node و Host می‌تواند کل cluster را تهدید کندبعضی تنظیمات Pod، مرز بین container و node را ضعیف می‌کنند:privileged: truemount کردن مسیرهای حساس /hostاستفاده از hostPID یا hostNetworkافزودن capabilityهای غیرضروریmount کردن Docker Socket یا runtime socketاجرای process با کاربر rootاین تنظیمات همیشه به معنی compromise قطعی نیستند، اما سطح حمله را به‌شدت افزایش می‌دهند. اگر مهاجم از داخل container بتواند به credential یا socket مربوط به node برسد، ممکن است از سطح application به سطح زیرساخت نزدیک شود.برای همین Pod Security Standards و policyهای admission باید از ورود workloadهای پرخطر جلوگیری کنند. اجرای workload با کاربر غیر root، حذف capabilityهای اضافی و استفاده از filesystem فقط‌خواندنی، کنترل‌های پایه‌ای اما مهم هستند.نمونه‌ای از یک security context محدودتر:securityContext: runAsNonRoot: true allowPrivilegeEscalation: false readOnlyRootFilesystem: true capabilities: drop: - ALLالبته این تنظیمات باید با نیاز واقعی application آزمایش شوند. هدف، حذف دسترسی‌های غیرضروری است؛ نه اضافه کردن تنظیماتی که باعث اختلال بدون تحلیل شوند.Cloud Metadata و credentialهای بیرون از clusterاگر cluster روی یک cloud provider اجرا شود، باید دسترسی workload به metadata service و credentialهای cloud هم بررسی شود.یک application compromise‌شده ممکن است تلاش کند token یا اطلاعاتی را پیدا کند که برای دسترسی به object storage، queue، registry یا سرویس‌های مدیریتی استفاده می‌شود. اگر هویت workload با مجوزهای گسترده به cloud متصل شده باشد، حادثهٔ داخل یک Pod می‌تواند به منابع خارج از cluster هم برسد.راهکارهای مناسب شامل استفاده از هویت جدا برای هر workload، tokenهای کوتاه‌عمر، محدود کردن نقش‌های cloud و جلوگیری از credentialهای ثابت داخل environment variableهاست.مانیتورینگ باید مسیر سوءاستفاده را قابل مشاهده کندوقتی فقط وضعیت نهایی را می‌بینیم، تشخیص حرکت جانبی دشوار می‌شود. باید رویدادهای مهم را ثبت و بررسی کنیم:درخواست‌های غیرعادی به Kubernetes APIتلاش برای خواندن Secretهااجرای command داخل Podهاایجاد Pod یا Service جدید توسط هویت غیرمنتظرهتغییر RoleBindingهاارتباط شبکه‌ای غیرمعمول بین namespaceهااجرای container با تنظیمات privilegedلاگ بدون alert و تحلیل، فقط حجم زیادی از داده تولید می‌کند. بهتر است برای رفتارهای پرریسک، baseline مشخص شود و رویدادهای خارج از آن به‌صورت قابل پیگیری گزارش شوند.یک مدل عملی برای محدود کردن دامنهٔ خسارتبرای هر workload می‌توان این مدل ساده را اجرا کرد:هویت workload را مشخص کنید.تمام permissionهای RBAC را فهرست کنید.permissionهای بلااستفاده را حذف کنید.دسترسی به Secretها را محدود کنید.ارتباط شبکه‌ای مجاز را تعریف کنید.security context را سخت‌گیرانه‌تر کنید.دسترسی به host و cloud metadata را بررسی کنید.رویدادهای حساس را audit و monitor کنید.سناریوی compromise را در tabletop exercise یا محیط آزمایشی امتحان کنید.سؤال نهایی این است: اگر همین Pod امروز compromise شود، مهاجم چه resourceهایی را می‌بیند و چه تغییراتی می‌تواند ایجاد کند؟جمع‌بندیامنیت Kubernetes با امن بودن image تمام نمی‌شود. image فقط چیزی است که اجرا می‌شود؛ هویت، permission، شبکه و runtime مشخص می‌کنند آن workload بعد از اجرا چه قدرتی دارد.یک container محدود و بدون credential غیرضروری، حتی در صورت compromise شدن، دامنهٔ خسارت کوچک‌تری ایجاد می‌کند. در مقابل، containerای که با Service Account قدرتمند، دسترسی گسترده به Secretها، شبکهٔ باز و تنظیمات privileged اجرا می‌شود، می‌تواند به نقطهٔ شروع یک حادثهٔ بزرگ‌تر تبدیل شود.بهترین دفاع این نیست که امیدوار باشیم هیچ workloadای compromise نشود. بهترین دفاع این است که هر workload فقط به اندازهٔ نیازش قدرت داشته باشد و هر حرکت مهمی در cluster قابل مشاهده و قابل پاسخ‌گویی باشد.سپهر فصیحی - Sepehr Fassihiسپهر فصیحی - Sepehr FassihiThu, 24 Sep 2026 13:44:58 +0330https://virgool.ir/@sepehrfci/چرا-اسکن-container-image-به-تنهایی-امنیت-شما-را-تضمین-نمی-کند-rd1lgjvvjpegتقریباً هر تیمی که با Docker یا Kubernetes کار می‌کند، در بخشی از مسیر توسعه از image scanner استفاده می‌کند. ابزارهایی مثل Trivy، Grype، Snyk و چندین ابزار دیگر، image را بررسی می‌کنند و دربارهٔ آسیب‌پذیری‌های موجود در پکیج‌ها و کتابخانه‌ها گزارش می‌دهند.این کار ضروری است؛ اما یک سوءتفاهم رایج وجود دارد: بعضی تیم‌ها تصور می‌کنند اگر اسکن image بدون خطای جدی تمام شود، آن image امن است.واقعیت این است که اسکن image فقط یکی از لایه‌های امنیت container را پوشش می‌دهد. این ابزارها معمولاً می‌توانند آسیب‌پذیری‌های شناخته‌شده را پیدا کنند، اما امنیت container به چیزهای بیشتری وابسته است: نحوهٔ ساخت image، منبع آن، تنظیمات runtime، سطح دسترسی برنامه و محیطی که container در آن اجرا می‌شود.به زبان ساده، ممکن است یک image هیچ آسیب‌پذیری Critical نداشته باشد، اما همچنان به دلیل اجرای برنامه با کاربر root، داشتن secret داخل لایه‌های image یا دسترسی بیش از حد به host، ناامن باشد.اسکن image دقیقاً چه چیزی را بررسی می‌کند؟بیشتر image scannerها محتویات image را با یک پایگاه دادهٔ آسیب‌پذیری مقایسه می‌کنند. آن‌ها معمولاً مواردی مانند این‌ها را بررسی می‌کنند:پکیج‌های سیستم‌عامل مثل Debian، Alpine یا Ubuntuکتابخانه‌های زبان‌های برنامه‌نویسیdependencyهای مستقیم و غیرمستقیمنسخهٔ ابزارهای نصب‌شده در imageبرخی misconfigurationهای شناخته‌شدهsecretها یا فایل‌های حساس، در صورت پشتیبانی ابزارفرض کنید image شما بر پایهٔ یک نسخهٔ قدیمی از Debian ساخته شده باشد و کتابخانه‌ای با یک آسیب‌پذیری شناخته‌شده داخل آن وجود داشته باشد. scanner می‌تواند نسخهٔ نصب‌شده را تشخیص دهد، شناسهٔ آسیب‌پذیری را پیدا کند و severity آن را گزارش دهد.این قابلیت ارزشمند است، اما باید بدانیم که scanner بیشتر دربارهٔ «محتویات قابل شناسایی image» صحبت می‌کند، نه دربارهٔ تمام رفتار امنیتی application.اولین مشکل: همهٔ آسیب‌پذیری‌ها قابل شناسایی نیستندپایگاه دادهٔ scannerها بر اساس آسیب‌پذیری‌های شناخته‌شده کار می‌کند. اگر یک آسیب‌پذیری هنوز عمومی نشده باشد، در پایگاه داده وجود نداشته باشد یا ابزار نتواند package را درست شناسایی کند، ممکن است در گزارش دیده نشود.از طرف دیگر، وجود یک آسیب‌پذیری در image لزوماً به معنی exploit شدن آن در application شما نیست. ممکن است یک package آسیب‌پذیر نصب شده باشد، اما کد مربوط به آن feature اصلاً استفاده نشود. برعکس، ممکن است application شما در برابر یک ورودی مخرب آسیب‌پذیر باشد، در حالی که هیچ CVE شناخته‌شده‌ای برای dependencyهای آن گزارش نشده است.بنابراین نباید گزارش scanner را با ارزیابی کامل ریسک اشتباه بگیریم. severity یک CVE نقطهٔ شروع بررسی است، نه پایان آن.دومین مشکل: اسکن فقط بخشی از زنجیرهٔ تأمین استامنیت image از زمانی شروع نمی‌شود که image ساخته شده و آمادهٔ اسکن است. باید از مراحل قبل‌تر سؤال کنیم:base image از کجا آمده است؟آیا ناشر آن قابل اعتماد است؟آیا image با digest مشخص دریافت می‌شود یا فقط از tag استفاده شده است؟آیا dependencyها از registry معتبر نصب می‌شوند؟آیا build قابل بازتولید است؟آیا کسی image نهایی را sign می‌کند؟استفاده از tagهایی مثل latest مشکل رایجی است. این tag ممکن است در زمان‌های مختلف به imageهای متفاوت اشاره کند. در نتیجه build امروز الزاماً همان چیزی نیست که هفتهٔ آینده ساخته می‌شود.بهتر است نسخهٔ base image و dependencyهای حساس pin شوند و در محیط‌های مهم، image با digest مشخص دریافت شود. این کار باعث می‌شود بدانیم دقیقاً چه artifactی وارد pipeline شده است.سومین مشکل: secret ممکن است در لایه‌های image باقی بماندیکی از خطرناک‌ترین اشتباه‌ها این است که secret را در زمان build وارد image کنیم و بعد در یک لایهٔ بعدی حذفش کنیم:COPY .npmrc /root/.npmrc RUN npm install RUN rm /root/.npmrcدر نگاه اول فایل حذف شده است، اما image از چند layer تشکیل می‌شود و ممکن است فایل حساس در یکی از layerهای قبلی همچنان قابل بازیابی باشد. حتی اگر scanner secret را در filesystem نهایی پیدا نکند، secret ممکن است در history یا layerهای قبلی باقی مانده باشد.راهکار بهتر این است که secret در زمان build به شکل امن و موقت در اختیار build قرار بگیرد؛ برای مثال با secretهای BuildKit، نه با ARG یا ENV معمولی. همچنین باید secretهایی که احتمال افشای آن‌ها وجود دارد، فوراً revoke و rotate شوند؛ حذف فایل به‌تنهایی کافی نیست.چهارمین مشکل: image کم‌خطر می‌تواند با تنظیمات بد، خطرناک اجرا شودفرض کنید scanner یک image تمیز و بدون آسیب‌پذیری مهم گزارش کند. حالا همان image را با این تنظیمات اجرا می‌کنیم:اجرای process با کاربر rootفعال بودن privilegedmount کردن مسیرهای حساس hostاستفاده از host networkدادن capabilityهای غیرضروریدسترسی نوشتن به filesystemmount کردن Docker Socketدر این حالت، نتیجهٔ اسکن image به‌تنهایی امنیت workload را تضمین نمی‌کند. بخش بزرگی از ریسک به runtime configuration مربوط است.برای کاهش سطح حمله، application باید تا جای ممکن با کاربر غیر root اجرا شود، capabilityهای اضافی حذف شوند و filesystem به‌صورت read-only در نظر گرفته شود. در Kubernetes نیز باید security context، service account، network policy و محدودیت‌های admission بررسی شوند.یک image امن با تنظیمات ناامن، همچنان می‌تواند یک workload ناامن باشد.پنجمین مشکل: اسکن باید در زمان درست انجام شودبعضی تیم‌ها image را فقط بعد از deploy اسکن می‌کنند. این کار برای کشف مشکل مفید است، اما خیلی دیر انجام می‌شود. از طرف دیگر، اگر pipeline در اولین هشدار همهٔ buildها را متوقف کند، توسعه‌دهنده‌ها ممکن است به‌مرور هشدارها را نادیده بگیرند.یک رویکرد عملی، اسکن در چند نقطه است:هنگام توسعهتوسعه‌دهنده باید بتواند image و dependencyهای خود را قبل از push بررسی کند. این مرحله بازخورد سریع می‌دهد و هزینهٔ اصلاح را پایین نگه می‌دارد.داخل CI/CDpipeline باید image را قبل از push به registry یا قبل از deploy اسکن کند. در این مرحله باید policy مشخص باشد؛ مثلاً وجود آسیب‌پذیری Critical قابل exploit باعث شکست build شود، اما یک هشدار کم‌ریسک صرفاً گزارش شود.داخل registryregistry می‌تواند imageها را به‌صورت دوره‌ای دوباره اسکن کند. این موضوع مهم است، چون ممکن است امروز image بدون مشکل باشد، اما فردا برای همان نسخه یک CVE جدید منتشر شود.هنگام deployدر Kubernetes می‌توان با admission control از اجرای imageهایی که policy را رعایت نمی‌کنند جلوگیری کرد. این مرحله جلوی ورود artifact نامعتبر به محیط حساس را می‌گیرد.به‌جای شمارش CVE، ریسک را اولویت‌بندی کنیددیدن صدها آسیب‌پذیری در یک image بزرگ معمولاً باعث خستگی و بی‌تفاوتی تیم می‌شود. همهٔ این موارد ارزش یکسانی ندارند.برای اولویت‌بندی، فقط severity را نگاه نکنید. این سؤال‌ها مهم‌تر هستند:آیا آسیب‌پذیری از بیرون قابل دسترسی است؟آیا exploit عمومی برای آن وجود دارد؟آیا package آسیب‌پذیر واقعاً در مسیر اجرای application استفاده می‌شود؟آیا container با root یا capability بالا اجرا می‌شود؟آیا image در production استفاده می‌شود یا فقط در محیط تست؟آیا نسخهٔ اصلاح‌شده وجود دارد؟به این ترتیب، تیم به‌جای تلاش برای صفر کردن یک عدد، روی ریسک‌هایی تمرکز می‌کند که واقعاً می‌توانند به compromise منجر شوند.یک pipeline منطقی برای امنیت imageیک pipeline مناسب می‌تواند این مراحل را داشته باشد:استفاده از base image کوچک و معتبرpin کردن نسخه‌ها و digestهای مهمجلوگیری از ورود secret به context و layerهای imageاجرای dependency scan و image scanبررسی Dockerfile و تنظیمات امنیتیتولید SBOM برای ثبت اجزای imagesign کردن image و بررسی signature هنگام deployاجرای image فقط در صورت عبور از policyاسکن دوره‌ای imageهای موجود در registryبازسازی image پس از انتشار آسیب‌پذیری جدیداین مراحل قرار نیست سرعت توسعه را از بین ببرند. هدف این است که کنترل‌های امنیتی در همان جریان عادی build و release قرار بگیرند، نه اینکه چند ماه بعد به‌صورت دستی و جداگانه انجام شوند.جمع‌بندیاسکن Container Image لازم است، اما کافی نیست. scanner می‌تواند بسیاری از packageهای آسیب‌پذیر و misconfigurationهای شناخته‌شده را پیدا کند؛ اما نمی‌تواند به‌تنهایی دربارهٔ منبع image، کیفیت کد application، نحوهٔ اجرای container، مدیریت secret یا سطح دسترسی workload تصمیم بگیرد.امنیت container باید از یک زنجیرهٔ کامل تشکیل شود: image معتبر، build قابل اعتماد، dependencyهای کنترل‌شده، secret management درست، runtime محدود، policy روشن و پایش مداوم.به‌جای اینکه بپرسیم «آیا image اسکن شده است؟»، سؤال دقیق‌تر این است:این image از کجا آمده، چه چیزی داخل آن قرار دارد، با چه سطح دسترسی اجرا می‌شود و آیا می‌توانیم در تمام چرخهٔ عمر آن به آن اعتماد کنیم؟اگر پاسخ این سؤال‌ها روشن نباشد، یک گزارش سبز از image scanner نباید احساس امنیت کاذب ایجاد کند.سپهر فصیحی - Sepehr Fassihiسپهر فصیحی - Sepehr FassihiThu, 24 Sep 2026 13:00:22 +0330https://virgool.ir/@sepehrfci/docker-socket-چرا-یک-فایل-ساده-می-تواند-معادل-root-روی-host-باشد-vb2lg9d2ufj8یکی از پیکربندی‌هایی که در پروژه‌های واقعی زیاد دیده‌ام، mount کردن Docker Socket داخل کانتینر است:-v /var/run/docker.sock:/var/run/docker.sockدر نگاه اول این کار کاملاً منطقی به نظر می‌رسد. ابزارهایی مثل Jenkins، GitLab Runner، بعضی image scannerها و build toolها برای ساخت یا مدیریت container به Docker daemon دسترسی می‌خواهند.اما نکته‌ای که معمولاً نادیده گرفته می‌شود این است:دسترسی نوشتن روی Docker Socket، در بسیاری از محیط‌ها عملاً معادل دسترسی root روی Host است.این یعنی موضوع فقط «دسترسی به Docker» نیست. موضوع این است که یک container می‌تواند از طرف Docker daemon عملیاتی انجام دهد که روی خود host اجرا می‌شوند.Docker Socket دقیقاً چیست؟وقتی دستور زیر را اجرا می‌کنیم:docker ps docker build -t myapp . docker run nginxابزار docker معمولاً خودش container را نمی‌سازد. این ابزار درخواست را از طریق socket زیر برای Docker daemon ارسال می‌کند:/var/run/docker.sockDocker daemon معمولاً با سطح دسترسی root اجرا می‌شود. بنابراین هر چیزی که بتواند از طریق این socket به daemon دستور بدهد، می‌تواند از قابلیت‌های privileged daemon استفاده کند.برای بررسی وضعیت socket روی host می‌توانید این دستور را اجرا کنید:ls -l /var/run/docker.sockدر بسیاری از سیستم‌ها خروجی چیزی شبیه این است:srw-rw---- 1 root docker ... /var/run/docker.sockدر اینجا دسترسی به socket در اختیار root و اعضای گروه docker است. نکتهٔ مهم این است که عضویت در گروه docker را نباید مثل یک permission معمولی در نظر گرفت؛ این دسترسی در عمل می‌تواند بسیار نزدیک به root روی host باشد.چرا mount کردن socket خطرناک است؟فرض کنید یک CI/CD container به Docker Socket دسترسی دارد. اگر یکی از این اتفاق‌ها رخ دهد، امنیت host زیر سؤال می‌رود:یک dependency در pipeline آلوده باشد.یک مهاجم بتواند فایل pipeline را تغییر دهد.یک Jenkinsfile یا GitLab CI configuration دست‌کاری شود.یک ابزار third-party آسیب‌پذیر باشد.credential مربوط به CI افشا شود.یک image مخرب در فرایند build وارد شود.در این حالت مهاجم لزوماً لازم نیست مستقیماً به host دسترسی داشته باشد. کافی است بتواند به containerای برسد که Docker Socket را در اختیار دارد.از آنجا که Docker daemon می‌تواند container جدید ایجاد کند، volume mount انجام دهد و تنظیمات privileged را تغییر دهد، این container به یک واسطه برای دسترسی به host تبدیل می‌شود.مثال واقعی‌تر: CI/CDیکی از رایج‌ترین سناریوها این است:services: - docker:dind build: script: - docker build -t registry.example.com/app:$CI_COMMIT_SHA . - docker push registry.example.com/app:$CI_COMMIT_SHAیا در یک runner:-v /var/run/docker.sock:/var/run/docker.sockتیم معمولاً با هدف ساده‌ای این کار را انجام می‌دهد: pipeline باید image بسازد و آن را push کند.اما اگر pipeline روی production cluster اجرا شود، یا runner با workloadهای غیرقابل‌اعتماد مشترک باشد، یک مشکل معماری جدی ایجاد می‌شود. حالا build job فقط یک job ساده نیست؛ به بخشی از control plane ماشین تبدیل شده است.تفاوت Docker-in-Docker و Docker Socket Mountاین دو مفهوم را نباید با هم اشتباه گرفت.Docker Socket Mountدر این مدل، container به Docker daemon روی host وصل می‌شود:-v /var/run/docker.sock:/var/run/docker.sockمزیت آن سادگی و performance مناسب است، اما daemon و در نتیجه سطح دسترسی host را share می‌کنید.Docker-in-Dockerدر Docker-in-Docker، یک Docker daemon دیگر داخل container اجرا می‌شود. این مدل isolation بیشتری ایجاد می‌کند، اما اگر با --privileged اجرا شود، همچنان ریسک قابل‌توجهی دارد.هیچ‌کدام از این الگوها به‌صورت خودکار امن نیستند. باید مشخص شود build در کجا اجرا می‌شود، چه کسی می‌تواند آن را trigger کند و daemon به چه resourceهایی دسترسی دارد.یک اشتباه رایج در Kubernetesگاهی Docker Socket روی node به pod mount می‌شود:volumeMounts: - name: docker-sock mountPath: /var/run/docker.sock volumes: - name: docker-sock hostPath: path: /var/run/docker.sock این کار باید یک red flag جدی باشد.در Kubernetes مدرن معمولاً container runtime ممکن است containerd یا CRI-O باشد، نه Docker. بنابراین mount کردن Docker Socket هم ممکن است از نظر فنی بی‌فایده باشد و هم از نظر امنیتی ریسک غیرضروری ایجاد کند.اگر workload واقعاً به runtime node نیاز دارد، باید اول پرسید چرا این نیاز وجود دارد و آیا راهکار محدودتر و جداگانه‌ای برای آن وجود دارد یا نه.جایگزین‌های امن‌تر۱. استفاده از BuildKit با daemon جداگانهبه‌جای اتصال مستقیم به daemon host، build را روی builder جدا اجرا کنید. این builder باید:روی nodeهای جداگانه باشد.به credentialهای محدود دسترسی داشته باشد.به production cluster دسترسی مستقیم نداشته باشد.lifecycle و permission جداگانه داشته باشد.با workloadهای untrusted به‌صورت مشترک استفاده نشود.۲. استفاده از builderهای بدون daemonابزارهایی مثل Kaniko یا Buildah در بعضی سناریوها می‌توانند image بسازند، بدون اینکه به Docker daemon host متصل شوند.این ابزارها هم نیازمند threat model هستند و نباید صرفاً به‌دلیل «بدون Docker Socket بودن» امن فرض شوند؛ اما معمولاً blast radius محدودتری ایجاد می‌کنند.۳. جداسازی build و deployیک pipeline بهتر است این مراحل را از هم جدا کند:build کردن imageاسکن vulnerabilityتولید SBOMsign کردن imagepush به registrydeploy از طریق GitOps یا کنترلر محدوددر این مدل، build job نباید دسترسی مستقیم و گسترده به cluster production داشته باشد.۴. استفاده از GitOpsدر مدل GitOps، pipeline به‌جای اینکه مستقیماً به cluster command بفرستد، تغییر مطلوب را در repository ثبت می‌کند. سپس GitOps controller تغییر را بررسی و اعمال می‌کند.این معماری چند مزیت دارد:دسترسی مستقیم pipeline به cluster کاهش پیدا می‌کند.تغییرها audit trail دارند.review و approval ممکن می‌شود.rollback ساده‌تر است.credentialهای حساس کمتری در اختیار job قرار می‌گیرد.اگر واقعاً مجبور به استفاده از Socket هستیم چه کنیم؟گاهی حذف کامل Docker Socket واقعاً ممکن نیست. در این حالت حداقل این کنترل‌ها را اجرا کنید:runner را جدا کنیدrunner دارای Docker Socket نباید با workloadهای معمولی یا پروژه‌های untrusted مشترک باشد.روی production اجرا نکنیدbuild را روی nodeهای اختصاصی انجام دهید و اجازه ندهید runner به nodeهای production دسترسی داشته باشد.credentialها را محدود کنیدcredential registry، cloud و deployment را از هم جدا کنید. یک job نباید همهٔ این credentialها را هم‌زمان داشته باشد.image را قبل از deploy کنترل کنیدحداقل این موارد را بررسی کنید:vulnerability scanSBOMimage signatureimage digestsource و build provenancepolicyهای admissionدسترسی را audit کنیدبررسی کنید چه containerهایی socket را mount کرده‌اند:kubectl get pods --all-namespaces -o yaml | grep -n docker.sockهمچنین در Docker و ابزارهای مدیریت host، mountهای حساس را به‌صورت دوره‌ای بررسی کنید.یک قاعدهٔ ساده برای Code Reviewهر زمان این الگو را دیدید:hostPath: path: /var/run/docker.sockیا این را:-v /var/run/docker.sock:/var/run/docker.sockقبل از اینکه بپرسید «آیا application کار می‌کند؟»، این سؤال‌ها را بپرسید:چرا این application به Docker daemon نیاز دارد؟آیا این دسترسی فقط برای build است یا runtime هم به آن نیاز دارد؟اگر این container compromise شود، مهاجم به چه چیزهایی دسترسی خواهد داشت؟آیا builder از production جداست؟آیا جایگزین بدون daemon وجود دارد؟چه کسی می‌تواند این job را اجرا یا تغییر دهد؟آیا تمام commandهای Docker audit می‌شوند؟جمع‌بندیDocker Socket یک فایل معمولی نیست. این socket دروازهٔ دسترسی به Docker daemon است و Docker daemon نیز معمولاً با privilege بالایی روی host اجرا می‌شود.به همین دلیل mount کردن آن داخل container باید یک exception باشد، نه default معماری CI/CD.اگر هدف شما build کردن image است، builder جداگانه بسازید. اگر هدف deploy کردن است، از GitOps یا کنترلر محدود استفاده کنید. اگر واقعاً به socket نیاز دارید، آن را روی runner جدا، با دسترسی محدود و خارج از production نگه دارید.در امنیت container، سؤال مهم فقط این نیست که «این container چه کاری انجام می‌دهد؟»؛ باید بپرسیم:اگر این container compromise شود، چه چیزی می‌تواند به‌جای خودش انجام دهد؟و دربارهٔ Docker Socket، پاسخ معمولاً بیشتر از چیزی است که در نگاه اول به نظر می‌رسد.سپهر فصیحی - Sepehr Fassihiسپهر فصیحی - Sepehr FassihiThu, 24 Sep 2026 12:01:19 +0330https://virgool.ir/@sepehrfci/چرا-اجرای-کانتینر-با-root-هنوز-یکی-از-اشتباه-های-رایج-در-production-است-mdhnojz9zkoxخیلی از تیم‌ها وقتی به کانتینر مهاجرت می‌کنند، تصور می‌کنند چون کانتینر از سیستم‌عامل میزبان جداست، پس اجرای برنامه با کاربر root مشکل خاصی ایجاد نمی‌کند.این تصور تا زمانی که همه‌چیز طبق برنامه پیش برود، شاید خودش را نشان ندهد. مشکل از جایی شروع می‌شود که application آسیب‌پذیر باشد، یک dependency آلوده وارد image شود یا مهاجم بتواند از داخل کانتینر کاری فراتر از رفتار معمول برنامه انجام دهد.در چنین شرایطی، root بودن کانتینر می‌تواند تفاوت بین یک حادثهٔ محدود و compromise شدن کل میزبان باشد.اول یک سوءتفاهم مهم را برطرف کنیموقتی داخل کانتینر دستور زیر را اجرا می‌کنیم:docker run --rm -it alpine sh / # whoami rootاین root فقط یک نام داخل کانتینر نیست.در Docker، اگر user namespace فعال نباشد، کاربر root داخل کانتینر معمولاً همان شناسهٔ کاربری root روی میزبان است. البته کانتینر به‌صورت پیش‌فرض همهٔ capabilityهای root را ندارد، اما همچنان با سطح دسترسی بالایی اجرا می‌شود.یعنی اگر مهاجم بتواند از کانتینر خارج شود، دیگر با یک user معمولی روی میزبان روبه‌رو نیستیم؛ با root طرف هستیم.آیا non-root بودن به‌تنهایی کافی است؟نه.اجرای کانتینر با user غیر root یکی از مهم‌ترین کنترل‌های امنیتی است، اما نباید آن را یک راه‌حل جادویی در نظر گرفت. امنیت کانتینر مجموعه‌ای از لایه‌هاست:اجرای application با user غیر rootحذف capabilityهای غیرضروریفعال کردن no-new-privilegesاستفاده از seccomp و AppArmor یا SELinuxمحدود کردن mountهاجلوگیری از دسترسی به Docker socketاسکن imageهااستفاده از runtime securityبااین‌حال، non-root بودن یک خط دفاعی بسیار ارزشمند است؛ مخصوصاً وقتی یک اشتباه پیکربندی یا vulnerability در لایه‌های دیگر وجود دارد.ساده‌ترین راه: تعیین USER در Dockerfileیک Dockerfile ساده را در نظر بگیرید:FROM python:3.12-slim WORKDIR /app COPY requirements.txt . RUN pip install --no-cache-dir -r requirements.txt COPY . . CMD ["python", "app.py"] این image، مگر اینکه جای دیگری user مشخص شده باشد، برنامه را با root اجرا می‌کند.نسخهٔ بهتر:FROM python:3.12-slim WORKDIR /app RUN useradd --create-home --uid 10001 appuser COPY requirements.txt . RUN pip install --no-cache-dir -r requirements.txt COPY --chown=appuser:appuser . . USER appuser CMD ["python", "app.py"] چند نکته در این مثال مهم است:user اختصاصی برای application ساخته شده است.مالکیت فایل‌های application به همان user داده شده است.دستور USER قبل از اجرای application قرار گرفته است.برنامه دیگر با root اجرا نمی‌شود.برای imageهای production بهتر است UID ثابت و مشخص داشته باشید، اما نباید فرض کنید این UID روی host نیز همان هویت را دارد. چیزی که اهمیت دارد کاهش privilege داخل کانتینر و محدود کردن سطح اثرگذاری application است.مشکل رایج بعد از non-root کردن imageگاهی بعد از اضافه کردن USER، application دیگر اجرا نمی‌شود. معمولاً یکی از این مشکلات وجود دارد:برنامه می‌خواهد روی port کمتر از ۱۰۲۴ listen کند.application می‌خواهد در مسیری بنویسد که مالک آن root است.package یا dependency هنگام startup نصب می‌شود.برنامه به دسترسی‌هایی نیاز دارد که قبلاً به‌صورت ضمنی از root دریافت می‌کرد.فایل‌های موقت یا log directory مجوز مناسب ندارند.این خطاها به این معنا نیستند که باید سریع به root برگردیم. معمولاً باید پیکربندی application را اصلاح کنیم.مثلاً یک web application لازم نیست داخل کانتینر روی port 80 اجرا شود:EXPOSE 8080و در زمان اجرا می‌توان آن را به port 80 روی host map کرد:docker run -p 80:8080 myappدر این حالت application با user غیر root روی port 8080 داخل کانتینر اجرا می‌شود، اما کاربر بیرونی از طریق port 80 به آن دسترسی دارد.محدود کردن privilege با --cap-dropحتی اگر کانتینر با root اجرا شود، بهتر است capabilityهای غیرضروری را حذف کنیم. روش بهتر این است که همهٔ capabilityها را حذف و فقط موارد موردنیاز را اضافه کنیم:bashdocker run \ --cap-drop=ALL \ --cap-add=NET_BIND_SERVICE \ myapp البته قبل از اضافه کردن هر capability باید دقیقاً بدانیم application به چه چیزی نیاز دارد.اضافه کردن capabilityهایی مثل موارد زیر باید با حساسیت زیادی انجام شود:CAP_SYS_ADMINCAP_SYS_MODULECAP_SYS_PTRACECAP_NET_ADMINCAP_BPFاین capabilityها می‌توانند دسترسی‌های قدرتمندی در اختیار process قرار دهند. استفاده از --cap-add=ALL تقریباً همیشه نشانهٔ این است که تیم هنوز دقیقاً نمی‌داند application چه مجوزهایی لازم دارد.جلوگیری از privilege escalation با no-new-privilegesحتی اگر application با user غیر root اجرا شود، بعضی executableها ممکن است با setuid سطح دسترسی بیشتری به دست آورند.برای جلوگیری از این رفتار در Docker:docker run \ --security-opt=no-new-privileges:true \ myapp در Kubernetes نیز می‌توان همین سیاست را در securityContext قرار داد: content_copy yamlsecurityContext: allowPrivilegeEscalation: false این تنظیم به‌تنهایی application را امن نمی‌کند، اما جلوی یکی از مسیرهای رایج افزایش سطح دسترسی را می‌گیرد.در Kubernetes چه تنظیمی باید داشته باشیم؟یک نمونهٔ پایه:apiVersion: v1 kind: Pod metadata: name: secure-app spec: containers: - name: app image: example/app:1.0.0 securityContext: runAsNonRoot: true runAsUser: 10001 allowPrivilegeEscalation: false readOnlyRootFilesystem: true capabilities: drop: - ALL البته readOnlyRootFilesystem ممکن است برای همهٔ applicationها بدون تغییرات اضافی قابل استفاده نباشد. بعضی برنامه‌ها برای اجرای صحیح به نوشتن در /tmp یا directory مشخصی نیاز دارند. در چنین شرایطی بهتر است فقط همان مسیر ضروری را به‌صورت volume موقت در اختیار application قرار دهیم، نه اینکه کل filesystem را writable کنیم.مثلاً:volumeMounts: - name: tmp mountPath: /tmp volumes: - name: tmp emptyDir: {} این رویکرد بسیار بهتر از writable بودن کل root filesystem است.چه زمانی اجرای root قابل‌قبول است؟گاهی واقعاً به root نیاز داریم؛ برای نمونه:بعضی ابزارهای زیرساختی که با kernel کار می‌کنندابزارهای eBPFبرخی agentهای monitoringcontainer runtimeهای خاصفرایندهای build در محیط کنترل‌شدهimageهایی که هنگام build package نصب می‌کننداما باید بین build-time privilege و runtime privilege تفاوت بگذاریم.اینکه در زمان build برای نصب package از root استفاده کنیم، با اینکه application را در production با root اجرا کنیم، یکسان نیست.الگوی مناسب معمولاً این است:FROM golang:1.23 AS builder WORKDIR /src COPY . . RUN go build -o app ./cmd/app FROM gcr.io/distroless/static-debian12 COPY --from=builder /src/app /app USER 65532:65532 ENTRYPOINT ["/app"] در این مدل:مرحلهٔ build محیط کاملی دارد.image نهایی فقط artifact موردنیاز را شامل می‌شود.ابزارهای build و package manager وارد production نمی‌شوند.application با user غیر root اجرا می‌شود.attack surface کاهش پیدا می‌کند.چند بررسی ساده برای pipelineقبل از deploy شدن image این موارد را بررسی کنید:docker inspect myappبررسی کنید:آیا user اجرای container مشخص است؟آیا container با root اجرا می‌شود؟آیا capability اضافی دارد؟آیا filesystem باید writable باشد؟آیا volume حساس mount شده است؟آیا Docker socket در اختیار container قرار گرفته است؟آیا image از registry معتبر دریافت شده است؟در Kubernetes نیز می‌توان این کنترل‌ها را با admission policy enforce کرد تا deploy شدن workloadهای ناامن به تصمیم دستی developer وابسته نباشد.جمع‌بندیاجرای کانتینر با root همیشه به معنی وجود یک آسیب‌پذیری فوری نیست، اما سطح ریسک را بالا می‌برد و در صورت وقوع container escape، پیامد حادثه را بسیار شدیدتر می‌کند.یک رویکرد منطقی برای production این است:application را با user غیر root اجرا کنید.همهٔ capabilityها را حذف و فقط موارد ضروری را اضافه کنید.allowPrivilegeEscalation را غیرفعال کنید.root filesystem را تا حد امکان read-only کنید.package را در runtime نصب نکنید.Docker socket و mountهای حساس را وارد container نکنید.این سیاست‌ها را با admission control enforce کنید.برای رفتار runtime نیز از ابزارهایی مانند Falco یا Tetragon کمک بگیرید.امنیت کانتینر با یک flag حل نمی‌شود. اما همین تغییرهای به‌ظاهر ساده، مثل حذف root، می‌توانند فاصلهٔ بین یک incident محدود و compromise شدن کل host را بسیار زیاد کنند.سپهر فصیحی - Sepehr Fassihiسپهر فصیحی - Sepehr FassihiWed, 23 Sep 2026 13:38:46 +0330https://virgool.ir/@sepehrfci/deployment-در-kubernetes-نسخه-بندی-و-به-روزرسانی-اپلیکیشن-ها-vgk1kdsholfrسلام دوستان Kubernetes‌باز! 🌟 امیدوارم توی دنیای پرچالش و پرهیجان Kubernetes هنوز از هیجان نیوفته باشید! توی این مقاله می‌خواهیم به یکی از قابلیت‌های خیلی مهم Kubernetes بپردازیم که بدون شک کار شما رو خیلی راحت‌تر می‌کنه: Deployment‌ها.اگر شما هم از اون دست افرادی هستید که همیشه وقتی اپلیکیشنی رو به‌روزرسانی می‌کنید، می‌ترسید که ممکنه چیزی خراب بشه یا سرور بهم بریزه، پس این مقاله مخصوص شماست! 😬 بریم سراغ اینکه چطور با استفاده از Deployments در Kubernetes، اپلیکیشن‌هاتون رو بدون دردسر و با خیال راحت به‌روزرسانی کنید.تو این مقاله چی یاد می‌گیریم؟ 📚Deployment در Kubernetes چیست؟چگونه می‌توانیم اپلیکیشن‌ها رو به‌روزرسانی کنیم بدون اینکه سیستم کرش کنه.مفهوم Rolling Update و چطور باعث می‌شود که بدون قطعی، به‌روزرسانی‌ها انجام بشه.پیاده‌سازی نسخه‌بندی در Kubernetes با استفاده از Deployment.Deployment در Kubernetes: چه کاربردی داره؟وقتی شما اپلیکیشن‌ها رو توی Kubernetes می‌سازید و اجرا می‌کنید، نیاز دارید که اون‌ها رو به راحتی و بدون اینکه مشکل پیش بیاد، به‌روزرسانی کنید. اینجاست که Deployment وارد میشه! 🤩تعریف ساده:Deployment در Kubernetes یه شیء (object) هست که به شما این امکان رو می‌ده که اپلیکیشن‌ها رو با راحتی و انعطاف‌پذیری بالا مدیریت کنید. یعنی شما می‌تونید تعداد مشخصی Pod رو در کلاستر Kubernetes تعریف کنید و Kubernetes وظیفه مقیاس‌پذیری، نسخه‌بندی، و به‌روزرسانی اون‌ها رو به عهده می‌گیره.چه مشکلی رو حل می‌کنه؟نسخه‌بندی: به راحتی می‌تونید نسخه‌های مختلف اپلیکیشن رو مدیریت کنید.Rolling Update: به‌روزرسانی‌ها به صورت مرحله به مرحله و بدون ایجاد قطعی انجام میشه. به این معنی که حتی وقتی آپدیت می‌کنید، کاربران متوجه قطعی یا downtime نمی‌شن.Rollback: اگه آپدیت جدید مشکلی ایجاد کنه، می‌تونید خیلی راحت به نسخه قبلی برگردید. یعنی مثل جادو عمل می‌کنه! 🔮چطور با استفاده از Deployment اپلیکیشن‌ها رو به‌روزرسانی کنیم؟Rolling Update: چطور به‌روزرسانی بدون قطعی داشته باشیم؟حالا فرض کنید شما یه اپلیکیشن دارید که یه مدت کار کرده، اما حالا می‌خواهید یه ویژگی جدید بهش اضافه کنید یا باگ‌هاش رو اصلاح کنید. وقتی بخواهید اپلیکیشن رو به‌روزرسانی کنید، ممکنه نگرانی‌هایی داشته باشید که "آیا کاربران من به مشکل می‌خورن؟" یا "آیا سیستم از کار می‌افته؟"کدوم آدمی دوست داره وسط کارش قطعی پیش بیاد؟ 😅 هیچ‌کس! خب، اینجاست که Rolling Update به کمک شما میاد.چطور کار می‌کنه؟در Rolling Update، Kubernetes به طور تدریجی و مرحله به مرحله Podهای قدیمی رو با Podهای جدید جایگزین می‌کنه. به این صورت، همیشه تعدادی از Podها فعال و در حال سرویس‌دهی هستن و هیچ قطعی به وجود نمیاد. به طور مثال، اگه شما ۳ Pod دارید، Kubernetes ابتدا یک Pod قدیمی رو حذف می‌کنه و سپس یک Pod جدید رو راه‌اندازی می‌کنه. این فرآیند به همین صورت ادامه پیدا می‌کنه تا تمام Podها به‌روزرسانی بشن.بیشتر از این نمی‌شه راحت!نسخه‌بندی در Kubernetes با استفاده از Deploymentچرا نسخه‌بندی مهمه؟در دنیای واقعی، هیچ‌وقت نمی‌خواهید که آخرین نسخه اپلیکیشن شما باعث از کار افتادن همه چیز بشه. پس داشتن نسخه‌های مختلف و امکان برگشت به نسخه‌های قبلی، یک ضرورت است. این ویژگی در Kubernetes به راحتی از طریق Deployment قابل دسترسی است.چطور نسخه‌بندی کنیم؟وقتی شما یک Deployment جدید می‌سازید یا یک اپلیکیشن رو به‌روزرسانی می‌کنید، می‌تونید ورژن‌های مختلف رو مشخص کنید. اینکار می‌تونه با استفاده از image جدیدی که در فایل YAML مشخص می‌کنید، انجام بشه.نمونه کد:apiVersion: apps/v1 kind: Deployment metadata: name: nginx-deployment spec: replicas: 3 selector: matchLabels: app: nginx template: metadata: labels: app: nginx spec: containers: - name: nginx image: nginx:1.19.0 # اینجا نسخه جدید رو مشخص می‌کنید ports: - containerPort: 80با این کد، شما دارید به Kubernetes می‌گید که از نسخه‌ی nginx:1.19.0 استفاده کن و اون رو به‌طور خودکار برای شما به‌روزرسانی کنه.Rollback: وقتی که به‌روزرسانی جواب نمی‌ده 😬حتماً شما هم این تجربه رو داشتید که یک‌سری تغییرات انجام بدید و بعد ببینید که "اوops، این یکی اشتباه بود!" و خب، اینجا Kubernetes برای شما امکان Rollback رو فراهم کرده. با استفاده از فرمان kubectl rollout undo، می‌تونید به راحتی به نسخه قبلی برگردید.نمونه دستور Rollback:kubectl rollout undo deployment/nginx-deploymentبه همین راحتی! بعد از این دستور، Kubernetes به‌طور خودکار نسخه قبلی اپلیکیشن شما رو بازیابی می‌کنه و کاربران هیچ‌چیز متوجه نمی‌شن! 😎نتیجه‌گیریحالا که Deployment رو شناختید، می‌دونید چطور از این ابزار قدرتمند برای به‌روزرسانی و نسخه‌بندی اپلیکیشن‌ها استفاده کنید. با استفاده از Rolling Update، می‌تونید به راحتی اپلیکیشن‌هاتون رو بدون قطعی و مشکلات دیگه به‌روزرسانی کنید و با امکان Rollback هم، هیچ نگرانی از بابت اشتباهات ندارید.Kubernetes همیشه توی گوش شما می‌گه: "نگران نباش، من همه چی رو برات درست می‌کنم!" 😅نظر شما چیه؟ شما چطور اپلیکیشن‌هاتون رو به‌روزرسانی می‌کنید؟ سوالات و تجربیات خودتون رو تو کامنت‌ها بنویسید! 😊سپهر فصیحی - Sepehr Fassihiسپهر فصیحی - Sepehr FassihiSat, 23 Nov 2024 23:48:36 +0330https://virgool.ir/@sepehrfci/replicationcontroller-و-replicaset-مدیریت-مقیاس-پذیری-در-kubernetes-️-zmidh8dpxadsسلام دوستان Kubernetes‌باز! 😄 اینبار قراره راجع به یکی از بخش‌های کلیدی مقیاس‌پذیری در Kubernetes صحبت کنیم: ReplicationController و ReplicaSet. اگر هنوز با این دو مفهوم آشنا نیستید، نگران نباشید! این مقاله بهتون کمک می‌کنه تا بفهمید این دو چی هستن و چطور می‌تونید از اون‌ها برای مدیریت اپلیکیشن‌های خودتون استفاده کنید. آماده‌اید که مقیاس Kubernetes رو به سقف برسونید؟ 🚀تو این مقاله چی یاد می‌گیریم؟ 📚تفاوت‌های کلیدی بین ReplicationController و ReplicaSet.چگونه می‌توانید با استفاده از این‌ها اپلیکیشن‌های مقیاس‌پذیر بسازید.چرا ReplicaSet جایگزین ReplicationController شد.استفاده عملی از ReplicationController و ReplicaSet در Kubernetes.ReplicationController چیه؟قبل از اینکه وارد بحث ReplicaSet بشیم، باید بدونیم که ReplicationController (RC) چی هست. در Kubernetes، این ابزار برای اطمینان از تعداد مشخصی از Pods در هر زمان کار می‌کنه. به عبارت ساده‌تر، اگر شما ۳ Pod مشخص کرده باشید، ReplicationController هر وقت یکی از اون‌ها از بین بره، یه Pod جدید می‌سازه.تعریف ساده:ReplicationController یه شیء در Kubernetes است که تعداد دقیق Podها رو بر اساس نیاز شما نگه می‌داره و در صورت از دست رفتن Pod، Pod جدید می‌سازه.چرا به ReplicationController نیاز داریم؟مقیاس‌پذیری: به راحتی می‌تونید تعداد Podها رو افزایش یا کاهش بدید.اطمینان از در دسترس بودن: حتی اگر یکی از Podها سقوط کنه، ReplicationController به‌طور خودکار یک Pod جدید راه‌اندازی می‌کنه.ReplicaSet چیه و چه تفاوتی با ReplicationController داره؟حالا که با ReplicationController آشنا شدیم، می‌خوایم بریم سراغ ReplicaSet. شاید بگید "آخه این دو که خیلی شبیه هم هستن!" بله، حق با شماست، اما خب! همیشه یه چیزی هست که این‌ها رو از هم متمایز می‌کنه. 😅تفاوت‌های اصلی:نسخه‌ جدیدتر: در واقع، ReplicaSet نسخه پیشرفته‌تر ReplicationController است و ویژگی‌های بیشتری داره.استفاده از Label Selector: یکی از ویژگی‌های مهم ReplicaSet اینه که به شما اجازه می‌ده از label selector برای انتخاب Podها استفاده کنید. این ویژگی به شما امکان می‌ده که دقیقاً Pods‌هایی رو که می‌خواهید مقیاس‌پذیر بشن، انتخاب کنید.بهبود در همگام‌سازی با Deployments: یکی دیگه از تفاوت‌ها اینه که ReplicaSet بیشتر در هم‌گامی با Deployments استفاده میشه و عملکرد بهتری در این زمینه داره.تعریف ساده:ReplicaSet هم مثل ReplicationController مسئول اطمینان از تعداد مشخصی از Pods در کلاستر است، ولی امکانات بیشتری داره که مدیریت اپلیکیشن‌ها رو راحت‌تر می‌کنه.چرا ReplicaSet به ReplicationController ترجیح داده می‌شود؟1. استفاده بهتر از Label Selector:با استفاده از label selector در ReplicaSet می‌تونید دقیقاً مشخص کنید که چه Pods‌هایی باید مقیاس‌پذیر بشن. این ویژگی باعث میشه که شما کنترل بیشتری روی انتخاب Pods‌هاتون داشته باشید.2. هم‌گامی با Deployments:ReplicaSet به‌طور طبیعی به Deployments متصل میشه و باعث میشه که زمانی که شما Deployment جدیدی ایجاد می‌کنید، ReplicaSet به صورت خودکار Pods رو مدیریت کنه. این هماهنگی باعث میشه که مدیریت اپلیکیشن‌ها ساده‌تر بشه.3. ارتقاء آسان:به کمک ReplicaSet، می‌تونید به راحتی اپلیکیشن‌ها رو مقیاس‌پذیر کنید و در مواقعی که نیاز به ارتقا دارید، ReplicaSet به شما اجازه می‌ده که نسخه‌های جدید اپلیکیشن رو جایگزین نسخه‌های قبلی کنید.چطور از ReplicationController و ReplicaSet استفاده کنیم؟حالا که تفاوت‌های این دو رو فهمیدیم، وقتشه که ببینیم چطور می‌تونیم از این‌ها توی پروژه‌ها و اپلیکیشن‌های خودمون استفاده کنیم.نمونه کد ReplicationController:apiVersion: v1 kind: ReplicationController metadata: name: nginx-controller spec: replicas: 3 selector: app: nginx template: metadata: labels: app: nginx spec: containers: - name: nginx image: nginx:latestنمونه کد ReplicaSet:apiVersion: apps/v1 kind: ReplicaSet metadata: name: nginx-replicaset spec: replicas: 3 selector: matchLabels: app: nginx template: metadata: labels: app: nginx spec: containers: - name: nginx image: nginx:latestنتیجه‌گیریدر نهایت، ReplicationController و ReplicaSet هر دو ابزارهایی هستند که برای مقیاس‌پذیری و مدیریت Pods در Kubernetes استفاده می‌شن. اما با توجه به ویژگی‌های پیشرفته‌تر، ReplicaSet به‌طور گسترده‌تری استفاده میشه و توصیه میشه که به جای ReplicationController، از ReplicaSet استفاده کنید.با استفاده از این دو ابزار، می‌تونید اپلیکیشن‌های مقیاس‌پذیر و پایدار بسازید که در مواجهه با مشکلات، خود به خود مقیاس‌پذیر بشن و از بین نرن.نظر شما چیه؟ کدوم یکی از این ابزارها رو بیشتر استفاده کردید؟ یا شاید سوالی دارید؟ خوشحال می‌شیم تو کامنت‌ها باهامون در میون بذارید! 😊سپهر فصیحی - Sepehr Fassihiسپهر فصیحی - Sepehr FassihiSat, 23 Nov 2024 23:38:15 +0330https://virgool.ir/@sepehrfci/volumes-در-kubernetes-مدیریت-داده-ها-در-کانتینرها-qjyrs0r2gwdkسلام دوستان Kubernetes‌باز! 😄 امروز می‌خوایم یکی از مهم‌ترین موضوعات توی Kubernetes رو بررسی کنیم: Volumes.Volumes به ما کمک می‌کنه که داده‌ها رو توی کانتینرها مدیریت کنیم و اون‌ها رو برای همیشه نگه داریم، حتی وقتی کانتینرها از بین رفتن. آماده‌اید؟ بزنید بریم! 🚀تو این مقاله چی یاد می‌گیریم؟ 📚Volumes چیه و چرا لازمه؟انواع Volume‌ها تو Kubernetes.فرق Volume‌ها با Storage‌های معمولی.مثال‌های کاربردی از استفاده از Volumes.Volumes چیه و چرا بهش نیاز داریم؟کانتینرها توی Kubernetes خیلی انعطاف‌پذیرن، ولی یه مشکل دارن: داده‌هایی که توی کانتینر ذخیره می‌شن فرّارن. یعنی اگه کانتینر حذف بشه یا ری‌استارت بشه، همه داده‌ها از بین میرن. 😱اینجاست که Volumes وارد بازی میشه!تعریف ساده:Volume در Kubernetes یه فضای ذخیره‌سازیه که به Podها وصل میشه و داده‌ها رو حتی بعد از حذف کانتینر نگه می‌داره.چرا Volumes مهمه؟پایداری داده‌ها: داده‌ها بعد از ری‌استارت یا حذف کانتینر، همچنان موجودن.اشتراک داده: کانتینرهای مختلف می‌تونن از یه Volume مشترک استفاده کنن.انعطاف‌پذیری: می‌تونید انواع مختلفی از Volume رو بسته به نیازتون استفاده کنید.انواع Volume‌ها تو Kubernetesتوی Kubernetes انواع مختلفی از Volumes وجود داره که هر کدوم برای موقعیت خاصی طراحی شدن. بیایید رایج‌ترین‌ها رو بررسی کنیم:1. emptyDir 🗂این Volume وقتی Pod ساخته میشه، ایجاد میشه و وقتی Pod حذف میشه، Volume هم از بین میره.کاربرد:ذخیره داده‌های موقتی.به اشتراک‌گذاری داده بین کانتینرهای یک Pod.مثال:فرض کنید یه کانتینر داده‌ها رو دانلود می‌کنه و کانتینر دیگه اون داده‌ها رو پردازش می‌کنه.2. hostPath 🖥️این Volume به یه دایرکتوری روی سرور فیزیکی (Node) متصل میشه.کاربرد:دسترسی به فایل‌های سیستمی سرور.ثبت لاگ‌ها به صورت مستقیم روی سرور.توجه:استفاده از این Volume خطرناکه چون وابسته به سرور خاصه.3. persistentVolume (PV) و persistentVolumeClaim (PVC) 💾این‌ها بهترین روش برای ذخیره‌سازی پایدار هستن.PV: منابع ذخیره‌سازی‌ای که ادمین‌ها تعریف می‌کنن.PVC: درخواست‌هایی که Podها برای استفاده از PV ارسال می‌کنن.کاربرد:ذخیره داده‌هایی که باید برای مدت طولانی نگه داشته بشن.اپلیکیشن‌های دیتابیس مثل MySQL یا MongoDB.4. configMap و secret 🔑این‌ها برای مدیریت داده‌های حساس و فایل‌های تنظیمات استفاده میشن.کاربرد:ذخیره تنظیمات اپلیکیشن.نگهداری رمزعبورها یا کلیدهای API.تفاوت:configMap: برای داده‌های غیرحساس.secret: برای داده‌های رمزنگاری‌شده و حساس.5. دیگر Volume‌هاnfs: برای اشتراک‌گذاری داده بین Podها در چند Node.azureDisk / awsElasticBlockStore: مخصوص ذخیره‌سازی در محیط‌های ابری.csi: برای استفاده از درایورهای ذخیره‌سازی سفارشی.فرق Volume‌ها با Storage‌های معمولیوقتی درباره ذخیره‌سازی صحبت می‌کنیم، شاید فکر کنید Volume مثل یه هارد دیسکه. ولی تفاوت‌های مهمی وجود داره:Volume‌ها وابسته به Kubernetes هستن: شما نمی‌تونید از یه Volume خارج از Kubernetes استفاده کنید.مدیریت خودکار: Kubernetes می‌تونه Volume‌ها رو به صورت پویا مدیریت کنه.یه مثال عملی: استفاده از PVC برای ذخیره دادهبیایید یه Volume پایدار (Persistent Volume) بسازیم و توی یه Pod ازش استفاده کنیم.ایجاد Persistent Volume (PV):apiVersion: v1 kind: PersistentVolume metadata: name: my-pv spec: capacity: storage: 1Gi accessModes: - ReadWriteOnce hostPath: path: "/mnt/data" ایجاد Persistent Volume Claim (PVC):apiVersion: v1 kind: Pod metadata: name: my-pod spec: containers: - name: nginx image: nginx volumeMounts: - mountPath: "/usr/share/nginx/html" name: my-storage volumes: - name: my-storage persistentVolumeClaim: claimName: my-pvc اتصال PVC به یک Pod:apiVersion: v1 kind: Pod metadata: name: my-pod spec: containers: - name: nginx image: nginx volumeMounts: - mountPath: "/usr/share/nginx/html" name: my-storage volumes: - name: my-storage persistentVolumeClaim: claimName: my-pvc نتیجه‌گیریVolumes در Kubernetes یکی از ابزارهای کلیدی برای مدیریت داده‌هاست. چه داده‌های موقت داشته باشید و چه داده‌های حساس و پایدار، Volume‌ها به شما انعطاف‌پذیری لازم رو میدن.از emptyDir گرفته تا PV و PVC، هر کدوم برای نیاز خاصی طراحی شدن و استفاده درست از اون‌ها می‌تونه بهره‌وری شما رو بالا ببره. تو مقاله‌های بعدی، عمیق‌تر به این موضوعات می‌پردازیم.نظر شما چیه؟ از چه نوع Volume تو پروژه‌هاتون بیشتر استفاده می‌کنید؟ سوالات و نظراتتون رو حتما تو کامنت‌ها بنویسید! 😊سپهر فصیحی - Sepehr Fassihiسپهر فصیحی - Sepehr FassihiSat, 23 Nov 2024 22:45:43 +0330https://virgool.ir/@sepehrfci/namespace-در-kubernetes-تفکیک-محیط-ها-به-سبک-حرفه-ای-vocqsymaqbrsسلام به همه دوستان Kubernetes باز! 😊 امروز قراره درباره یکی از مفاهیم جذاب و کاربردی Kubernetes صحبت کنیم: Namespace. این ابزار قدرتمند همون چیزی‌ست که بهتون اجازه میده محیط‌های مختلف رو از هم جدا کنید و تو یه کلاستر بزرگ، همه چیز رو مرتب و تمیز نگه دارید.تو این مقاله چه چیزی یاد می‌گیریم؟ 📚Namespace چیه و چرا وجودش لازمه؟چطوری محیط‌های جداگانه بسازیم؟استفاده از Namespace چه مزایایی داره؟چند مثال کاربردی از دنیای واقعی.اگه آماده‌اید بزنید بریم، چون Namespace می‌تونه کلا دیدتون به Kubernetes رو عوض کنه! 🚀Namespace چیه؟ 🤔Namespace در Kubernetes یه روش برای تقسیم‌بندی منطقی منابع توی یه Cluster هست.تصور کنید یه شهر شلوغ دارید و می‌خواید هر محله قوانینی برای خودش داشته باشه. Namespace مثل همین محله‌هاست که به شما کمک می‌کنه منابع رو از هم جدا کنید.تعریف ساده:Namespace‌ها تو Kubernetes، محیط‌های جداگانه‌ای هستن که می‌تونید توش سرویس‌ها، Podها، و منابع مختلف رو بدون تداخل مدیریت کنید.ویژگی‌های Namespace:جداسازی: هر Namespace منابع خودش رو داره.مدیریت بهتر: می‌تونید دسترسی و قوانین جداگانه برای هر Namespace تعریف کنید.مقیاس‌پذیری: برای پروژه‌های بزرگ فوق‌العاده‌ست.چرا Namespace لازم داریم؟ 🔍بدون Namespace، تمام منابع تو یه محیط واحد (Default) قرار می‌گیرن. این یعنی:شلوغی بیش از حد: اگه پروژه‌های مختلف تو یه Cluster کار کنن، مدیریت سخت میشه.ریسک تداخل: ممکنه منابع با اسم‌های مشابه، با هم تداخل پیدا کنن.عدم امنیت: نمی‌تونید دسترسی‌ها رو برای پروژه‌های مختلف کنترل کنید.Namespace همه این مشکلات رو حل می‌کنه.مثال ساده:فرض کنید شما یه شرکت بزرگ دارید و توش چند تیم مختلف کار می‌کنن. هر تیم نیاز داره که فضای مخصوص به خودش رو داشته باشه، درست مثل Namespace.Namespace پیش‌فرض در Kubernetesوقتی یه Cluster جدید ایجاد می‌کنید، Kubernetes خودش چند Namespace پیش‌فرض براتون می‌سازه:default: اینجا جاییه که منابعی که Namespace خاصی ندارن، ذخیره میشن.kube-system: برای سرویس‌های داخلی Kubernetes مثل Scheduler و Controller Manager.kube-public: برای منابع عمومی که همه می‌تونن ببینن (ولی معمولاً کمتر استفاده میشه).kube-node-lease: برای مدیریت Heartbeat‌های Node‌ها.این Namespace‌ها همیشه هستن، ولی شما می‌تونید Namespace‌های جدید برای پروژه‌های خاص بسازید.چطور Namespace بسازیم؟ ✍️ساخت Namespace تو Kubernetes خیلی ساده‌ست:روش اول: با استفاده از فایل YAMLیه فایل YAML مثل این ایجاد کنید:apiVersion: v1 kind: Namespace metadata: name: my-namespace بعد دستور زیر رو اجرا کنید:kubectl apply -f namespace.yamlروش دوم: با استفاده از خط فرماناگه حوصله نوشتن YAML ندارید، این دستور رو بزنید:kubectl create namespace my-namespaceحالا یه Namespace جدید دارید که آماده پذیرش منابعه. 🎉استفاده از Namespaceوقتی Namespace ساختید، می‌تونید منابع مثل Pod، Service، و Deployment رو داخلش قرار بدید.اضافه کردن منابع به Namespace:توی فایل YAML منابع، اسم Namespace رو مشخص کنید:apiVersion: v1 kind: Pod metadata: name: my-pod namespace: my-namespace spec: containers: - name: nginx image: nginx یا موقع استفاده از kubectl، Namespace رو مشخص کنید:kubectl run nginx --image=nginx --namespace=my-namespaceمزایای استفاده از Namespace 🌟مدیریت بهتر منابع: برای پروژه‌های بزرگ که چند تیم روی یه Cluster کار می‌کنن، عالیه.کنترل دسترسی: می‌تونید برای هر Namespace دسترسی‌های جداگانه تعریف کنید.جلوگیری از تداخل: منابع با اسم‌های مشابه تو Namespace‌های جداگانه، تداخلی ندارن.تست محیط‌های مختلف: می‌تونید محیط‌های Development، Staging، و Production رو جدا کنید.مثال واقعی: تفکیک محیط‌هافرض کنید یه تیم DevOps دارید که روی یه اپلیکیشن بزرگ کار می‌کنه. شما نیاز دارید که محیط‌های Development، Testing، و Production کاملاً از هم جدا باشن:برای محیط Development، یه Namespace به اسم dev بسازید.برای محیط Testing، یه Namespace به اسم test بسازید.برای محیط Production، یه Namespace به اسم prod بسازید.حالا هر تیم می‌تونه تو Namespace خودش کار کنه، بدون اینکه با بقیه تیم‌ها تداخل داشته باشه. 😎نتیجه‌گیریNamespace یه ابزار ساده ولی قدرتمنده که مدیریت منابع تو Kubernetes رو راحت‌تر و بهینه‌تر می‌کنه. با استفاده از Namespace می‌تونید پروژه‌های مختلف رو تو یه Cluster اجرا کنید، بدون اینکه سردرگم بشید یا نگران تداخل منابع باشید.پس از همین امروز شروع کنید به استفاده از Namespace و محیط کاری خودتون رو حرفه‌ای‌تر کنید. Kubernetes همیشه یه چیز جدید برای یادگیری داره، پس مقالات بعدی رو از دست ندید! 🚀نظر شما چیه؟ آیا تا حالا از Namespace استفاده کردید؟ اگه سوالی دارید یا موضوع خاصی رو می‌خواید یاد بگیرید، تو کامنت‌ها بگید! 😊سپهر فصیحی - Sepehr Fassihiسپهر فصیحی - Sepehr FassihiSat, 23 Nov 2024 22:31:25 +0330https://virgool.ir/@sepehrfci/هوش-مصنوعی-برای-همه-ساده-ترین-ابزارهای-ai-که-می-توانید-امتحان-کنید-iltxbetllchaسلام دوستان! 🎉 امروز قراره باهم بریم سراغ یه موضوع جذاب که شاید فکر کنید فقط برای نابغه‌های کامپیوتره، اما این‌طور نیست! هوش مصنوعی (Artificial Intelligence - AI) دیگه فقط برای دانشمندها و برنامه‌نویس‌ها نیست؛ ابزارهایی ساخته شدن که هر کسی، حتی اگر با کامپیوتر مثل گاو (اون هم گاو مهربون!) آشنا باشه، می‌تونه ازشون استفاده کنه. 😅در این مقاله، یاد می‌گیریم:هوش مصنوعی چطوری می‌تونه به درد زندگی ما بخوره؟معرفی ابزارهای ساده و کاربردی AI که امتحانشون برای همه ممکنه.چطور از این ابزارها استفاده کنیم بدون اینکه سرمون گیج بره؟خب، آماده‌اید؟ بریم که داشته باشیم! 🚀هوش مصنوعی، ولی ساده‌تر از چیزی که فکر می‌کنید! 😌شاید شنیدید که هوش مصنوعی خیلی پیچیدست و نیاز به کدنویسی و سرورهای قوی داره. اما خبر خوب اینه که امروزه کلی ابزار ساده و کاربرپسند طراحی شده که هر کسی می‌تونه ازشون استفاده کنه.فرض کنید یه آشپزی هست که نمی‌دونه چی بپزه؛ یا یه دانشجویی که می‌خواد خلاصه یه کتاب رو دربیاره. هوش مصنوعی مثل یه دستیار همه‌کاره کنارتونه و می‌گه: "بیا من برات درستش می‌کنم!" 🤖✨اگر به یک کانفیگ پر سرعت🚀، بدون قطعی🔥، قیمت مناسب💸(حتی با 30 هزارتومان!!!) و پشتیبانی عالی💣 جهت دور زدن تحریم های اینترنتی داشتین ما میتونیم به شما نهایت کمک رو کنیم!! (برای استفاده از همین ابزار های هوش مصنوعی هم نیاز بهم همین کانفیگ ها دارین) جهت تست رایگان و تهیه کانفیگ و آموزش نحوه استفاده وارد ربات زیر در تلگرام بشید تا در کسری از ثانیه ما براتون دنیا 🌍 رو تغییر بدیم!!ورود به ربات تلگرام🤖ابزارهای هوش مصنوعی که باید امتحان کنید1. ChatGPT: دستیار همه‌فن‌حریف برای گفتگو و کمک‌های روزمرهخب، بریم سراغ Chat GPTبا این ابزار، می‌تونید:ازش بپرسید امروز چی بپزید؟برای یه متن رسمی کمک بخواید.حتی براش جک تعریف کنید و ببینید چطوری واکنش نشون می‌ده.مثال:شما: "یه برنامه غذایی برای یه هفته می‌خوام."ChatGPT: "خیلی خب، صبحانه نون تست و آووکادو... ناهار ماکارونی با سس پستو... شام سوپ عدس."این ابزار برای کسایی که دنبال یه مشاور سریع و رایگان هستن، عالیه. استفاده‌ش هم آسونه: فقط باید به وب‌سایت OpenAI برید یا از اپلیکیشنش استفاده کنید.2. Canva: طراحی حرفه‌ای بدون نیاز به فتوشاپاگر مثل من تو طراحی گرافیک افتضاحید، Canva نجات‌دهنده‌تونه. این ابزار یه قابلیت هوش مصنوعی داره که به شما کمک می‌کنه طرح‌هایی حرفه‌ای و زیبا بسازید. از طراحی کارت‌پستال گرفته تا پست‌های اینستاگرام.چرا Canva جالبه؟قالب‌های آماده.پیشنهاد رنگ‌ها و ترکیب‌ها توسط AI.حتی می‌تونه عکستون رو بهتر کنه.مثال:تصور کنید یه پیج اینستاگرام دارید و نمی‌دونید چی طراحی کنید. Canva به شما می‌گه: "نگران نباش، من اینجام!"3. Grammarly: ویرایشگر متن که همیشه مواظب شماستاگه مثل من گاهی دستتون می‌لرزه موقع نوشتن، Grammarly بهترین دوستتونه. این ابزار متن‌های شما رو چک می‌کنه و می‌گه:"اینجا یه کاما اضافه گذاشتی!""بهتره این کلمه رو عوض کنی."چرا عالیه؟مناسب برای ایمیل‌های کاری.تقویت مهارت‌های نگارش انگلیسی.یه نسخه رایگان داره که کلی امکانات خوب می‌ده.4. Lumen5: ساخت ویدیو برای کسایی که از ادیت متنفرنمی‌خواید یه ویدیوی باحال بسازید ولی بلد نیستید؟ Lumen5 به کمک هوش مصنوعی متن شما رو به یه ویدیو حرفه‌ای تبدیل می‌کنه. فقط کافیه متن رو وارد کنید، موسیقی و تم انتخاب کنید و تمام!مثال:شما: "یه ویدیو برای معرفی کسب‌وکارم می‌خوام."Lumen5: "در خدمتتم! بیا اینم ویدیو!"اگر به یک کانفیگ پر سرعت🚀، بدون قطعی🔥، قیمت مناسب💸(حتی با 30 هزارتومان!!!) و پشتیبانی عالی💣 جهت دور زدن تحریم های اینترنتی داشتین ما میتونیم به شما نهایت کمک رو کنیم!! (برای استفاده از همین ابزار های هوش مصنوعی هم نیاز بهم همین کانفیگ ها دارین) جهت تست رایگان و تهیه کانفیگ و آموزش نحوه استفاده وارد ربات زیر در تلگرام بشید تا در کسری از ثانیه ما براتون دنیا 🌍 رو تغییر بدیم!!ورود به ربات تلگرام🤖5. Remove.bg: حذف پس‌زمینه عکس در یک ثانیه!تا حالا خواستید پس‌زمینه یه عکس رو حذف کنید ولی نرم‌افزار فتوشاپ رو نداشتید؟ Remove.bg به کمک شما می‌آد. فقط عکس رو آپلود کنید و هوش مصنوعی خودش پس‌زمینه رو حذف می‌کنه.مثال:یه عکس از خودتون تو یه مهمونی دارید و می‌خواید فقط چهره‌تون باشه؟ به‌راحتی انجام می‌شه!چطور این ابزارها زندگی ما رو راحت‌تر می‌کنن؟این ابزارها به ما نشون می‌دن که لازم نیست دانشمند باشیم تا از تکنولوژی استفاده کنیم. هوش مصنوعی مثل اون دوست زرنگ کلاسه که همه تکلیف‌ها رو برات حل می‌کنه، فقط کافیه ازش بخوای!جمع‌بندیخب دوستان، دیدید که هوش مصنوعی اون‌قدرها هم پیچیده نیست. ابزارهایی مثل ChatGPT، Canva، Grammarly، Lumen5 و Remove.bg به همه کمک می‌کنن زندگی‌شون رو راحت‌تر و جذاب‌تر کنن. اگر هنوز امتحانشون نکردید، همین الان شروع کنید.و یادتون باشه، دنیا داره تغییر می‌کنه؛ بهتره سوار موج بشیم، نه اینکه زیرش غرق بشیم! 🌊✨نظر شما چیه؟ دوست دارید از کدوم ابزار استفاده کنید؟ زیر همین پست برامون بنویسید یا به یه نفر که به این ابزارها نیاز داره معرفی کنید! 💬سپهر فصیحی - Sepehr Fassihiسپهر فصیحی - Sepehr FassihiTue, 19 Nov 2024 23:38:10 +0330https://virgool.ir/@sepehrfci/مفاهیم-کلیدی-kubernetes-pod-node-و-cluster-ldruoeocliquسلام رفقا! امروز قراره با پایه‌های Kubernetes آشنا بشیم. بدون شناخت این مفاهیم، Kubernetes مثل یه جنگل مه‌آلود می‌مونه که نمی‌دونید از کجا شروع کنید. اما نگران نباشید، بعد از این مقاله، دیدتون روشن میشه! 🌟 تو این مقاله چه چیزی یاد می‌گیریم؟ Pod چیه و چه نقشی داره؟ Node چیه و چرا بهش نیاز داریم؟ Cluster چیه و چطوری همه چیز رو به هم متصل می‌کنه؟ مثال‌های ساده و کاربردی برای فهم بهتر این مفاهیم. پس اگر آماده‌اید، بزنید بریم که Kubernetes رو بشکافیم! 😊 Pod: کوچک‌ترین واحد اجرایی در Kubernetesوقتی اسم Kubernetes میاد، اولین چیزی که باید بشناسیدPod هست. تعریف ساده: Pod در Kubernetes، یه "بسته"‌ست که کانتینرها رو شامل میشه. این بسته می‌تونه یک کانتینر داشته باشه یا چندتا کانتینر که با هم کار می‌کنن. ویژگی‌های Pod: 1. کانتینرهای درونش منابع رو به اشتراک میذارن: مثلاً حافظه، CPU، و شبکه. 2. هر Pod یه آدرس IP داره: انگار یه خونه مستقل تو یه شهر بزرگ باشه. 3. Pod‌ها معمولا کوتاه‌عمر هستن: یعنی اگر خراب بشن یا دیگه لازم نباشن، Kubernetes سریع اون‌ها رو جایگزین می‌کنه. یه مثال ساده: فرض کنید یه کافی‌شاپ دارید. هر Pod مثل یه میز توی کافی‌شاپه که مشتری‌ها (کانتینرها) می‌تونن روش بشینن و قهوه‌شون رو بخورن. هر میز یه شماره (آدرس IP) داره و مشتری‌ها به کمک اون شماره میز پیدا می‌کنن. Node: ستون فقرات کلاسترحالا که فهمیدید Pod چیه، بیایید ببینیم Node کجای این داستان قرار داره. تعریف ساده: Node یه سرور فیزیکی یا مجازی‌ست که Pod‌ها روی اون اجرا میشن. Kubernetes می‌تونه یه Node داشته باشه (مثل لپ‌تاپ شما) یا صدها Node (توی یه دیتاسنتر عظیم). دو نوع Node داریم:1. Master Node: این نود مغز متفکره و تصمیمات مدیریتی می‌گیره (مثل ایجاد یا حذف Pod‌ها). 2. Worker Node: این نودها کارها رو انجام میدن و Pod‌ها روی اون‌ها اجرا میشن. یه مثال ساده: فرض کنید یه کارخانه دارید. Master Node مثل مدیر کارخانه‌ست که به کارگرها (Worker Node‌ها) میگه چه کاری رو انجام بدن. کارگرها هم دستگاه‌ها (Pod‌ها) رو مدیریت می‌کنن. Cluster: جامعه‌ای از Node‌هاحالا که فهمیدید Pod و Node چیه، وقتشه مفهوم Cluster رو بشناسید. تعریف ساده:Cluster مجموعه‌ای از Node‌هاست که با هم کار می‌کنن و یه محیط یکپارچه برای اجرای برنامه‌ها ایجاد می‌کنن. Kubernetes مسئول مدیریت این Cluster‌ هست. چرا Cluster مهمه؟ - مقیاس‌پذیری: شما می‌تونید به تعداد دلخواه Node اضافه کنید. - پایداری: اگه یکی از Node‌ها خراب بشه، Cluster همچنان به کارش ادامه میده. - انعطاف‌پذیری: Cluster می‌تونه روی چند سرور فیزیکی یا تو فضای ابری باشه. یه مثال ساده: فرض کنید یه شهر دارید (Cluster). هر Node یه ساختمان توی این شهره، و هر ساختمون میزبان چند واحد آپارتمان (Pod) هست. Kubernetes شهردار این شهره که همه چیز رو مدیریت می‌کنه. ارتباط Pod، Node، و Cluster برای اینکه همه چیز واضح‌تر بشه، اجازه بدید یه داستان کوتاه تعریف کنم: 1. Cluster مثل یه شرکت بزرگه. 2. Node‌ها مثل تیم‌های مختلف این شرکت هستن (تیم مالی، تیم توسعه و...). 3. Pod‌ها مثل پروژه‌هایی هستن که هر تیم روش کار می‌کنه. Kubernetes هم نقش مدیرعامل رو داره که همه تیم‌ها و پروژه‌ها رو هماهنگ می‌کنه. نتیجه‌گیری تا اینجا فهمیدیم که: - Pod: کوچک‌ترین واحد اجرایی برای میزبانی کانتینرهاست. - Node: سرورهای فیزیکی یا مجازی برای اجرای Pod‌ها هستن. - Cluster: مجموعه‌ای از Node‌ها که Kubernetes مدیریت‌شون می‌کنه. این مفاهیم پایه‌ای، قلب Kubernetes هستن. تو مقالات بعدی بیشتر در مورد این موارد صحبت می‌کنیم و به جزئیات بیشتری وارد می‌شیم. پس آماده باشید که با Kubernetes حرفه‌ای‌تر بشید! 😊 نظر یا سوالی دارید؟ کامنت بذارید و بگید به چه مفاهیمی بیشتر علاقه دارید تا در مقالات بعدی پوشش بدیم. 🚀سپهر فصیحی - Sepehr Fassihiسپهر فصیحی - Sepehr FassihiTue, 19 Nov 2024 16:55:04 +0330https://virgool.ir/@sepehrfci/kubernetes-چیست-چرا-باید-از-آن-استفاده-کنیم-️-fraic52e2d3mسلام رفقا! تو این مقاله می‌خوایم با هم Kubernetes (همون K8s معروف) رو بشناسیم. قراره یه سفر جذاب به دنیای مدیریت کانتینرها داشته باشیم و ببینیم چرا Kubernetes اینقدر محبوبه. تو این مقاله چه چیزی یاد می‌گیریم؟ 📚 چرا Kubernetes به‌وجود اومد و چه مشکلاتی رو حل می‌کنه؟ Kubernetes چطوری کار می‌کنه و چه قابلیت‌هایی داره؟ اصطلاحات مهم Kubernetes که هر تازه‌کاری باید بدونه. یه مثال ساده و روزمره برای فهم بهتر Kubernetes. و در نهایت، چرا باید عاشق این ابزار بشید؟ 😊 خب، اگه آماده‌اید، بزنید بریم! 🚀 مشکل از کجا شروع شد؟ چرا به Kubernetes نیاز داریم؟ 🤔 تصور کنید یه اپلیکیشن ساده مثل "فروشگاه آنلاین نقره‌جات" نوشتید. روی لپ‌تاپتون همه چیز عالی کار می‌کنه. اما وقتی می‌خواید این اپلیکیشن رو برای هزاران کاربر اجرا کنید، مشکلات شروع میشه: نیاز به مقیاس‌پذیری (Scalability): وقتی تعداد کاربرا زیاد میشه، برنامه باید منابع بیشتری استفاده کنه. مدیریت آپدیت‌ها (Updates): چطور بدون قطعی برنامه‌تون رو آپدیت کنید؟ مدیریت خرابی‌ها (Failure Management): اگه یه بخش از سیستم خراب بشه، آیا کل سایت خاموش میشه؟ برای حل این چالش‌ها، کانتینرها (مثل Docker) معرفی شدن. کانتینرها برنامه‌تون رو با تمام وابستگی‌هاش تو یه بسته سبک قرار میدن. اما وقتی تعداد کانتینرها زیاد بشه، مدیریت‌شون خودش می‌تونه یه کابوس بشه! اینجاست که Kubernetes وارد میشه!🚀 Kubernetes (یا K8s) یه پلتفرم متن‌بازه که توسط گوگل طراحی شده. این ابزار به شما کمک می‌کنه کانتینرهای خودتون رو با خیال راحت اجرا، مدیریت و مقیاس‌پذیر کنید. قابلیت‌های اصلی Kubernetes:1. مقیاس‌پذیری خودکار (Auto Scaling): فرض کنید روز "بلک فرایدی" رسیده و فروشگاه آنلاین شما پر از بازدیدکننده شده. Kubernetes به‌طور خودکار تعداد کانتینرها رو زیاد می‌کنه تا برنامه شما بدون مشکل کار کنه. ۲. خودترمیمی (Self-Healing): 💪 اگه یکی از کانتینرها خراب بشه یا بیفته، Kubernetes یه نسخه جدید از همون کانتینر رو سریع اجرا می‌کنه. انگار یه تیم تعمیرکار حرفه‌ای ۲۴ ساعته در خدمت شماست! ۳. مدیریت آپدیت‌ها (Rolling Updates): Kubernetes به‌آرومی آپدیت‌ها رو اجرا می‌کنه. مثلاً نیمی از کاربرا نسخه جدید رو می‌بینن و نیمی دیگه همچنان با نسخه قبلی کار می‌کنن. چرا باید از Kubernetes استفاده کنیم؟ اگه هنوز شک دارید، بذارید چندتا دلیل خوب براتون بیارم: 1. کاهش هزینه‌ها: Kubernetes منابع رو بهینه استفاده می‌کنه؛ یعنی هزینه‌های سرور کمتر میشه. 2. توسعه سریع‌تر: توسعه‌دهنده‌ها می‌تونن روی نوشتن کد تمرکز کنن، چون Kubernetes مدیریت زیرساخت رو بر عهده می‌گیره. 3. سازگاری بالا (Portability): Kubernetes روی هر محیطی کار می‌کنه؛ از سرورهای محلی گرفته تا Cloudهایی مثل AWS، Azure و Google Cloud. 4. جامعه بزرگ: Kubernetes جامعه کاربری فعالی داره، یعنی همیشه منابع آموزشی، ابزارهای جدید و آدم‌هایی که کمک کنن پیدا میشن. چند اصطلاح کلیدی Kubernetes که باید بشناسیدCluster (کلاستر): مجموعه‌ای از سرورها (Nodes) که Kubernetes مدیریت می‌کنه. Node (نود): سرورهای فیزیکی یا مجازی که Pods روی اون‌ها اجرا میشن. Pod (پاد): کوچک‌ترین واحد اجرایی در Kubernetes که معمولاً شامل یک یا چند کانتینر هست. Service (سرویس): مکانیزمی برای مدیریت ارتباط بین Podها یا ارتباط کاربران با Podها. Namespace (نیم‌اسپیس): فضایی برای جداسازی منابع در Kubernetes (مثلاً برای محیط‌های مختلف توسعه، تست و تولید). یه مثال ساده برای درک Kubernetes🎯 فرض کنید شما یه پیتزافروشی دارید. هر مشتری که میاد، یکی از کارکنان شما باید یه پیتزا براش درست کنه. حالا تصور کنید شب جمعه باشه و پیتزافروشی شما پر از مشتری بشه: اگه کارکنان بیشتری داشته باشید، سفارش‌ها سریع‌تر آماده میشه. اگه یکی از کارکنان مریض بشه، باید سریع کسی جایگزینش کنید. اگه بخواید منوی جدید اضافه کنید، باید این کار بدون دردسر انجام بشه. Kubernetes دقیقاً همینه! کارکنان شما = کانتینرها، و Kubernetes = یه مدیر حرفه‌ای که همه چیز رو مدیریت می‌کنه. نتیجه‌گیری Kubernetes یه ابزار فوق‌العاده برای مدیریت برنامه‌ها در دنیای مدرنه. اگه دنبال راهی برای مقیاس‌پذیری، پایداری و مدیریت راحت‌تر برنامه‌هاتون هستید، Kubernetes همون چیزیه که دنبالشید. نظرت چیه؟ حتماً بگو! 😊سپهر فصیحی - Sepehr Fassihiسپهر فصیحی - Sepehr FassihiTue, 19 Nov 2024 15:38:39 +0330