Geekly articles weekly

Kubernetes RBAC المستخدمين والترخيص

تقريبا. العابرة. : استمرارًا للموضوع الذي تم طرحه مؤخرًا حول أمان Kubernetes بشكل عام و RBAC على وجه الخصوص ، فإننا ننشر ترجمة لهذه المادة من مستشار فرنسي من شركة Adaltas Big Data الدولية. يوضح المؤلف بالتفصيل كيفية إنشاء المستخدمين ومنحهم الحقوق والاستمرار في الخدمة.

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

(رسم توضيحي مأخوذ من مدونة CNCF - ترجمة تقريبية.)

تتناول هذه المقالة كيفية إنشاء مستخدمين يستخدمون شهادات عميل X.509 ، وكيفية إدارة التخويل باستخدام واجهات برمجة تطبيقات RBAC الأساسية في Kubernetes. سنتحدث أيضًا عن بعض مشاريع المصادر المفتوحة التي تعمل على تبسيط إدارة نظام المجموعة: rakkess ، و kubectl-who-can ، و rbac-lookup ، و RBAC Manager.

الشروط المسبقة والافتراضات


بادئ ذي بدء ، يجب وضع عدة افتراضات:


إذا لم يكن لديك نظام Kubernetes جاهز ، فأنا أوصي بالرجوع إلى مقالة زميل (Arthur BUSSER) يتحدث فيها عن تثبيت Kubernetes على CentOS 7 باستخدام Vagrant.

هناك 4 نقاط في مجموعتنا: سيد واحد و 3 عمال. سيتم استخدام المعالج أيضًا كعقدة حافة للتفاعل مع الكتلة.

واجهات برمجة التطبيقات RBAC


التحكم في الوصول المستند إلى الدور (RBAC) هو طريقة للتحكم في الوصول إلى أجهزة الكمبيوتر وموارد الشبكة ، استنادًا إلى أدوار المستخدمين الفرديين في الشركة. يمكن استخدام RBAC مع جميع موارد Kubernetes التي تدعم CRUD (إنشاء ، قراءة ، تحديث ، حذف). أمثلة على هذه الموارد:

  • مساحة الاسم.
  • Pod'y.
  • Deployment'y.
  • وحدات التخزين الثابتة (PersistentVolumes) ؛
  • ConfigMap'y.

وإليك أمثلة لعمليات محتملة معهم:

  • create
  • get (الاستقبال)؛
  • delete (حذف) ؛
  • list (عرض list ) ؛
  • update .

لإدارة RBAC في Kubernetes ، نحتاج إلى إعلان:

  • Role و ClusterRole . هذه ببساطة مجموعات قواعد تمثل مجموعة من الأذونات. لا يمكن استخدام Role إلا لتوفير الوصول إلى الموارد داخل مساحات الأسماء. يمكن أن يوفر ClusterRole نفس أذونات Role ، كما يتيح الوصول إلى الموارد المتاحة داخل المجموعة بأكملها ، وما يسمى بنقاط النهاية غير المتعلقة بالموارد (مثل /healthz - approx. Transl.) .
  • Subjects . الموضوع هو كيان يقوم بإجراء عمليات في كتلة. يمكن أن يكون المستخدمون أو الخدمات أو حتى المجموعات.
  • RoleBinding و ClusterRoleBinding . كما يوحي الاسم ، هذا هو ببساطة ملزمة للموضوع إلى دور أو ClusterRole.

Kubernetes لديه الأدوار الافتراضية التالية:

  • view : الوصول للقراءة فقط ، باستثناء الأسرار ؛
  • edit : أعلاه + القدرة على تحرير معظم الموارد ، يستبعد الأدوار وربط الأدوار ؛
  • admin : ما سبق + القدرة على إدارة الأدوار وتعيينات الأدوار على مستوى مساحة الاسم ؛
  • cluster-admin : جميع الامتيازات الممكنة.

بالطبع ، يمكنك إنشاء ClusterRoles و ClusterRoles الخاصة بك ، لكننا نوصيك باستخدام الأدوار الافتراضية قدر الإمكان ، بقدر ما يسمح الموقف. خلاف ذلك ، يمكنك الحصول على الخلط بسرعة في كل هذا.

مثال للاستخدام


سننشئ مساحات أسماء اثنين: my-project-dev و my-project-prod ، - بالإضافة إلى اثنين من المستخدمين: jean و sarah - مع أدوار مختلفة في مساحات الأسماء هذه:

  • بلدي مشروع ديف:
    • جان: تحرير
  • بلدي مشروع همز:
    • جان: رأي
    • سارة: تحرير

إنشاء ومصادقة المستخدمين باستخدام شهادات عميل X.509


عادة ، هناك نوعان من المستخدمين: حسابات الخدمة التي تديرها Kubernetes والمستخدمون العاديون. سوف نركز على هذا الأخير. إليك كيفية وصفها في الوثائق الرسمية:

من المفترض أن تتم إدارة المستخدمين العاديين بواسطة خدمة خارجية مستقلة. يمكن لعب الدور بواسطة مسؤول يوزع المفاتيح الخاصة ، أو مستودع مستخدم مثل Keystone أو Google Accounts ، أو حتى ملف به قائمة بأسماء المستخدمين وكلمات المرور. في هذا الصدد ، Kubernetes لا يوجد لديه كائنات تمثل المستخدمين العاديين. لا يمكن إضافة المستخدمين العاديين إلى الكتلة من خلال مكالمة API.

هناك عدة طرق لإدارة المستخدمين العاديين:

  • المصادقة الأساسية:
    • نقل التكوين إلى خادم API بالمحتويات التالية (أو ما شابه): كلمة المرور ، اسم المستخدم ، معرف المستخدم ، المجموعة ؛
  • شهادة عميل X.509:
    • إنشاء المفتاح السري للمستخدم وتوقيع الشهادة ؛
    • شهادة في مرجع مصدق (Kubernetes CA) للحصول على شهادة مستخدم ؛
  • رموز حامل (JSON Web Tokens، JWT):
    • OpenID الاتصال
    • طبقة المصادقة أعلى OAuth 2.0 ؛
    • السنانير ويب (webhooks).

في هذه المقالة ، سوف نستخدم شهادات X.509 و OpenSSL بسبب بساطتها. يتم إنشاء المستخدمين على عدة مراحل - سنستعرضهم جميعًا. يجب إجراء العمليات تحت حساب المستخدم مع امتيازات مسؤول الكتلة (نظام المجموعة). فيما يلي جميع الخطوات لإنشاء مستخدم (باستخدام jean كمثال):

  • قم بإنشاء مستخدم على المعالج ، ثم انتقل إلى دليله الرئيسي لإكمال الخطوات المتبقية:

     useradd jean && cd /home/jean
  • إنشاء مفتاح خاص:

     openssl genrsa -out jean.key 2048
  • قم بإنشاء طلب توقيع شهادة (CSR). CN هو اسم المستخدم ، O هي المجموعة. يمكنك تعيين أذونات حسب المجموعة. سيؤدي ذلك إلى تبسيط العمل ، على سبيل المثال ، إذا كان لديك العديد من المستخدمين بنفس الأذونات:

     #   openssl req -new -key jean.key \ -out jean.csr \ -subj "/CN=jean" #     $group openssl req -new -key jean.key \ -out jean.csr \ -subj "/CN=jean/O=$group" #       openssl req -new -key jean.key \ -out jean.csr \ -subj "/CN=jean/O=$group1/O=$group2/O=$group3"
  • تسجيل المسؤولية الاجتماعية للشركات في Kubernetes CA. يجب علينا استخدام شهادة المرجع المصدق والمفتاح ، والتي توجد عادة في /etc/kubernetes/pki . ستكون الشهادة صالحة لمدة 500 يوم:

     openssl x509 -req -in jean.csr \ -CA /etc/kubernetes/pki/ca.crt \ -CAkey /etc/kubernetes/pki/ca.key \ -CAcreateserial \ -out jean.crt -days 500
  • قم .certs دليل .certs . فيه ، سنقوم بتخزين مفاتيح المستخدم العامة والخاصة:

     mkdir .certs && mv jean.crt jean.key .certs
  • إنشاء مستخدم داخل Kubernetes:

     kubectl config set-credentials jean \ --client-certificate=/home/jean/.certs/jean.crt \ --client-key=/home/jean/.certs/jean.key
  • تعيين السياق للمستخدم:

     kubectl config set-context jean-context \ --cluster=kubernetes --user=jean
  • تحرير ملف تكوين المستخدم. أنه يحتوي على المعلومات اللازمة للمصادقة في كتلة. يمكنك استخدام ملف تكوين نظام المجموعة ، والذي يوجد عادةً في /etc/kubernetes : يجب أن تكون متغيرات certificate-authority-data server ومتغيرات server كما هي في الملف المذكور:

     apiVersion: v1 clusters: - cluster: certificate-authority-data: {  } server: {  } name: kubernetes contexts: - context: cluster: kubernetes user: jean name: jean-context current-context: jean-context kind: Config preferences: {} users: - name: jean user: client-certificate: /home/jean/.certs/jean.cert client-key: /home/jean/.certs/jean.key

    أنت الآن بحاجة إلى نسخ التكوين أعلاه إلى دليل .kube :

     mkdir .kube && vi .kube/config
  • يبقى لجعل المستخدم مالك جميع الملفات والدلائل التي تم إنشاؤها:

     chown -R jean: /home/jean/

jean إنشاء jean المستخدم بنجاح. سنفعل نفس الشيء من أجل sarah . هناك خطوات قليلة للغاية ، ويمكن أن يستغرق إنشاء عدد كبير من المستخدمين وقتًا طويلاً. لذلك ، كتبت نصوص Bash التي تعمل على أتمتة العملية: يمكن العثور عليها في المستودع على GitHub .

تقريبا. العابرة. : كما كتبنا في مقالتنا الأخيرة ، يمكن تبسيط هذا الإجراء بطريقة أكثر "محلية" إلى Kubernetes - من خلال ميزات جديدة في الأداة المساعدة kubeadm console . ومع ذلك ، تذكر أنه في وقت نشر هذه الترجمة ، كانت متوفرة في شكل ألفا. مثال على الأمر لإنشاء مستخدم هو مستخدم kubeadm alpha kubeconfig user .

لدينا الآن مستخدمون ، ويمكننا الانتقال إلى إنشاء مساحات أسماء اثنين:

 kubectl create namespace my-project-dev kubectl create namespace my-project-prod

نظرًا لأننا لم نحدد بعد ترخيص المستخدم ، فلا ينبغي أن يكون لهم حق الوصول إلى موارد نظام المجموعة:

 User: Jean kubectl get nodes Error from server (Forbidden): nodes is forbidden: User "jean" cannot list resource "nodes" in API group "" at the cluster scope kubectl get pods -n default Error from server (Forbidden): pods is forbidden: User "jean" cannot list resource "pods" in API group "" in the namespace "default" kubectl get pods -n my-project-prod Error from server (Forbidden): pods is forbidden: User "jean" cannot list resource "pods" in API group "" in the namespace "my-project-prod" kubectl get pods -n my-project-dev Error from server (Forbidden): pods is forbidden: User "jean" cannot list resource "pods" in API group "" in the namespace "my-project-dev" 

 User: Sarah kubectl get nodes Error from server (Forbidden): nodes is forbidden: User "sarah" cannot list resource "nodes" in API group "" at the cluster scope kubectl get pods -n default Error from server (Forbidden): pods is forbidden: User "sarah" cannot list resource "pods" in API group "" in the namespace "default" kubectl get pods -n my-project-prod Error from server (Forbidden): pods is forbidden: User "sarah" cannot list resource "pods" in API group "" in the namespace "my-project-prod" kubectl get pods -n my-project-dev Error from server (Forbidden): pods is forbidden: User "sarah" cannot list resource "pods" in API group "" in the namespace "my-project-dev"

خلق الدور و ClusterRole


سوف نستخدم ClusterRole ، المتاحة بشكل افتراضي. ومع ذلك ، نعرض أيضًا كيفية إنشاء Role و ClusterRole الخاص بك. في الجوهر ، يمثل كل من Role and ClusterRole مجرد مجموعة من الإجراءات (تسمى verbs ، أي الأفعال الكلامية) المسموح بها لموارد ومساحات أسماء معينة. فيما يلي مثال لملف YAML:

 apiVersion: rbac.authorization.k8s.io/v1beta1 kind: Role metadata: name: list-deployments namespace: my-project-dev rules: - apiGroups: [ apps ] resources: [ deployments ] verbs: [ get, list ] --------------------------------- apiVersion: rbac.authorization.k8s.io/v1beta1 kind: ClusterRole metadata: name: list-deployments rules: - apiGroups: [ apps ] resources: [ deployments ] verbs: [ get, list ]

لإنشائها ، قم بتشغيل الأمر:

 kubectl create -f /path/to/your/yaml/file

ربط دور أو ClusterRole للمستخدمين


الآن ربط ClusterRole الافتراضي ( edit view ) لمستخدمينا على النحو التالي:

  • jean :
    • edit - في مساحة الاسم my-project-dev ؛
    • view - في مساحة الاسم my-project-prod ؛
  • sarah :
    • edit - في مساحة الاسم my-project-prod .

يجب تحديد RoleBindings بمساحات الأسماء ، وليس بواسطة المستخدمين. بمعنى آخر ، لتخويل jean سننشئ اثنين من RoleBindings. مثال على ملف YAML يعرّف RoleBindings لـ jean :

 apiVersion: rbac.authorization.k8s.io/v1 kind: RoleBinding metadata: name: jean namespace: my-project-dev subjects: - kind: User name: jean apiGroup: rbac.authorization.k8s.io roleRef: kind: ClusterRole name: edit apiGroup: rbac.authorization.k8s.io --------------------------------- apiVersion: rbac.authorization.k8s.io/v1 kind: RoleBinding metadata: name: jean namespace: my-project-prod subjects: - kind: User name: jean apiGroup: rbac.authorization.k8s.io roleRef: kind: ClusterRole name: view apiGroup: rbac.authorization.k8s.io

نحن نسمح لـ jean view my-project-prod وتعديل my-project-dev . نفس الشيء يجب القيام به sarah . لتنشيطها ، قم بتشغيل الأمر:

 kubectl apply -f /path/to/your/yaml/file

في هذه الحالة ، تم استخدام kubectl apply بدلاً من kubectl create . الفرق بينهما هو أن create يخلق الكائن ولا يفعل أي شيء آخر ، apply - ليس فقط إنشاء الكائن (إذا لم يكن موجودا) ، ولكن أيضا التحديثات إذا لزم الأمر.

دعونا نتحقق مما إذا كان مستخدمونا قد حصلوا على الأذونات اللازمة.

  • مستخدم: sarah ( edit في my-project-prod )
    • my-project-prod
      • يمكن سرد القرون (1) ؛
      • يمكن إنشاء نشرات (2).
    • my-project-dev
      • لا يمكن سرد القرون (4) ؛
      • لا يمكن إنشاء نشرات (5).

 (1) kubectl get pods -n my-project-prod No resources found. (2) kubectl run nginx --image=nginx --replicas=1 -n my-project-prod deployment.apps/nginx created (3) kubectl get pods -n my-project-prod NAME READY STATUS RESTARTS AGE nginx-7db9fccd9b-t14qw 1/1 Running 0 4s (4) kubectl get pods -n my-project-dev Error from server (Forbidden): pods is forbidden: User "sarah" cannot list resource "pods" in API group "" in the namespace "my-project-dev" (5) kubectl run nginx --image=nginx --replicas=1 -n my-project-dev Error from server (Forbidden): deployments.apps is forbidden: User "sarah" cannot create resource "deployments" in API group "apps" in the namespace "my-project-dev"

  • المستخدم: jean ( view في my-project-prod في my-project-dev )
    • my-project-prod
      • يمكن سرد القرون (1) ؛
      • يمكن سرد نشر '2 (؛
      • لا يمكن حذف النشرات (3).
    • بلدي مشروع ديف:
      • يمكن سرد القرون (4) ؛
      • يمكن إنشاء نشرات (5) ؛
      • يمكن سرد نشر '6 (؛
      • يمكن إزالة النشرات (7).

 (1) kubectl get pods -n my-project-prod NAME READY STATUS RESTARTS AGE nginx-7db9fccd9b-t14qw 1/1 Running 0 101s (2) kubectl get deploy -n my-project-prod NAME READY UP-TO-DATE AVAILABLE AGE nginx 1/1 1 1 110s (3) kubectl delete deploy/nginx -n my-project-prod Error from server (Forbidden): deployments.extensions "nginx" is forbidden: User "jean" cannot delete resource "deployments" in API group "extensions" in the namespace "my-project-prod" (4) kubectl get pods -n my-project-dev No resources found. (5) kubectl run nginx --image=nginx --replicas=1 -n my-project-dev deployment.apps/nginx created (6) kubectl get deploy -n my-project-dev NAME READY UP-TO-DATE AVAILABLE AGE nginx 0/1 1 0 13s (7) kubectl delete deploy/nginx -n my-project-dev deployment.extensions "nginx" deleted (8) kubectl get deploy -n my-project-dev No resources found.

إدارة المستخدم والترخيص


لذلك ، قمنا بتعيين الأدوار المختلفة وتصاريح المستخدم بنجاح. السؤال الذي يطرح نفسه: كيف الآن لإدارة كل هذا؟ كيف أعرف ما إذا تم تعيين أذونات مستخدم معين بشكل صحيح؟ كيف أعرف من لديه السلطة لأداء إجراء محدد؟ كيفية الحصول على صورة عامة لأذونات المستخدم؟

نحتاج إلى إجابات على كل هذه الأسئلة لضمان أمان نظام المجموعة. يسمح لك الأمر kubectl auth can-i بمعرفة ما إذا كان بإمكان المستخدم تنفيذ إجراء معين:

 # kubectl auth can-i $action $resource --as $subject (1) kubectl auth can-i list pods (2) kubectl auth can-i list pods --as jean

يسمح الأمر الأول (1) للمستخدم بمعرفة ما إذا كان يمكنه القيام ببعض الإجراءات. الثاني (2) - يسمح للمسؤول بانتحال شخصية المستخدم لمعرفة ما إذا كان يمكنه تنفيذ إجراء معين. يُسمح بهذا "التناسخ" فقط للمستخدمين ذوي امتيازات مسؤول الكتلة.

هذا هو عمليا كل ما يمكن القيام به مع مجموعة الأدوات المدمجة. هذا هو السبب في أنني سأقدم بعض مشاريع المصادر المفتوحة التي تعمل على توسيع القدرات التي يوفرها فريق can-i kubectl. قبل تقديمها ، لنقم بإنشاء التبعيات: Go and Krew .

الذهاب التثبيت


Go هي لغة برمجة مفتوحة المصدر تتيح لك إنشاء برامج بسيطة وموثوقة وفعالة. تم تطويره بواسطة Google تحت إلهام C و Pascal ، استنادًا إلى المفاهيم الأصلية لروبرت Griesemer و Rob Pike و Ken Thompson .

 wget https://dl.google.com/go/go1.12.5.linux-amd64.tar.gz sudo tar -C /usr/local -xzf go1.12.5.linux-amd64.tar.gz export PATH=$PATH:/usr/local/go/bin

Krew التثبيت


Krew هي أداة تعمل على تبسيط استخدام الإضافات kubectl . يساعدك Krew في العثور على المكونات الإضافية وتثبيتها وإدارتها. فيما يتعلق بالوظائف ، فهي تشبه أدوات مثل apt أو dnf أو brew. Krew متوافق فقط مع kubectl الإصدار 1.12 وأعلى.

 set -x; cd "$(mktemp -d)" && curl -fsSLO "https://storage.googleapis.com/krew/v0.2.1/krew.{tar.gz,yaml}" && tar zxvf krew.tar.gz && ./krew-"$(uname | tr '[:upper:]' '[:lower:]')_amd64" install \ --manifest=krew.yaml --archive=krew.tar.gz export PATH="${KREW_ROOT:-$HOME/.krew}/bin:$PATH"

rakkess


يسمح لك هذا المشروع بعرض جميع الأذونات الممنوحة للمستخدم. على سبيل المثال ، يساعد في الإجابة على سؤال ما الذي يمكن أن يفعله jean . بادئ ذي بدء ، دعونا تثبيته:

 kubectl krew install access-matrix

يمكن العثور على وثائق المشروع في المستودع على GitHub . هنا مثال على عمله:

 kubectl access-matrix -n my-project-dev --as jean



kubect الذين يمكن،


يسمح لنا هذا المشروع بمعرفة المستخدمين الذين يمكنهم تنفيذ إجراء محدد. إنها تساعد في الإجابة على السؤال: "من يستطيع فعل هذا؟" الإعداد:

 go get -v github.com/aquasecurity/kubectl-who-can

الوثائق في مستودع جيثب . مثال العمل:

 kubectl-who-can list pods -n default No subjects found with permissions to list pods assigned through RoleBindings CLUSTERROLEBINDING SUBJECT TYPE SA-NAMESPACE cluster-admin system:masters Group rbac-manager rbac-manager ServiceAccount rbac-manager system:controller:attachdetach-controller attachdetach-controller ServiceAccount kube-system system:controller:clusterrole-aggregation-controller clusterrole-aggregation-controller ServiceAccount kube-system system:controller:cronjob-controller cronjob-controller ServiceAccount kube-system system:controller:daemon-set-controller daemon-set-controller ServiceAccount kube-system system:controller:deployment-controller deployment-controller ServiceAccount kube-system system:controller:endpoint-controller endpoint-controller ServiceAccount kube-system system:controller:generic-garbage-collector generic-garbage-collector ServiceAccount kube-system system:controller:horizontal-pod-autoscaler horizontal-pod-autoscaler ServiceAccount kube-system system:controller:job-controller job-controller ServiceAccount kube-system system:controller:namespace-controller namespace-controller ServiceAccount kube-system system:controller:node-controller node-controller ServiceAccount kube-system system:controller:persistent-volume-binder persistent-volume-binder ServiceAccount kube-system system:controller:pod-garbage-collector pod-garbage-collector ServiceAccount kube-system system:controller:pvc-protection-controller pvc-protection-controller ServiceAccount kube-system system:controller:replicaset-controller replicaset-controller ServiceAccount kube-system system:controller:replication-controller replication-controller ServiceAccount kube-system system:controller:resourcequota-controller resourcequota-controller ServiceAccount kube-system system:controller:statefulset-controller statefulset-controller ServiceAccount kube-system system:coredns coredns ServiceAccount kube-system system:kube-controller-manager system:kube-controller-manager User system:kube-scheduler system:kube-scheduler User

RBAC-بحث


يوفر هذا المشروع نظرة عامة على قواعد RBAC. إنها تساعد في الإجابة على الأسئلة: "ما هو الدور الذي ينتمي إليه jean sarah ؟" ، "ما هو الدور الذي ينتمي إليه جميع المستخدمين؟" ، "ما هو الدور الذي تنتمي إليه المجموعة بأكملها؟". لتثبيت ، قم بتشغيل الأمر:

 kubectl krew install rbac-lookup

الوثائق في مستودع جيثب . هنا مثال على العمل:

 kubectl-rbac_lookup jean SUBJECT SCOPE ROLE jean my-project-dev ClusterRole/edit jean my-project-prod ClusterRole/view kubectl-rbac_lookup sarah SUBJECT SCOPE ROLE sarah my-project-prod ClusterRole/edit kubectl-rbac_lookup --kind user SUBJECT SCOPE ROLE jean my-project-dev ClusterRole/edit jean my-project-prod ClusterRole/view sarah my-project-prod ClusterRole/edit system:anonymous kube-public Role/kubeadm:bootstrap-signer-clusterinfo system:kube-controller-manager kube-system Role/extension-apiserver-authentication-reader system:kube-controller-manager kube-system Role/system::leader-locking-kube-controller-manager system:kube-controller-manager cluster-wide ClusterRole/system:kube-controller-manager system:kube-proxy cluster-wide ClusterRole/system:node-proxier system:kube-scheduler kube-system Role/extension-apiserver-authentication-reader system:kube-scheduler kube-system Role/system::leader-locking-kube-scheduler system:kube-scheduler cluster-wide ClusterRole/system:kube-scheduler system:kube-scheduler cluster-wide ClusterRole/system:volume-scheduler kubectl-rbac_lookup --kind group SUBJECT SCOPE ROLE system:authenticated cluster-wide ClusterRole/system:basic-user system:authenticated cluster-wide ClusterRole/system:discovery system:authenticated cluster-wide ClusterRole/system:public-info-viewer system:bootstrappers:kubeadm:default-node-token cluster-wide ClusterRole/system:node-bootstrapper system:bootstrappers:kubeadm:default-node-token cluster-wide ClusterRole/system:certificates.k8s.io:certificatesigningrequests:nodeclient system:bootstrappers:kubeadm:default-node-token kube-system Role/kube-proxy system:bootstrappers:kubeadm:default-node-token kube-system Role/kubeadm:kubelet-config-1.14 system:bootstrappers:kubeadm:default-node-token kube-system Role/kubeadm:nodes-kubeadm-config system:masters cluster-wide ClusterRole/cluster-admin system:nodes kube-system Role/kubeadm:kubelet-config-1.14 system:nodes kube-system Role/kubeadm:nodes-kubeadm-config system:nodes cluster-wide ClusterRole/system:certificates.k8s.io:certificatesigningrequests:selfnodeclient system:unauthenticated cluster-wide ClusterRole/system:public-info-viewer

مدير RBAC


كما يوحي اسم هذا المشروع بوضوح ، فهو مدير RBAC. يبسط العديد من التلاعب اللازمة. ربما الأهم هو إنشاء RoleBindings. لقد رأينا في وقت سابق أنه عند إنشاء أدوار مختلفة للمستخدم ، من الضروري إنشاء RoleBindings مختلفة. يساعد مدير RBAC من خلال السماح لك بإنشاء رولبينغ واحد فقط مع كل التفويض في وقت واحد. للتثبيت ، يجب عليك تنزيل ملف YAML من المستودع على GitHub:

 kubectl apply -f /path/to/rbac/manager/yaml/file

الوثائق الرسمية موجودة في مستودع جيثب . مثال العمل:

 apiVersion: rbacmanager.reactiveops.io/v1beta1 kind: RBACDefinition metadata: name: jose rbacBindings: - name: jose subjects: - kind: User name: jose roleBindings: - namespace: my-project-prod clusterRole: edit - namespace: my-project-dev clusterRole: edit

استنتاج


أنشأنا مستخدمين في نظام Kubernetes باستخدام شهادة عميل X.509 مع OpenSSL وتمكينهم. لتسهيل إنشاء المستخدم ، يمكنك استخدام البرنامج النصي المتاح في مستودع التخزين الخاص بي على GitHub (أو أوامر kubeadm التجريبية - ترجمة تقريبية ) . أما بالنسبة لإدارة نظام المجموعة ، فيمكنك استخدام المشاريع مفتوحة المصدر الواردة في المقالة:

  • kubectl auth can-i : معرفة ما إذا كان يمكن للمستخدم إجراء بعض الإجراءات ؛
  • rakkess : اكتشف جميع الإجراءات التي يمكن للمستخدم القيام بها ؛
  • kubectl-who-can : تحديد المستخدمين الذين يمكنهم القيام ببعض الإجراءات ؛
  • rbac-lookup : الحصول على نظرة عامة على RBAC ؛
  • مدير RBAC : تبسيط التكوين من خلال الجمع بين روابط الحقوق ، وأتمتة التغييرات على RBAC ، وذلك باستخدام التصنيفات كمحددات لتعيين الحقوق.

يمكن أن يتحول إنشاء المستخدمين إلى مهمة تستغرق وقتًا كبيرًا ، خاصةً إذا كنت بحاجة إلى تعيين عدد كبير من المستخدمين في وقت واحد (أو إنشائها كثيرًا). للتخفيف من هذا الموقف ، يمكن توصيل LDAP للشركات بمجموعة Kubernetes. تقدم بعض مشاريع المصادر المفتوحة ( Kismatic [ Object تبدو مهجورة] و ObjectifLibre ) Kooknet webhooks التي تتيح المصادقة المباشرة من خلال LDAP. حل آخر ممكن هو تكوين خادم OpenID مع LDAP للشركات كخلفية.

PS من المترجم


اقرأ أيضًا في مدونتنا:

Source: https://habr.com/ru/post/ar470503/

More articles:


All Articles