الوصول إلى مجموعات Kubernetes

يُمنح الوصول إلى المجموعة لكل شخص ولكل مجموعة على حدة. لكل شخص دور في المجموعة أو لا دور له، وكل ما يفعله داخلها يحمل ذلك الدور: ملف kubeconfig الخاص به، ولوحة التحكم في وحدة التحكم، وتكبير وحدة تخزين. لا يوجد ملف kubeconfig مدير مشترك يُتداول بين الناس.

الأدوار

مساحات النظام هي kube-system وkube-public وkube-node-lease والمساحتان اللتان تعمل فيهما البوابة المُدارة. ولا دور للمحرّرين فيها، فلا يستطيعون قراءة أسرارها ولا تغيير ما يعمل فيها. أما ما يستطيعون تشغيله في مساحات الأسماء الأخرى فيحدّده أمان الـ Pods.

داخل المجموعة، يُمثَّل كل دور بمجموعة Kubernetes: sahabti:cluster-admins للمديرين، وsahabti:developers للمحرّرين، وsahabti:viewers للمشاهدين. تحمل بيانات اعتمادك مجموعة دورك وتسمّيك بعنوان بريدك الإلكتروني، كما يشرح قسم كيف تعرفك المجموعة. ويستطيع مدير المجموعة ربط هذه المجموعات بأدواره الخاصة، كأن يسمح للمشاهدين بقراءة مورد مخصّص.

أمان الـ Pods

تتبع كل مساحات الأسماء عدا مساحات النظام معايير أمان الـ Pods في Kubernetes:

وبهذا لا يستطيع ما ينشره المحرّر الاستيلاء على عقدة عاملة ولا الوصول إلى مكوّنات المجموعة نفسها عليها.

ويستطيع مدير المجموعة تخفيف المعيار أو تشديده في مساحة أسماء واحدة بالتسميات القياسية، التي تتقدّم على الإعدادات الافتراضية في تلك المساحة وحدها:

# السماح بـ Pods ذات امتيازات، مثل مُصدِّر مقاييس العقد، دون تحذيرات بشأنها
kubectl label namespace monitoring pod-security.kubernetes.io/enforce=privileged pod-security.kubernetes.io/warn=privileged
# Pods محصّنة فقط
kubectl label namespace payments pod-security.kubernetes.io/enforce=restricted

لا يستطيع المحرّرون تغيير تسميات مساحات الأسماء، فلا يستطيعون رفع المعيار الذي يعملون في ظلّه. والمساحة المخفّفة تسمح لكل من يستطيع إنشاء Pods فيها، والمحرّرون منهم، بتشغيل Pods ذات امتيازات هناك: خصّص مثل هذه المساحات لأحمال العمل التي تحتاجها.

فعّله لمجموعة أقدم

المجموعة التي أُنشئت قبل وجود هذه الإعدادات الافتراضية تعمل دونها إلى أن تفعّلها: فمساحة الأسماء التي بلا تسميات تقبل فيها Pods ذات امتيازات، ويستطيع المحرّرون تشغيلها على العقد العاملة. وتذكر الإعدادات في المجموعة ذلك تحت أمان الـ Pods؛ فعّله من هناك، أو أرسل podSecurity: true إلى PATCH /v1/kubernetes/clusters/{id}/settings، فتحصل المجموعة على الإعدادات الافتراضية أعلاه نفسها.

• تبقى الـ Pods التي تعمل الآن قيد التشغيل. ويُرفض الـ Pod الذي يخالف baseline في المرة التالية التي يُنشأ فيها، كأن يُطرح الـ Deployment الخاص به أو تُستبدل عقدته العاملة، فراجع أحمال العمل لديك أولًا وضع التسميات على مساحات الأسماء التي تحتاج إلى أكثر من ذلك قبل أن تفعّله.
• يُعاد تشغيل مستوى التحكم به عقدةً تلو الأخرى، وتعرض المجموعة حالة قيد التحديث حتى ينتهي ذلك. ودون الإتاحة العالية يتعذّر الوصول إلى الـ API الخاص بالمجموعة نحو دقيقة، وتبقى أحمال العمل قيد التشغيل.
• إن لم يعد خادم API به، تعود تلك العقدة إلى ما كانت عليه، ويظهر الإعداد متوقفًا من جديد، وتعرض المجموعة حالة متدهورة مع السبب. ولا تتغير أحمال العمل لديك.
• بعد تفعيله يبقى مفعّلًا. وللسماح لمساحة أسماء واحدة بتشغيل Pods ذات امتيازات، ضع عليها التسميات كما في المثال أعلاه.

من يحمل دورًا

• مالكو مساحة العمل مديرون لكل مجموعة في مساحة العمل، ولا يمكن تغيير وصولهم أو إلغاؤه.
• من ينشئ المجموعة يصبح مديرًا لها.
• أي شخص آخر يحمل الدور الذي مُنح له، ولا دور له قبل ذلك، أيًّا كان دوره في مساحة العمل. وتغيير دور شخص في مساحة العمل لا يغيّر أدواره في المجموعات؛ غيّرها أو ألغِها في كل مجموعة.

حين صار الوصول لكل مجموعة على حدة، احتفظت كل مجموعة موجودة بمن كان يصل إليها: صار مالكو مساحة العمل ومديروها مديرين لها، والمطوّرون محرّرين.

منح الوصول وتغييره وإلغاؤه

افتح المجموعة، وانتقل إلى الوصول، وستجد من لديه وصول: كل من لديه دور، ومن منحه إياه ومتى.

• منح الوصول يعطي عضوًا في مساحة العمل دورًا. ادعُ الشخص إلى مساحة العمل أولًا إن لم يكن عضوًا بعد.
• تغيّر قائمة كل شخص دوره أو تلغي وصوله.

يدير مالكو مساحة العمل ومديروها الوصول إلى كل مجموعة فيها، ويدير مديرو المجموعة الوصول إليها. لا يستطيع أحد منح دور أعلى من دوره، ويبقى للمجموعة دائمًا مدير واحد على الأقل. ويُسجَّل كل تغيير مع من أجراه.

من يستطيع الوصول إلى الواجهة

تحدّد بطاقة الوصول إلى الـ API في قسم الوصول من المجموعة من يستطيع الوصول إلى واجهة Kubernetes API الخاصة بالمجموعة عبر الشبكة. تبقى بيانات اعتمادك هي ما يقرّر ما يحقّ للطلب فعله، أما هذا الإعداد فيقرّر من أين يُسمح للطلب أن يأتي.

المجموعات التي أُنشئت قبل وجود هذا الإعداد عامة ومفتوحة للإنترنت، وتبقى كذلك حتى تغيّرها. وتنبّهك البطاقة إلى نقطة الوصول المفتوحة: إن كنت تعرف من أين تتصل، فاحصرها بتلك الشبكات.

يستطيع مالكو مساحة العمل ومديروها، ومديرو المجموعة، تغيير الإعداد، ويستطيع غيرهم الاطلاع عليه. يسري التغيير خلال ثوانٍ، وتُقطع الاتصالات المفتوحة من أي عنوان لا يشمله الإعداد الجديد.

الشبكات المصرّح بها

• أضف حتى 20 عنوان IPv4 أو شبكة بصيغة CIDR، واحدًا في كل سطر، مثل 203.0.113.7 أو 198.51.100.0/24. يُحفظ العنوان المفرد بصيغة /32، وتُحفظ الشبكة بعنوانها الأول، فيصبح 198.51.100.9/24 هو 198.51.100.0/24.
• لا يُقبل 0.0.0.0/0: لتسمح لكل العناوين، اختر فتحها للإنترنت بدلًا من ذلك.
• يضيف زر إضافة عنواني العنوان الذي تتصل منه. وإن أخبرتك البطاقة أن هذا العنوان IPv6، فأضف عنوان IPv4 الذي تستخدمه شبكتك بدلًا منه، فنقطة الوصول تعمل على IPv4 فقط.
• قبل الحفظ، تنبّهك البطاقة إن كانت القائمة لا تشمل العنوان الذي تستخدمه، كي لا تحجب نفسك عن الواجهة دون قصد.

الوصول الخاص من شبكة مساحة العمل

للمجموعة نقطتا وصول، وتعرض البطاقة كلتيهما:

• نقطة الوصول العامة: https://<address>:<port> على الإنترنت، ويمكن الوصول إليها بحسب الإعداد.
• نقطة الوصول الخاصة: https://<address>:6443 داخل شبكة مساحة عملك، ويمكن الوصول إليها من أي نسخة أو جهاز افتراضي أو Pod في تلك الشبكة، أيًّا كان الإعداد.

حين تكون المجموعة خاصة، تشير ملفات kubeconfig التي تُنزَّل بعد ذلك إلى نقطة الوصول الخاصة. نزّل ملف kubeconfig جديدًا واستخدمه من جهاز داخل شبكة مساحة العمل، كجهاز افتراضي مثلًا؛ أما الملف الذي نُزّل قبل ذلك فما زال يشير إلى نقطة الوصول العامة ويتوقف عن العمل. وبعد إعادتها إلى عامة، نزّل ملف kubeconfig جديدًا للاتصال من الخارج، فالملف الذي نُزّل والمجموعة خاصة لا يعمل إلا داخل شبكة مساحة العمل.

وصول المنصّة

يُسمح دائمًا باتصالات المنصّة نفسها بمجموعتك، مثل لوحة المجموعة في وحدة التحكم، أيًّا كان الإعداد. ولا تظهر هذه الاتصالات في قائمتك، وتبقى بحاجة إلى بيانات اعتماد مثل أي طلب آخر.

نوعان من ملف kubeconfig

كلاهما من بطاقة الاتصال في قسم الوصول من المجموعة، وكلاهما يحمل دورك أنت.

تنزيل kubeconfig يعطيك ملفًا يُبقي نفسه صالحًا. فبدل شهادة طويلة العمر، يحمل رمزًا لا يفعل إلا شيئًا واحدًا: طلب بيانات اعتماد جديدة صالحة لساعة واحدة لهذه المجموعة. يفعل kubectl ذلك بنفسه باستخدام sh وcurl، فيعمل على macOS وLinux وWSL. ويحفظ بيانات الاعتماد في ~/.kube/cache/sahabti/ بحيث لا يقرؤها غيرك، ويطلب غيرها قبل انتهائها بخمس دقائق، فلا تنتظر أوامرك المنصّة. يدوم الرمز سنة، ويظهر في صفحة مفاتيح API في مساحة عملك حيث يمكنك إلغاؤه.

kubeconfig لمدة 12 ساعة يعطيك ملفًا عاديًا بشهادة تنتهي بعد اثنتي عشرة ساعة. لا يحتاج إلا إلى kubectl، فهو الأنسب لنظام Windows دون WSL أو لجلسة سريعة على جهاز مستعار. نزّل ملفًا جديدًا حين ينتهي.

احفظ ملفات kubeconfig بعيدًا عن الآخرين: من يحمل أحدها يتصرّف بصفتك في تلك المجموعة.

كيف تعرفك المجموعة

تعرفك المجموعة بعنوان بريدك الإلكتروني بأحرف صغيرة، وتعرف دورك بمجموعته. ويعرض kubectl auth whoami الاثنين:

ATTRIBUTE   VALUE
Username    [email protected]
Groups      [sahabti:viewers system:authenticated]

ويسمّيك الرفض بالطريقة نفسها. فلدانة دور المشاهد، ولذلك يُرفض طلبها إنشاء Pod:

Error from server (Forbidden): pods is forbidden: User "[email protected]" cannot create resource "pods" in API group "" in the namespace "default"

ويسمّي ملف kubeconfig إدخالاته باسمك واسم المجموعة، لا باسم دورك أبدًا:

ولأن كل اسم يتضمّن المجموعة، يمكنك جمع ملفات kubeconfig لعدة مجموعات معًا، مثل export KUBECONFIG=smoke-1.kubeconfig:prod.kubeconfig، والتنقّل بينها باستخدام kubectl config use-context.

لا تأتي الأدوار إلا من المجموعات. وفي روابط الأدوار التي تنشئها بنفسك، سمِّ المجموعات لا عنوان بريد إلكتروني: فالربط الذي يسمّي عنوانًا يبقى مع ذلك العنوان حين يغيّره صاحبه.

حين تغيّر عنوان بريدك الإلكتروني، ترى المجموعة العنوان الجديد ابتداءً من بيانات الاعتماد التالية التي تُصدر لك: عند التحديث التالي للوحة التحكم، وخلال ساعة عبر ملف kubeconfig المتجدّد ذاتيًا، وعبر ملف kubeconfig لمدة 12 ساعة فقط بعد أن تنزّل ملفًا جديدًا. أما أسماء الإدخالات داخل ملف kubeconfig فتبقى كما نُزّلت؛ نزّل ملفًا جديدًا لتغييرها.

ويستمر ملف kubeconfig الذي نُزّل قبل هذه الأسماء في العمل كما هو. إدخالاته sahabti-<cluster> وsahabti-<cluster>-admin أيًّا كان دورك: ولم تعنِ -admin هذه دور المدير قط. وكانت المجموعات أيضًا تعرفك بمعرّف داخلي، sahabti:user: تتبعه أحرف وأرقام، بدل بريدك الإلكتروني. والدور المرتبط بمثل هذا الاسم لم يعد يسري: اربطه بمجموعة بدلًا من ذلك.

متى يسري التغيير، ومتى ينتهي الوصول

يُقرأ دورك وعنوان بريدك الإلكتروني من جديد في كل مرة تُصدر فيها بيانات الاعتماد:

• لوحة التحكم تتبع التغيير عند التحديث التالي.
• ملف kubeconfig المتجدّد ذاتيًا يحتفظ بكل بيانات اعتماد مدةً أقصاها 55 دقيقة، فيسري التغيير أو الإلغاء خلال ساعة. وبعد تغيّر دورك أنت، احذف ~/.kube/cache/sahabti/ لتستخدم الدور الجديد فورًا. أما ملف kubeconfig المتجدّد ذاتيًا الذي نُزّل قبل وجود هذا الحفظ فيطلب بيانات اعتماد لكل أمر؛ نزّل ملفًا جديدًا ليحتفظ بها بين الأوامر.
• ملف kubeconfig لمدة 12 ساعة يحتفظ بالدور الذي صدر به حتى ينتهي. لا يمكن إلغاؤه مبكرًا، ولهذا هو قصير.

وينتهي الوصول أيضًا:

• حين تغادر مساحة العمل: تزول كل أدوارك مع عضويتك، وتبدأ بلا دور إن انضممت من جديد.
• حين تلغي رمز ملف kubeconfig من صفحة مفاتيح API: يتوقّف عند تجديده التالي.
• حين تُحذف المجموعة: تتوقّف كل ملفات kubeconfig المتجدّدة ذاتيًا الخاصة بها فورًا.

للأتمتة

لخط نشر يرسل إلى المجموعة، أنشئ حساب خدمة (service account) في Kubernetes بدور يغطّي ما ينشره، وأعطِ خط النشر رمز ذلك الحساب، لا ملف kubeconfig يخصّ شخصًا.

ولإدارة المجموعات نفسها — إنشاؤها وتغيير عدد عُقدها وحذفها وسرد وحدات تخزينها ومعرفة من لديه وصول وتغييره — من سكربتات أو من وكيل ذكاء اصطناعي، استخدم واجهة API أو MCP: list_kubernetes_clusters وget_kubernetes_cluster وcreate_kubernetes_cluster وscale_kubernetes_cluster وdelete_kubernetes_cluster وlist_kubernetes_cluster_volumes وlist_kubernetes_volumes وdelete_kubernetes_volume وlist_kubernetes_access وset_kubernetes_access وrevoke_kubernetes_access. تغيير الوصول يتم بصفة شخص، فيعمل بتسجيل دخول شخص لا بمفتاح API. ولا يسلّم أيٌّ منهما ملف kubeconfig أبدًا.

ويُضبط من يستطيع الوصول إلى واجهة المجموعة عبر GET وPUT /v1/kubernetes/clusters/{id}/api-access، أو عبر get_kubernetes_api_access وset_kubernetes_api_access في MCP. أرسل أحد ما يلي:

{ "mode": "public", "openToInternet": true }
{ "mode": "public", "authorizedNetworks": ["203.0.113.0/24", "198.51.100.7"] }
{ "mode": "private" }

ويقبل create_kubernetes_cluster وPOST /v1/kubernetes/clusters الكائن نفسه في الحقل apiAccess؛ ومن دونه تكون المجموعة الجديدة مفتوحة للإنترنت. ويحتاج تغيير الإعداد إلى مالك مساحة العمل أو أحد مديريها أو أحد مديري المجموعة مسجَّلًا الدخول، فتستطيع مفاتيح API قراءته دون تغييره.

كيف تُحمى نقطة وصول الواجهة

لا تستجيب نقطة وصول واجهة المجموعة إلا للعناوين التي يسمح بها إعداد الوصول إلى الـ API. ومن تلك العناوين، تجيب عن فحوص السلامة لأي أحد، وعن كل طلب آخر لبيانات اعتماد صالحة فقط. الأسرار مشفّرة أثناء التخزين، ولا يشغّل مستوى التحكم أيًّا من أحمال عملك، وتتبع الـ Pods معايير أمان الـ Pods، ولكل مجموعة جهة إصدار شهادات خاصة بها.