توصي مادة منشورة على مدونة CNCF بالتعامل مع التحكم في الوصول إلى عناقيد Kubernetes كجزء من قائمة الإعداد الأساسية، إلى جانب الشبكات والتخزين، خصوصاً في البيئات ذاتية الاستضافة التي لا توفر عادةً تكامل IAM أو SSO جاهزاً كما هو الحال في خدمات Kubernetes المُدارة. الفكرة المحورية هي استخدام مزود هوية متوافق مع OIDC، مثل Keycloak، مع تسجيل العميل باعتباره عميلًا عاماً يستخدم PKCE، وليس عميلاً سرياً يحمل مفتاحاً مشتركاً.
في كثير من العناقيد المحلية، يعتمد الوصول على شهادة عميل ثابتة أو رمز طويل العمر يُصدر مرة واحدة. وتظل هذه البيانات صالحة حتى بعد مغادرة الموظف أو تغير دوره أو فقدانه الجهاز الذي يحتوي عليها. كما أن إلغاء الوصول يتطلب العثور على كل نسخة من ملف الشهادة أو الرمز، وهي عملية يصعب ضمان اكتمالها عندما تتعدد الأجهزة والمستخدمون. ومع زيادة عدد الأشخاص واختلاف مستويات الصلاحيات، يتحول توزيع الملفات وإدارتها إلى مهمة تشغيلية مستمرة.
ما الذي يتغير مع OIDC؟
بدلاً من ربط الصلاحية بملف شهادة، تصبح مرتبطة بحساب المستخدم وعضويته في مجموعات مزود الهوية. ويتكون التكامل من ثلاثة أطراف مترابطة: أداة kubectl مع إضافة kubelogin أو kubectl oidc-login، ومزود الهوية الذي يصادق على المستخدم ويصدر رمز الهوية، وخادم kube-apiserver الذي يتحقق من الرمز ويستخرج اسم المستخدم والمجموعات ثم يترك لـ Kubernetes RBAC تحديد العمليات المسموح بها.
لا يتصل kubectl بخادم API أولاً لبدء تسجيل الدخول. فإضافة exec-credential تطلق تسجيل الدخول عبر المتصفح لدى مزود الهوية، ثم تعيد رمز الهوية إلى kubectl ليُرسل كبيانات اعتماد لحامل الرمز. ويتحقق خادم API من الرمز باستخدام مفاتيح التوقيع العامة لمزود الهوية. ووفق المادة، لا يحتاج الخادم إلى اتصال مستمر بمزود الهوية، باستثناء جلب تلك المفاتيح عند الحاجة.
لماذا يجب أن يكون العميل عاماً؟
العميل السري يصدر مفتاحاً يُضاف إلى إعدادات إضافة kubelogin ويُوزع على كل جهاز يحتاج إلى الوصول. وترى المادة أن المفتاح الذي يجب توزيعه على جميع العملاء لم يعد سراً فعلياً، بل اعتماد ثابت مشترك يصعب تدويره. أما في تطبيقات سطر الأوامر والتطبيقات الأصلية، فيتمثل الاختيار الأنسب في عميل عام بلا سر، مع تفعيل PKCE، أو Proof Key for Code Exchange.
ينشئ العميل قيمة عشوائية محلياً، ويرسل تجزئة منها في طلب تسجيل الدخول الأولي، ثم يثبت امتلاكه للقيمة الأصلية عند استبدال رمز التفويض برمز وصول. لذلك لا يستطيع من يعترض رمز التفويض وحده إكمال العملية. وتقترح إعدادات Keycloak الواردة في المادة تعطيل مصادقة العميل، وتفعيل التدفق القياسي، وتعطيل منح الوصول المباشر، وفرض PKCE باستخدام S256، مع قصر عناوين إعادة التوجيه وأصول الويب على عناوين loopback مثل 127.0.0.1 وlocalhost.
خطوات الإعداد الأساسية
- إضافة مُعيّن عضوية المجموعات إلى نطاق العميل في Keycloak، بحيث يظهر ادعاء باسم groups داخل رمز الهوية.
- ضبط kube-apiserver باستخدام أعلام مثل oidc-issuer-url وoidc-client-id وoidc-username-claim وoidc-groups-claim.
- إضافة oidc-ca-file إذا كان مزود الهوية يستخدم شهادة غير موقعة من جهة موثوقة عامة، حتى يستطيع خادم API التحقق من اتصال TLS وجلب مفاتيح التوقيع.
- تعديل kubeconfig لاستخدام إدخال exec-credential عبر kubectl oidc-login بدلاً من تضمين الشهادات أو الرموز الثابتة، من دون إضافة حقل سر.
- ربط مجموعات مزود الهوية بأدوار Kubernetes RBAC، مثل ربط مجموعة platform-viewer بدور view.
الأثر العملي والحدود
بعد هذا الربط، تتم تغييرات الوصول داخل مزود الهوية: إضافة المستخدم إلى مجموعة أو إزالته منها، بدلاً من تعديل العنقود أو إعادة توزيع kubeconfig. ويحصل الرمز التالي الذي يصدره المستخدم على عضوية المجموعة الجديدة، فتطبق قاعدة RBAC المرتبطة بها. وتوضح المادة أن تسجيل الدخول الأول يفتح المتصفح، بينما تعيد kubelogin استخدام الرمز المخزن مؤقتاً إلى أن تنتهي صلاحيته، ثم تستخدم رمز التحديث من دون جولة متصفح جديدة. ويمكن التحقق من الهوية والمجموعات الفعلية عبر الأمر kubectl auth whoami.
لا يعني ذلك أن التكامل يخلو من متطلبات تشغيلية. يجب ضبط ادعاء المجموعات بدقة، والتحقق من شهادة مزود الهوية، وحصر عناوين إعادة التوجيه، والتأكد من أن أدوار RBAC تعكس الصلاحيات المطلوبة. كما أن المادة لا تقدم قياسات مستقلة لزمن الإعداد أو كلفة التشغيل، بل تقدر أن التجهيز قد يتم خلال فترة عمل واحدة، لا عبر ترحيل كامل للمنصة.
أهم فائدة أمنية وإدارية هي أن سجلات Kubernetes تصبح مرتبطة بهوية المستخدم الفعلية. فالسجلات التي تعتمد حساباً عاماً مثل cluster-admin لا تميز بين منفذي الطلبات، بينما يحمل كل طلب صادر عبر OIDC اسم المستخدم والمجموعات المرتبطة به. هذه قراءة تحريرية مستندة إلى تفاصيل المادة: التحسن ليس في طريقة تسجيل الدخول فقط، بل في قابلية إسناد الأفعال إلى أصحابها، مع جعل منح الصلاحيات وسحبها عملية هوية مركزية بدلاً من البحث عن ملفات اعتماد موزعة.
كيف أعددنا هذا الخبر؟
اعتمد الخبر على المصدر الأصلي الموضح أعلاه. قد نستخدم أدوات آلية للمساعدة في الاستخراج والتصنيف والصياغة،
لكن النشر يخضع لقواعد تمنع المحتوى المكرر والقصير أو الروتيني منخفض القيمة.
اقرأ سياستنا التحريرية.