راهنمای جامع: ساخت کلاستر Kubernetes (EKS) و گروه‌های امنیتی پیشرفته برای Podها در AWS

آماده‌سازی زیرساخت AWS: نقش‌ها و شبکه VPC

برای بهره‌برداری کامل از ویژگی Security Groups for Pods در Amazon EKS، آماده‌سازی دقیق زیرساخت AWS ضروری است. این فرآیند شامل تنظیم نقش‌های IAM، ایجاد VPC با زیرشبکه‌های مناسب، و پیکربندی اجزای شبکه است تا عملکرد صحیح و ایمن EKS و پشتیبانی از گروه‌های امنیتی در سطح پاد تضمین شود.

تعریف و پیکربندی نقش‌های IAM ضروری

قبل از ایجاد هر زیرساختی، تعریف نقش‌های IAM حیاتی است. این نقش‌ها مجوزهای لازم را برای سرویس‌های AWS مشخص می‌کنند و به عنوان شناسه‌ای عمل می‌کنند که سرویس‌ها برای اثبات صلاحیت خود ارائه می‌دهند. چندین نقش متمایز با مجوزهای خاص ایجاد خواهیم شد.

ابتدا، نقش IAM سرویس EKS را برای مدیریت خوشه ایجاد می‌کنیم. این نقش با برقراری رابطه اعتماد بین حساب AWS و EKS، به EKS امکان انجام اقدامات لازم را می‌دهد. دو سیاست مدیریت شده AWS، AmazonEKSClusterPolicy و AmazonEKSVPCResourceController، به این نقش متصل می‌شوند. سیاست دوم برای قابلیت Security Groups for Pods حیاتی است، زیرا به کنترلر منابع VPC امکان مدیریت ENIها و گروه‌های امنیتی را می‌دهد.

در ادامه، نقش IAM گره‌های کاری EC2 را می‌سازیم که پادها را اجرا می‌کنند. سیاست اعتماد این نقش `ec2.amazonaws.com` را سرویس مورد اعتماد اعلام می‌کند. سه سیاست مدیریت شده به آن متصل می‌شوند: AmazonEKSWorkerNodePolicy، AmazonEKS_CNI_Policy (مدیریت شبکه پاد توسط CNI) و AmazonEC2ContainerRegistryReadOnly (دانلود تصاویر از ECR).

برای تکمیل راه‌اندازی، یک نقش اختصاصی و Instance Profile برای نمونه EC2 مدیریتی ایجاد می‌کنیم. این نمونه، نقطه کنترلی برای اجرای دستورات `kubectl` و مدیریت خوشه خواهد بود. نقش آن شامل مجوزهای مدیریتی جامع برای EKS، EC2 و RDS است. مجوز `iam:PassRole` نیز حیاتی است، زیرا به این نمونه اجازه می‌دهد تا نقش‌های خوشه و گروه گره را هنگام ایجاد منابع به EKS منتقل کند.

طراحی و راه‌اندازی شبکه VPC با دسترس‌پذیری بالا

پس از پیکربندی نقش‌های IAM، زیرساخت شبکه را برای خوشه EKS خود ایجاد می‌کنیم. این شامل یک VPC آماده تولید با زیرشبکه‌های عمومی و خصوصی در چندین منطقه در دسترس (AZ) است که امنیت و دسترس‌پذیری بالا را تضمین می‌کند. VPC با بلوک CIDR 10.0.0.0/16 فضای IP خصوصی کافی را فراهم می‌آورد. یک Internet Gateway نیز به VPC متصل می‌شود تا ارتباط منابع عمومی با اینترنت را تسهیل کند.

چهار زیرشبکه – دو عمومی و دو خصوصی – در دو منطقه در دسترس مختلف ایجاد می‌کنیم. این رویکرد چند AZ برای دسترس‌پذیری بالا و بهترین شیوه‌های AWS حیاتی است. هر زیرشبکه از بلوک CIDR /24 استفاده می‌کند. زیرشبکه‌های عمومی (مانند 10.0.1.0/24) میزبان NAT Gateway و Load Balancerها خواهند بود و تخصیص خودکار IP عمومی برای آنها فعال می‌شود. زیرشبکه‌های خصوصی (مانند 10.0.3.0/24) گره‌های کاری EKS و پایگاه داده RDS را میزبانی می‌کنند؛ این منابع IP عمومی دریافت نمی‌کنند و مستقیماً از اینترنت قابل دسترسی نیستند که لایه امنیتی اضافی فراهم می‌کند.

برای کشف و استفاده صحیح EKS از زیرشبکه‌ها، تگ‌های خاصی به آنها اضافه می‌کنیم که نوع Load Balancer مربوطه را مشخص می‌کنند:

• تگ `kubernetes.io/cluster/pod-security-cluster-demo=shared` زیرشبکه‌هایی را که به خوشه ما تعلق دارند، شناسایی می‌کند.


• تگ `kubernetes.io/role/elb=1` در زیرشبکه‌های عمومی به Kubernetes می‌گوید که از این زیرشبکه‌ها برای ایجاد Load Balancerهای رو به اینترنت استفاده کند.


• تگ `kubernetes.io/role/internal-elb=1` در زیرشبکه‌های خصوصی نشان می‌دهد که Load Balancerهای داخلی باید در کجا ایجاد شوند.

پیکربندی جداول مسیریابی و دسترسی ایمن به اینترنت

در این گام، زیرساخت مسیریابی را برای کنترل جریان ترافیک زیرشبکه‌ها تنظیم می‌کنیم. این شامل ایجاد جداول مسیریابی برای زیرشبکه‌های عمومی و خصوصی و راه‌اندازی NAT Gateway برای دسترسی منابع خصوصی به اینترنت است، که دسترسی ایمن را تضمین می‌کند.

ابتدا، یک جدول مسیریابی برای زیرشبکه‌های عمومی با مسیر پیش‌فرض (0.0.0.0/0) ایجاد می‌کنیم که به Internet Gateway اشاره دارد. این ترافیک خروجی منابع عمومی را مستقیماً به اینترنت هدایت می‌کند. سپس، یک NAT Gateway با Elastic IP ایجاد می‌کنیم. NAT Gateway در یک زیرشبکه عمومی قرار گرفته و به عنوان واسطه‌ای برای ترافیک خروجی اینترنت از زیرشبکه‌های خصوصی عمل می‌کند.

برای زیرشبکه‌های خصوصی، یک جدول مسیریابی جداگانه با مسیر پیش‌فرض به NAT Gateway ایجاد می‌کنیم. این تنظیمات به منابع در زیرشبکه‌های خصوصی امکان آغاز ارتباطات خروجی به اینترنت را می‌دهد، اما از ارتباطات ورودی مستقیم از اینترنت جلوگیری می‌کند. این یک ویژگی امنیتی مهم است که به گره‌های کاری و پایگاه‌های داده اجازه دسترسی به اینترنت را در صورت نیاز می‌دهد، بدون اینکه مستقیماً از اینترنت قابل دسترس باشند.

ایجاد و پیکربندی کلاستر EKS و نودها

پس از آماده‌سازی زیرساخت‌های AWS از جمله نقش‌های IAM و پیکربندی VPC، گام بعدی ایجاد و تنظیم دقیق کلاستر EKS است. در این مرحله، کلاستر را به گونه‌ای پیکربندی می‌کنیم که از قابلیت «گروه‌های امنیتی برای پادها» (Security Groups for Pods) پشتیبانی کند و نودهای کاری مدیریت‌شده را با انواع اینستنس مناسب راه‌اندازی کنیم. این تنظیمات اولیه برای اطمینان از عملکرد صحیح مکانیزم‌های امنیتی در سطح پاد حیاتی است.

راه‌اندازی کلاستر Amazon EKS

اولین قدم، ایجاد خود کلاستر EKS با گزینه‌های پیکربندی است که به‌طور خاص برای پشتیبانی از ویژگی گروه‌های امنیتی برای پادها انتخاب شده‌اند. ما از نسخه 1.33 کوبرنتیس استفاده می‌کنیم که آخرین نسخه پایدار و حامی این قابلیت است. پارامتر `role-arn`، EKSClusterRole را مشخص می‌کند که قبلاً ایجاد کرده‌ایم و به کلاستر امکان مدیریت منابع AWS را می‌دهد.

تنظیم `access-config` به عنوان `API_AND_CONFIG_MAP` بسیار مهم است؛ با این کار، هم احراز هویت مدرن مبتنی بر API و هم روش سنتی `aws-auth ConfigMap` فعال می‌شوند که انعطاف‌پذیری در مدیریت دسترسی به کلاستر را فراهم می‌آورد. همچنین، هر چهار ساب‌نت (عمومی و خصوصی) را در `resources-vpc-config` کلاستر قرار می‌دهیم. این کار برای ارتباط کنترل پلن EKS با نودهای کاری در سراسر مناطق در دسترس (Availability Zones) ضروری است و تضمین می‌کند که کلاستر می‌تواند منابع را در هر کجا که لازم باشد با حفظ مرزهای امنیتی مناسب قرار دهد. فرآیند ایجاد کلاستر معمولاً ۱۰ تا ۱۵ دقیقه طول می‌کشد، در این مدت AWS اجزای کنترل پلن کوبرنتیس را برای دسترسی‌پذیری بالا فراهم می‌کند.

پیکربندی گروه نودهای کاری مدیریت‌شده

پس از ایجاد کلاستر، نیاز داریم نودهای کاری (worker nodes) را اضافه کنیم که وظیفه اجرای پادها را بر عهده خواهند داشت. ما یک گروه نود مدیریت‌شده (managed node group) با انواع اینستنس‌هایی ایجاد خواهیم کرد که به‌طور خاص برای پشتیبانی از چندین رابط شبکه الاستیک (ENI) انتخاب شده‌اند. نودهای کاری را فقط در ساب‌نت‌های خصوصی راه‌اندازی می‌کنیم که مطابق با بهترین شیوه‌های امنیتی است و منابع محاسباتی را از دسترسی مستقیم به اینترنت دور نگه می‌دارد. نودها همچنان می‌توانند از طریق NAT Gateway که قبلاً راه‌اندازی کردیم، تصاویر داکر و به‌روزرسانی‌ها را دانلود کنند.

انتخاب نوع اینستنس برای «گروه‌های امنیتی برای پادها» اهمیت زیادی دارد. ما از اینستنس‌های `m5.large` استفاده می‌کنیم که می‌توانند تا ۳ ENI را پشتیبانی کنند. یک ENI به عنوان رابط شبکه اصلی برای خود نود استفاده می‌شود و ۲ ENI باقی‌مانده برای شبکه‌سازی شاخه‌ای (branch networking) در دسترس هستند. هر ENI شاخه‌ای می‌تواند چندین پاد را با سیاست‌های گروه امنیتی پشتیبانی کند و چگالی پاد خوبی را در عین حفظ قابلیت اختصاص گروه‌های امنیتی سفارشی فراهم می‌آورد. پیکربندی مقیاس‌بندی ما با ۲ نود آغاز می‌شود (`desiredSize=2`)، می‌تواند تا ۱ نود کاهش یابد (`minSize=1`) و تا ۳ نود افزایش یابد (`maxSize=3`) که ظرفیت کافی برای این دمو را با هزینه‌ای معقول فراهم می‌کند. ما از نوع ظرفیت `ON_DEMAND` استفاده می‌کنیم که به معنای اینستنس‌های EC2 استاندارد با صورتحساب ساعتی است و دسترسی ثابت و بدون وقفه را در طول آزمایش تضمین می‌کند.

مدیریت محدودیت‌های ENI و دسترسی به کلاستر

درک محدودیت‌های ENI در انواع مختلف اینستنس می‌تواند در برنامه‌ریزی برای گروه‌های امنیتی برای پادها کمک‌کننده باشد. نوع اینستنس `m5.large` که انتخاب کردیم، حداکثر ۳ رابط شبکه را فراهم می‌کند: یک ENI همیشه به عنوان رابط شبکه اصلی برای خود نود عمل می‌کند و تمام شبکه‌سازی استاندارد نود را انجام می‌دهد. ۲ ENI باقی‌مانده می‌توانند به عنوان رابط‌های Trunk برای شبکه‌سازی شاخه‌ای استفاده شوند که قابلیت «گروه‌های امنیتی برای پادها» را امکان‌پذیر می‌سازد. در محیط تولید، شما باید نیازهای ENI خود را بر اساس تعداد پادهایی که به گروه‌های امنیتی سفارشی نیاز دارند، به دقت محاسبه کرده و انواع اینستنس را بر اساس آن انتخاب کنید.

برای پیکربندی دسترسی به کلاستر به گونه‌ای که اینستنس مدیریتی ما بتواند دستورات `kubectl` را اجرا کند، از «ورودی‌های دسترسی EKS» (EKS access entries) استفاده می‌کنیم. این رویکرد، جایگزینی مدرن و قابل نگهداری‌تر برای روش قدیمی `aws-auth ConfigMap` است. EKSClusterRole که قبلاً ایجاد کردیم، یک نقش خدماتی است که خود EKS برای مدیریت زیرساخت‌های AWS مانند VPCها، گروه‌های امنیتی و لودبالانسرها از آن استفاده می‌کند. این متفاوت از EKS-Management-Role است که یک نقش مدیریتی برای اپراتورهای انسانی (یا اینستنس مدیریتی EC2 ما) است تا با منابع کوبرنتیس تعامل داشته باشند. با ایجاد یک ورودی دسترسی برای نقش مدیریتی و اتصال آن به `AmazonEKSClusterAdminPolicy`، دسترسی کامل مدیریتی به کلاستر را اعطا می‌کنیم. این رویکرد مدرن، قابلیت بازرسی بهتر و مدیریت آسان‌تری را نسبت به ویرایش دستی `aws-auth ConfigMap` فراهم می‌کند.

این پیکربندی اساسی، تضمین می‌کند که کلاستر EKS شما برای پیاده‌سازی کنترل‌های امنیتی دقیق در سطح پاد آماده است و یک پایه قوی برای مدیریت و استقرار برنامه‌های شما فراهم می‌آورد.

تنظیم گروه‌های امنیتی و پایگاه داده RDS

در این مرحله حیاتی، به پیکربندی دقیق گروه‌های امنیتی (Security Groups) و راه‌اندازی پایگاه داده Amazon RDS PostgreSQL می‌پردازیم. این گام‌ها قلب پیاده‌سازی Security Groups for Pods در EKS هستند و کنترل بی‌نظیری بر دسترسی شبکه در سطح پادها و محافظت از منابع حساس مانند پایگاه داده شما فراهم می‌آورند.

اتصال به سرویس‌گیرنده مدیریتی و آماده‌سازی اولیه

پیش از ایجاد گروه‌های امنیتی، نیاز است تا به سرویس‌گیرنده مدیریت (Management Instance) خود متصل شده و اطلاعات شبکه مورد نیاز را از خوشه EKS خود جمع‌آوری کنیم. ابتدا، اطمینان حاصل می‌کنیم که تمامی ابزارهای مورد نیاز در زمان بوت اولیه اینسِتَنس به درستی نصب شده‌اند. سپس، فایل kubeconfig را به‌روزرسانی می‌کنیم تا kubectl بتواند با نقطه پایانی (endpoint) خوشه EKS ما ارتباط برقرار کند. این کار شامل بازیابی نقطه پایانی و داده‌های گواهی‌نامه (certificate authority) خوشه و ذخیره آن‌ها در مسیر ~/.kube/config است. با اجرای دستور kubectl get nodes وضعیت آماده (Ready) نودهای کاری را تأیید می‌کنیم و با kubectl cluster-info نقطه پایانی سرور API را مشاهده می‌کنیم که اتصال صحیح به خوشه را نشان می‌دهد. در نهایت، شناسه VPC (Virtual Private Cloud) که خوشه ما در آن اجرا می‌شود را استخراج می‌کنیم، زیرا گروه‌های امنیتی باید با یک VPC خاص مرتبط شوند.

ایجاد گروه‌های امنیتی برای پادها و پایگاه داده

اکنون که اطلاعات اولیه را در اختیار داریم، می‌توانیم گروه‌های امنیتی مورد نیاز را ایجاد کنیم. قدرت اصلی Security Groups for Pods در توانایی تعریف گروه‌های امنیتی اختصاصی برای پادهای مشخص نهفته است.

• گروه امنیتی برای پادها (POD_SG): یک گروه امنیتی جدید در VPC خوشه ایجاد می‌کنیم که پادهای مشخصی که نیاز به دسترسی به پایگاه داده دارند از آن استفاده خواهند کرد. در ابتدا، این گروه امنیتی بدون هیچ قانون ورودی یا خروجی است و منتظر تعریف قوانین می‌ماند. شناسه این گروه امنیتی را برای مراجعات بعدی (مانند تنظیم قوانین ورودی و تعریف SecurityGroupPolicy) ذخیره می‌کنیم.




• گروه امنیتی برای پایگاه داده RDS (RDS_SG): سپس، یک گروه امنیتی اختصاصی برای پایگاه داده RDS PostgreSQL ایجاد می‌کنیم. این گروه نیز در ابتدا بدون قانون است و به پایگاه داده RDS ما متصل خواهد شد. مزیت این رویکرد این است که دسترسی به پایگاه داده را می‌توان با تعریف اینکه کدام گروه‌های امنیتی مجاز به ارتباط با RDS_SG هستند، کنترل کرد، بدون نیاز به دانستن آدرس‌های IP خاص.

پیکربندی قوانین گروه‌های امنیتی برای ارتباط امن

مهم‌ترین بخش، پیکربندی قوانین ورودی (ingress) و خروجی (egress) برای گروه‌های امنیتی است تا ارتباطات لازم بین اجزا را فراهم کرده و در عین حال مرزهای امنیتی را حفظ کنیم:

• تفکیک DNS: ابتدا، گروه امنیتی ایجاد شده توسط EKS برای نودهای کاری (node group security group) را شناسایی می‌کنیم. دو قانون برای اجازه حل و فصل نام‌های دامنه (DNS resolution) اضافه می‌کنیم: اجازه ترافیک TCP و UDP بر روی پورت 53 از POD_SG به گروه امنیتی نودها. این اطمینان می‌دهد که پادهایی با گروه‌های امنیتی سفارشی می‌توانند نام‌های دامنه را حل کنند.




• دسترسی به پایگاه داده: دسترسی گروه امنیتی اینسِتَنس مدیریتی را به پورت 5432 (PostgreSQL) بر روی RDS_SG فعال می‌کنیم. این به ما امکان می‌دهد از اینسِتَنس مدیریت به پایگاه داده متصل شویم. از همه مهم‌تر، به پادهایی با گروه امنیتی POD_SG اجازه می‌دهیم تا به پورت 5432 بر روی RDS_SG متصل شوند. این قانون به پادهای "سبز" (که POD_SG به آن‌ها اختصاص داده خواهد شد) اجازه اتصال به پایگاه داده را می‌دهد. لازم به ذکر است که به گروه امنیتی نودها اجازه دسترسی به پایگاه داده داده نمی‌شود، به این معنی که پادهای بدون POD_SG نمی‌توانند به پایگاه داده متصل شوند، حتی اگر بر روی همان نودها اجرا شوند.

راه‌اندازی پایگاه داده RDS PostgreSQL

برای نمایش کنترل دسترسی در سطح پاد، یک اینسِتَنس Amazon RDS PostgreSQL راه‌اندازی می‌کنیم که به عنوان منبع محافظت‌شده عمل می‌کند. این پایگاه داده با پیکربندی امنیتی دقیق و داده‌های آزمایشی پر خواهد شد.

• گروه ساب‌نت پایگاه داده (DB Subnet Group): یک گروه ساب‌نت پایگاه داده ایجاد می‌کنیم که شامل هر دو ساب‌نت خصوصی ما می‌شود. این تضمین می‌کند که پایگاه داده هرگز به طور مستقیم در معرض اینترنت قرار نمی‌گیرد و فقط از داخل VPC ما قابل دسترسی است. همچنین، قابلیت استقرار Multi-AZ را برای دسترسی‌پذیری بالا در آینده فراهم می‌کند.




• رمز عبور امن: یک رمز عبور رمزنگاری‌شده قوی و امن برای پایگاه داده تولید می‌کنیم و آن را در یک فایل ذخیره می‌کنیم.




• ایجاد اینسِتَنس RDS: اینسِتَنس PostgreSQL را با مشخصات db.t3.micro (کوچکترین کلاس اینسِتَنس برای صرفه‌جویی در هزینه)، موتور PostgreSQL، و با اتصال RDS_SG راه‌اندازی می‌کنیم. پرچم --no-publicly-accessible اطمینان می‌دهد که پایگاه داده آدرس IP عمومی دریافت نمی‌کند و از اینترنت قابل دسترس نیست. دوره نگهداری پشتیبان (backup-retention-period) را برای محیط آزمایشی روی 0 تنظیم می‌کنیم. پس از ایجاد، منتظر می‌مانیم تا پایگاه داده به طور کامل در دسترس قرار گیرد.




• ایجاد داده‌های آزمایشی: پس از در دسترس قرار گرفتن پایگاه داده، به آن متصل می‌شویم و یک جدول ساده به نام test_data با سه پیام آزمایشی ایجاد می‌کنیم. این داده‌ها برای تأیید اتصال از پادها در مراحل بعدی استفاده خواهند شد.

پیاده‌سازی و تست امنیت پادها در عمل

قابلیت Security Groups for Pods در سرویس Amazon EKS، یک تغییر پارادایم در مدل شبکه‌بندی کوبرنتیس ایجاد کرده است. پیش از این، گروه‌های امنیتی فقط در سطح اینستنس‌های EC2 (یعنی همان نودها) اختصاص داده می‌شدند که به این معنی بود که تمامی پادهای روی یک نود، قوانین امنیتی شبکه یکسانی داشتند. اما با این قابلیت جدید، می‌توان گروه‌های امنیتی خاص را به پادهای منفرد اختصاص داد و کنترل بسیار دقیق‌تری بر دسترسی شبکه فراهم آورد. در این بخش، به مراحل عملی پیاده‌سازی این ویژگی و نحوه تست و اعتبارسنجی آن می‌پردازیم تا اطمینان حاصل کنیم که پادها دسترسی‌های شبکه‌ای مورد نیاز خود را دارند و از دسترسی‌های غیرمجاز محافظت می‌شوند.

فعال‌سازی قابلیت و پیکربندی AWS VPC CNI

اولین گام حیاتی برای استفاده از Security Groups for Pods، فعال‌سازی قابلیت زیرساختی آن در پلاگین AWS VPC CNI است. این پلاگین مسئولیت اصلی تخصیص آدرس‌های IP به پادها و پیکربندی اینترفیس‌های شبکه آن‌ها را بر عهده دارد. برای فعال‌سازی شاخه شبکه‌بندی (branch networking)، باید متغیر محیطی ENABLE_POD_ENI را در DaemonSet مربوط به aws-node (که پلاگین CNI را روی تمامی نودهای کاری اجرا می‌کند) روی true تنظیم کنیم. این تنظیم به پلاگین CNI دستور می‌دهد تا به جای تخصیص آدرس IP از ENI اولیه نود، با VPC Resource Controller همکاری کند و یک ENI اختصاصی (branch ENI) برای پادهایی که نیاز به گروه امنیتی سفارشی دارند، فراهم آورد.

پس از فعال‌سازی این متغیر محیطی، تمامی پادهای aws-node باید مجدداً راه‌اندازی شوند تا پیکربندی جدید اعمال گردد. این فرآیند معمولاً چند دقیقه به طول می‌انجامد. سپس، برای اطمینان از صحت پیکربندی، می‌توانیم ظرفیت pod-eni هر نود را بررسی کنیم که نشان می‌دهد هر نود قادر به پشتیبانی از چند پاد با ENI اختصاصی است. همچنین، بررسی وجود یک ENI "trunk" روی نودها تأیید می‌کند که شاخه شبکه‌بندی به درستی فعال شده است. لاگ‌های پلاگین CNI نیز منبع مهمی برای شناسایی هرگونه خطا یا مشکل در طول این فرآیند هستند.

تعریف سیاست‌های امنیتی پاد با SecurityGroupPolicy

با فعال‌سازی قابلیت‌های زیرساختی، گام بعدی تعریف سیاست‌های امنیتی در سطح کوبرنتیس است. این کار با استفاده از یک منبع سفارشی (Custom Resource) به نام SecurityGroupPolicy انجام می‌شود. SecurityGroupPolicy یک آبجکت کوبرنتیس است که به سیستم اعلام می‌کند کدام پادها باید کدام گروه‌های امنیتی AWS را دریافت کنند. شما از سِکوئنسورهای برچسب (label selectors) استاندارد کوبرنتیس برای شناسایی پادها استفاده می‌کنید و سپس یک یا چند ID گروه امنیتی AWS را که باید به آن پادها متصل شوند، مشخص می‌کنید.

زمانی که یک SecurityGroupPolicy ایجاد می‌شود، فورا تغییری در سیستم ایجاد نمی‌کند؛ بلکه یک قاعده تعریف می‌کند که برای پادهای آینده با برچسب‌های مطابق اعمال خواهد شد. به عنوان مثال، می‌توانید یک سیاست تعریف کنید که به هر پادی با برچسب app: green-pod، یک گروه امنیتی خاص (مثلاً POD_SG) اختصاص دهد. VPC Resource Controller که یک کامپوننت AWS است و در کنترل پلستر شما اجرا می‌شود، به طور مداوم پادهایی را که با تعاریف SecurityGroupPolicy شما مطابقت دارند، رصد می‌کند. هنگام ایجاد یک پاد مطابق، کنترلر با APIهای EC2 ارتباط برقرار کرده و ENI لازم را تأمین می‌کند، گروه‌های امنیتی مشخص شده را متصل می‌کند و اینترفیس شبکه را پیکربندی می‌نماید.

سناریوی عملی: پاد مجاز و پاد مسدود

برای اثبات عملکرد Security Groups for Pods، یک سناریوی عملی بهترین راه است. در این سناریو، دو پاد ایجاد می‌کنیم: یکی که باید بتواند به یک دیتابیس PostgreSQL دسترسی پیدا کند و دیگری که باید دسترسی‌اش مسدود شود، حتی اگر هر دو پاد روی یک نود فیزیکی اجرا شوند. ابتدا، اعتبارنامه‌های اتصال به دیتابیس را به صورت امن در یک Kubernetes Secret ذخیره می‌کنیم تا از افشای اطلاعات حساس در مشخصات پاد جلوگیری شود.

پاد "سبز" (green pod) با برچسب app: green-pod ایجاد می‌شود. این برچسب با SecurityGroupPolicy که قبلاً تعریف کرده‌ایم، مطابقت دارد. در نتیجه، VPC Resource Controller یک ENI اختصاصی برای این پاد تأمین کرده و گروه امنیتی POD_SG را به آن متصل می‌کند. از آنجایی که POD_SG دارای قاعده‌ای است که به پورت 5432 دیتابیس RDS (که یک گروه امنیتی RDS_SG اختصاصی دارد) اجازه دسترسی می‌دهد، پاد سبز قادر به اتصال به دیتابیس و اجرای کوئری خواهد بود.

در مقابل، پاد "قرمز" (red pod) با برچسب app: red-pod ایجاد می‌شود. از آنجایی که برچسب این پاد با SecurityGroupPolicy مطابقت ندارد، ENI اختصاصی دریافت نمی‌کند. در عوض، این پاد از اینترفیس شبکه اصلی نود استفاده می‌کند و گروه امنیتی نود را به ارث می‌برد. از آنجایی که گروه امنیتی نود قاعده‌ای برای دسترسی به دیتابیس RDS ندارد، تلاش‌های پاد قرمز برای اتصال به دیتابیس در سطح شبکه مسدود خواهد شد. این سناریو به وضوح نشان می‌دهد که چگونه می‌توان با استفاده از Security Groups for Pods، امنیت شبکه را به صورت دانه‌ای و دقیق در سطح پادها اعمال کرد و حتی پادهای روی یک نود را با پروفایل‌های امنیتی کاملاً متفاوت مدیریت نمود.

بررسی و عیب‌یابی مشکلات احتمالی

پس از پیاده‌سازی، بسیار مهم است که صحت عملکرد را تأیید کنید. برای پاد سبز، می‌توانید با استفاده از kubectl describe pod [green-pod-name] بررسی کنید که آیا annotationهایی مانند vpc.amazonaws.com/pod-eni حاوی ID یک ENI اختصاصی هستند یا خیر. همچنین، با دستورات AWS CLI می‌توانید ENIهای ایجاد شده را جستجو کرده و مطمئن شوید که گروه امنیتی صحیح (POD_SG) به آن‌ها متصل شده است. برای پاد قرمز، عدم وجود این annotationها و عدم دسترسی به دیتابیس، عملکرد صحیح را تأیید می‌کند.

در صورت بروز مشکل، یک رویکرد سیستماتیک برای عیب‌یابی ضروری است. این شامل بررسی موارد زیر می‌شود:

• تأیید وجود قوانین گروه امنیتی صحیح بین POD_SG و RDS_SG.


• اطمینان از تخصیص ENI به پادهای مجاز.


• بررسی لاگ‌های پلاگین AWS VPC CNI و VPC Resource Controller برای هرگونه خطا.


• اعتبارسنجی پیکربندی SecurityGroupPolicy و مطابقت دقیق برچسب‌های پاد.


• بررسی اینکه گروه امنیتی نود دسترسی ناخواسته‌ای به دیتابیس ندارد.

این بررسی‌ها به شما کمک می‌کنند تا ریشه مشکلات را شناسایی و حل کنید و اطمینان حاصل کنید که مکانیزم امنیت شبکه شما به درستی عمل می‌کند.

پاکسازی کامل منابع ایجاد شده در AWS

پس از اتمام کار با این راهنما و آزمایش قابلیت‌های آن، پاکسازی تمامی منابعی که در AWS ایجاد کرده‌اید، برای جلوگیری از هزینه‌های اضافی بسیار مهم است. فرآیند پاکسازی باید با دقت و به ترتیب صحیح انجام شود تا از بروز مشکلات وابستگی بین منابع جلوگیری شود. این بخش به شما کمک می‌کند تا تمام اجزای کلاستر EKS، پایگاه داده، و شبکه خود را به طور کامل حذف کنید.

حذف منابع Kubernetes

اولین گام در فرآیند پاکسازی، حذف تمامی منابع Kubernetes است که در طول دمو ایجاد کرده‌ایم. با حذف Deployment‌های تک به تک آغاز می‌کنیم تا اطمینان حاصل شود که Podها به صورت ایمن خاتمه می‌یابند. سپس SecurityGroupPolicy را حذف می‌کنیم که باعث توقف کنترلر منابع VPC از ایجاد ENIهای جدید می‌شود. حذف Namespace ایجاد شده، هرگونه منبع باقی‌مانده را که ممکن است در طول آزمایش ایجاد کرده باشیم، از بین می‌برد. غیرفعال کردن قابلیت ENABLE_POD_ENI نیز افزونه VPC CNI را به حالت پیش‌فرض خود بازمی‌گرداند. این عمل بلافاصله ENIهای Trunk موجود را حذف نمی‌کند، اما از ایجاد موارد جدید جلوگیری می‌کند.

حذف پایگاه داده RDS

در گام بعدی، نمونه پایگاه داده RDS و منابع مرتبط با آن را حذف خواهیم کرد. استفاده از فلگ `--skip-final-snapshot` بدین معنی است که قبل از حذف پایگاه داده، هیچ اسنپ‌شاتی ایجاد نخواهیم کرد. در یک محیط عملیاتی، معمولاً یک اسنپ‌شات نهایی مورد نیاز است، اما برای این دمو که داده‌ها ارزشی ندارند، رد شدن از این مرحله به سرعت بخشیدن به فرآیند حذف کمک می‌کند. دستور `wait` تا زمانی که RDS تأیید کند که نمونه به طور کامل حذف شده است، منتظر می‌ماند که معمولاً چند دقیقه طول می‌کشد.

حذف کلاستر EKS و Node Groupها

اکنون کلاستر EKS و Node Groupهای آن را حذف خواهیم کرد. مهم است که Node Group را قبل از حذف کلاستر پاک کنید. اگر ابتدا سعی کنید کلاستر را حذف کنید، به دلیل وابستگی به Node Groupها، عملیات با شکست مواجه خواهد شد. فرآیند حذف Node Group تمامی نمونه‌های EC2 را خاتمه می‌دهد و منابع مرتبط با آن‌ها را پاکسازی می‌کند. سپس حذف کلاستر، اجزای Control Plane را از بین می‌برد.

حذف نمونه مدیریتی (Management Instance)

برای پاکسازی کامل، باید نمونه EC2 مدیریتی و منابع مرتبط با آن را نیز حذف کنیم. خاتمه دادن به نمونه EC2 بسیار ساده است؛ AWS به طور خودکار پاکسازی حجم‌های متصل (Attached Volumes) و رابط‌های شبکه را انجام می‌دهد. اما مهم است که آدرس IP الاستیک (Elastic IP) را به صورت صریح آزاد کنیم. IPهای الاستیک در صورتی که تخصیص یافته باشند اما به یک نمونه در حال اجرا متصل نباشند، هزینه دارند. بنابراین، آزاد کردن آن‌ها برای جلوگیری از هزینه‌های غیرضروری حیاتی است.

حذف کامپوننت‌های VPC

حذف کامپوننت‌های VPC پیچیده‌ترین بخش پاکسازی است، زیرا منابع VPC وابستگی‌های داخلی زیادی دارند که باید به ترتیب صحیح برطرف شوند. این فرآیند پاکسازی، تمامی مسائل وابستگی رایج را که ممکن است هنگام حذف یک VPC با آن‌ها روبرو شوید، پوشش می‌دهد. ابتدا، منابع باقی‌مانده متصل به VPC را بررسی می‌کنیم. سپس هر ENI جدا شده را که ممکن است EKS یا افزونه CNI ایجاد کرده باشند و دیگر به نمونه‌ها متصل نیستند، حذف می‌کنیم. Load Balancerها باید قبل از حذف زیرشبکه‌ها حذف شوند. Gateway NAT و Internet Gateway نیز باید به ترتیب صحیح حذف شوند. زیرشبکه‌ها تنها زمانی قابل حذف هستند که تمامی منابع استفاده‌کننده از آن‌ها حذف شده باشند. Route Tableها نیز باید از زیرشبکه‌ها جدا شوند. گروه‌های امنیتی به دلیل وابستگی‌های متقابل، ممکن است نیاز به چندین تلاش برای حذف داشته باشند. در نهایت، پس از پاکسازی تمامی منابع متصل، می‌توانیم خود VPC را حذف کنیم.

حذف نقش‌ها و سیاست‌های IAM

آخرین مرحله، پاکسازی نقش‌ها (Roles) و سیاست‌های (Policies) IAM است که در ابتدای راهنما ایجاد کردیم. پاکسازی IAM از یک ترتیب خاص پیروی می‌کند: ابتدا تمامی سیاست‌ها از نقش‌ها جدا می‌شوند، سپس هر سیاست سفارشی که ایجاد کرده‌ایم حذف می‌شود، نقش‌ها از Instance Profileها برداشته می‌شوند، Instance Profileها حذف می‌شوند و در نهایت خود نقش‌ها حذف می‌گردند. IAM به این ترتیب نیاز دارد، زیرا شما نمی‌توانید نقشی را که هنوز سیاست‌هایی به آن متصل است، حذف کنید و نمی‌توانید یک Instance Profile را که هنوز حاوی نقشی است، حذف کنید. با اتمام این پاکسازی جامع، تمامی منابعی که در طول این راهنما ایجاد شده‌اند حذف می‌شوند و دیگر هزینه‌ای متحمل نخواهید شد.

جمع‌بندی و توصیه‌های نهایی

این راهنمای جامع نشان داد که چگونه می‌توان قابلیت Security Groups for Pods را در سرویس Amazon EKS پیاده‌سازی کرد و به کنترل‌های امنیتی شبکه بسیار دقیق در سطح پادها دست یافت. پیاده‌سازی این ویژگی امکان تعریف پروفایل‌های امنیتی متفاوت برای هر پاد، حتی در یک نود مشترک را فراهم می‌کند و امنیت برنامه‌های میکروسرویس را به طور چشمگیری افزایش می‌دهد. با استفاده از ENIهای اختصاصی و سیاست‌های گروه امنیتی، می‌توانید دسترسی شبکه هر پاد را بر اساس نیازهای خاص آن محدود کنید، که برای محیط‌های تولیدی با الزامات امنیتی بالا حیاتی است. توصیه می‌شود در محیط‌های تولیدی، تنظیمات امنیتی را با دقت بالا بررسی کرده و از بهترین شیوه‌ها برای مدیریت IAM و VPC بهره ببرید.