التخطي إلى المحتوى الرئيسي

Admission Webhook for K8s

1. نظرة عامة ووثائق لـ Casbin K8s-Gatekeeper​

Casbin K8s-GateKeeper هو ويب هوك للقبول في Kubernetes يدمج Casbin كأداة للتحكم في الوصول. باستخدام Casbin K8s-GateKeeper، يمكنك إنشاء قواعد مرنة لتفويض أو اعتراض أي عملية على موارد K8s، دون كتابة أي جزء من الكود، ولكن فقط بعض الأسطر من التكوينات الإعلانية لنماذج وسياسات Casbin، والتي هي جزء من لغة قائمة التحكم في الوصول (ACL) الخاصة بـ Casbin.

Casbin K8s-GateKeeper تم تطويره وصيانته من قبل مجتمع Casbin. مستودع هذا المشروع متاح هنا: https://github.com/casbin/k8s-gatekeeper

0.1 مثال بسيط​

على سبيل المثال، لا تحتاج إلى كتابة أي كود، ولكن استخدم الأسطر التالية من التكوين لتحقيق هذه الوظيفة: "منع الصور ذات العلامات المحددة من الاستخدام في أي عمليات نشر":

Model:

[request_definition]
r =  obj

[policy_definition]
p =  obj,eft

[policy_effect]
e = !some(where (p.eft == deny))

[matchers]
m = r.obj.Request.Namespace == "default" && r.obj.Request.Resource.Resource =="deployments" && \
contain(split(accessWithWildcard(${OBJECT}.Spec.Template.Spec.Containers , "*", "Image"),":",1) , p.obj)

And Policy:

p, "1.14.1",deny

هذه بلغة Casbin ACL العادية. لنفترض أنك قد قرأت بالفعل الفصول عنها، سيكون من السهل جدًا فهمها.

Casbin K8s-Gatekeeper له المزايا التالية:

  • سهل الاستخدام. كتابة بعض الأسطر من ACL أفضل بكثير من كتابة الكثير من الكود.
  • يسمح بتحديثات ساخنة للتكوينات. لا تحتاج إلى إيقاف تشغيل الإضافة بأكملها لتعديل التكوينات.
  • هو مرن. يمكن صنع قواعد تعسفية على أي مورد K8s، والتي يمكن استكشافها مع kubectl gatekeeper.
  • يبسط تنفيذ ويب هوك القبول في K8s، والذي يعتبر معقدًا للغاية. لا تحتاج إلى معرفة ما هو ويب هوك القبول في K8s أو كيفية كتابة الكود له. كل ما تحتاج إلى معرفته هو المورد الذي تريد وضع قيود عليه ثم كتابة Casbin ACL. الجميع يعلم أن K8s معقد، ولكن باستخدام Casbin K8s-Gatekeeper، يمكن توفير وقتك.
  • يتم صيانته من قبل مجتمع Casbin. لا تتردد في الاتصال بنا إذا كان هناك أي شيء يحيرك حول هذه الإضافة أو إذا واجهت أي مشاكل عند تجربتها.

1.1 كيف يعمل Casbin K8s-Gatekeeper؟​

K8s-Gatekeeper هو ويب هوك للقبول في K8s يستخدم Casbin لتطبيق قواعد تحكم في الوصول محددة من قبل المستخدم بشكل تعسفي للمساعدة في منع أي عملية على K8s لا يريدها المسؤول.

Casbin هو مكتبة تحكم في الوصول مفتوحة المصدر قوية وفعالة. يوفر دعمًا لتطبيق التفويض بناءً على نماذج تحكم في الوصول المختلفة. لمزيد من التفاصيل حول Casbin، انظر نظرة عامة.

ويب هوك القبول في K8s هي استدعاءات HTTP تتلقى 'طلبات القبول' وتقوم بشيء ما معها. على وجه الخصوص، K8s-Gatekeeper هو نوع خاص من ويب هوك القبول: 'ValidatingAdmissionWebhook'، والذي يمكنه أن يقرر ما إذا كان سيقبل طلب القبول هذا أم لا. أما بالنسبة لطلبات القبول، فهي طلبات HTTP تصف عملية على موارد محددة في K8s (على سبيل المثال، إنشاء/حذف عملية نشر). لمزيد من المعلومات حول ويب هوك القبول، انظر الوثائق الرسمية لـ K8s.

1.2 مثال يوضح كيف يعمل​

على سبيل المثال، عندما يرغب شخص ما في إنشاء عملية نشر تحتوي على بود يشغل nginx (باستخدام kubectl أو عملاء K8s)، سيولد K8s طلب قبول، والذي (إذا تم ترجمته إلى تنسيق YAML) يمكن أن يكون شيئًا مثل هذا:

apiVersion: apps/v1
kind: Deployment
metadata:
  name: nginx-deployment
spec:
  selector:
    matchLabels:
      app: nginx
  replicas: 1
  template:
    metadata:
      labels:
        app: nginx
    spec:
      containers:
      - name: nginx
        image: nginx:1.14.1
        ports:
        - containerPort: 80

سيمر هذا الطلب بعملية جميع الوسطاء الموضحين في الصورة، بما في ذلك K8s-Gatekeeper الخاص بنا. يمكن لـ K8s-Gatekeeper اكتشاف جميع مطبقات Casbin المخزنة في etcd الخاص بـ K8s، والتي يتم إنشاؤها وصيانتها من قبل المستخدم (عبر kubectl أو العميل Go الذي نوفره). كل مطبق يحتوي على نموذج Casbin وسياسة Casbin. سيتم معالجة طلب القبول بواسطة كل مطبق، واحدًا تلو الآخر، وفقط بالمرور عبر جميع المطبقات يمكن قبول طلب بواسطة هذا K8s-Gatekeeper.

(إذا كنت لا تفهم ما هو مطبق Casbin، أو نموذج، أو سياسة، انظر هذا الوثيقة: البدء).

على سبيل المثال، لسبب ما، يريد المسؤول منع ظهور الصورة 'nginx:1.14.1' مع السماح بـ 'nginx:1.3.1'. يمكن إنشاء مطبق يحتوي على القاعدة والسياسة التالية (سنشرح كيفية إنشاء مطبق، ما هي هذه النماذج والسياسات، وكيفية كتابتها في الفصول التالية).

Model:

[request_definition]
r =  obj

[policy_definition]
p =  obj,eft

[policy_effect]
e = !some(where (p.eft == deny))

[matchers]
m = r.obj.Request.Namespace == "default" && r.obj.Request.Resource.Resource =="deployments" && \
access(r.obj.Request.Object.Object.Spec.Template.Spec.Containers , 0, "Image") == p.obj

Policy:

p, "nginx:1.13.1",allow
p, "nginx:1.14.1",deny

بإنشاء مطبق يحتوي على النموذج والسياسة أعلاه، سيتم رفض طلب القبول السابق من قبل هذا المطبق، مما يعني أن K8s لن ينشئ هذه العملية النشر.

2 تثبيت K8s-gatekeeper​

هناك ثلاث طرق متاحة لتثبيت K8s-gatekeeper: ويب هوك خارجي، ويب هوك داخلي، وHelm.

ملاحظة

ملاحظة: هذه الطرق مخصصة فقط للمستخدمين لتجربة K8s-gatekeeper وليست آمنة. إذا كنت ترغب في استخدامه في بيئة إنتاجية، يرجى التأكد من قراءة الفصل 5. الإعدادات المتقدمة وإجراء أي تعديلات ضرورية قبل التثبيت.

2.1 ويب هوك داخلي​

2.1.1 الخطوة 1: بناء الصورة​

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

docker build --target webhook -t k8s-gatekeeper .

هذا الأمر سيقوم بإنشاء صورة محلية تسمى 'k8s-gatekeeper:latest'.

ملاحظة

ملاحظة: إذا كنت تستخدم minikube، يرجى تنفيذ eval $(minikube -p minikube docker-env) قبل تشغيل 'docker build'.

2.1.2 الخطوة 2: إعداد الخدمات والتوزيعات لـ K8s-gatekeeper​

قم بتشغيل الأوامر التالية:

kubectl apply -f config/rbac.yaml
kubectl apply -f config/webhook_deployment.yaml 
kubectl apply -f config/webhook_internal.yaml

هذا سيبدأ تشغيل K8s-gatekeeper، ويمكنك التأكد من ذلك بتشغيل kubectl get pods.

2.1.3 الخطوة 3: تثبيت موارد CRD لـ K8s-gatekeeper​

قم بتشغيل الأوامر التالية:

kubectl apply -f config/auth.casbin.org_casbinmodels.yaml 
kubectl apply -f config/auth.casbin.org_casbinpolicies.yaml

2.2 الويب هوك الخارجي​

لطريقة الويب هوك الخارجية، سيتم تشغيل K8s-gatekeeper خارج Kubernetes، وسيقوم Kubernetes بالوصول إلى K8s-gatekeeper كما لو كان يصل إلى موقع ويب عادي. Kubernetes لديه متطلب إلزامي بأن يكون الويب هوك للقبول HTTPS. لغرض تجربة K8s-gatekeeper، قدمنا مجموعة من الشهادات ومفتاح خاص (على الرغم من أن هذا ليس آمنًا). إذا كنت تفضل استخدام شهادتك الخاصة، يرجى الرجوع إلى الفصل 5. الإعدادات المتقدمة للحصول على تعليمات حول تعديل الشهادة والمفتاح الخاص. الشهادة التي نقدمها صادرة لـ 'webhook.domain.local'.

لذا، قم بتعديل المضيف (مثل، /etc/hosts) وأشر 'webhook.domain.local' إلى عنوان IP الذي يعمل عليه K8s-gatekeeper. ثم نفذ الأمر التالي:

2.3 تثبيت K8s-gatekeeper عبر Helm

go mod tidy
go mod vendor
go run cmd/webhook/main.go
kubectl apply -f config/auth.casbin.org_casbinmodels.yaml 
kubectl apply -f config/auth.casbin.org_casbinpolicies.yaml
kubectl apply -f config/webhook_external.yaml

2.3.1 الخطوة 1: بناء الصورة​

يرجى الرجوع إلى الفصل 2.1.1.​

2.3.2 تثبيت Helm

قم بتشغيل الأمر helm install k8sgatekeeper ./k8sgatekeeper.​

جرب K8s-gatekeeper 3.1 إنشاء نموذج Casbin والسياسة​

لديك طريقتان لإنشاء نموذج وسياسة: عبر kubectl أو عبر go-client الذي نقدمه.​

3.1.1 إنشاء/تحديث نموذج Casbin والسياسة عبر kubectl

في K8s-gatekeeper، يتم تخزين نموذج Casbin في مورد CRD يسمى 'CasbinModel'.​

تقع تعريفه في config/auth.casbin.org_casbinmodels.yaml. هناك أمثلة في example/allowed_repo/model.yaml.

انتبه للحقول التالية: metadata.name: اسم النموذج.

  • يجب أن يكون هذا الاسم هو نفسه اسم كائن CasbinPolicy المتعلق بهذا النموذج، حتى يتمكن K8s-gatekeeper من إقرانهما وإنشاء مُنفذ. spec.enable: إذا تم ضبط هذا الحقل على 'false'، سيتم تجاهل هذا النموذج (وكذلك كائن CasbinPolicy المتعلق بهذا النموذج).
  • spec.modelText: سلسلة تحتوي على نص نموذج Casbin.
  • يتم تخزين السياسة Casbin في مورد CRD آخر يسمى 'CasbinPolicy'، ويمكن العثور على تعريفه في config/auth.casbin.org_casbinpolicies.yaml.

هناك أمثلة في example/allowed_repo/policy.yaml.

انتبه للحقول التالية: metadata.name: اسم السياسة.

  • يجب أن يكون هذا الاسم هو نفسه اسم كائن CasbinModel المتعلق بهذه السياسة، حتى يتمكن K8s-gatekeeper من إقرانهما وإنشاء مُنفذ. spec.policyItem: سلسلة تحتوي على نص سياسة نموذج Casbin.
  • بعد إنشاء ملفات CasbinModel وCasbinPolicy الخاصة بك، استخدم الأمر التالي لتطبيقها:

بمجرد إنشاء زوج من CasbinModel وCasbinPolicy، سيكون K8s-gatekeeper قادرًا على اكتشافه خلال 5 ثوانٍ.

kubectl apply -f <filename>

3.1.2 إنشاء/تحديث نموذج Casbin والسياسة عبر go-client الذي نقدمه

نحن نفهم أن هناك حالات قد لا يكون من الملائم فيها استخدام الشل لتنفيذ الأوامر مباشرة على عقدة من عقد K8s، مثل عندما تقوم ببناء منصة سحابية تلقائية لشركتك.​

لذلك، قمنا بتطوير go-client لإنشاء وصيانة CasbinModel وCasbinPolicy. مكتبة go-client تقع في pkg/client.

في client.go، نقدم وظيفة لإنشاء عميل.

في client.go، نوفر وظيفة لإنشاء عميل.

func NewK8sGateKeeperClient(externalClient bool) (*K8sGateKeeperClient, error)

يحدد المعامل externalClient ما إذا كان K8s-gatekeeper يعمل داخل عنقود K8s أم لا.

في model.go، نوفر وظائف متعددة لإنشاء، حذف، وتعديل CasbinModel. يمكنك معرفة كيفية استخدام هذه الواجهات في model_test.go.

في policy.go، نوفر وظائف متعددة لإنشاء، حذف، وتعديل CasbiPolicy. يمكنك معرفة كيفية استخدام هذه الواجهات في policy_test.go.

3.1.2 جرب ما إذا كان K8s-gatekeeper يعمل​

افترض أنك قد أنشأت بالفعل النموذج والسياسة الدقيقين في example/allowed_repo. الآن، جرب الأمر التالي:

kubectl apply -f example/allowed_repo/testcase/reject_1.yaml

يجب أن تجد أن K8s سيرفض هذا الطلب ويذكر أن الويب هوك كان السبب في رفض هذا الطلب. ومع ذلك، عندما تحاول تطبيق example/allowed_repo/testcase/approve_2.yaml، سيتم قبوله.

4. كيفية كتابة النموذج والسياسة مع K8s-gatekeeper​

أولاً، تأكد من أنك ملم بالقواعد الأساسية لنماذج وسياسات Casbin. إذا لم تكن كذلك، يرجى قراءة قسم البدء أولاً. في هذا الفصل، نفترض أنك تفهم بالفعل ما هي نماذج وسياسات Casbin.

4.1 تعريف الطلب في النموذج​

عندما يقوم K8s-gatekeeper بتفويض طلب، فإن الإدخال دائمًا عبارة عن كائن: كائن Go لطلب القبول. هذا يعني أن المنفذ سيستخدم دائمًا بهذه الطريقة:

ok, err := enforcer.Enforce(admission)

حيث admission هو كائن AdmissionReview محدد بواسطة واجهة برمجة تطبيقات K8s الرسمية "k8s.io/api/admission/v1". يمكنك العثور على تعريف هذا الهيكل في هذا المستودع: https://github.com/kubernetes/api/blob/master/admission/v1/types.go. لمزيد من المعلومات، يمكنك أيضًا الرجوع إلى https://kubernetes.io/docs/reference/access-authn-authz/extensible-admission-controllers/#webhook-request-and-response.

لذلك، بالنسبة لأي نموذج يستخدمه K8s-gatekeeper، يجب أن يكون تعريف request_definition دائمًا كما يلي:

    [request_definition]
    r =  obj

اسم 'obj' ليس إلزاميًا، طالما أن الاسم متسق مع الاسم المستخدم في جزء [matchers].

4.2 مطابقات النموذج​

من المفترض أن تستخدم ميزة ABAC لكتابة قواعدك. ومع ذلك، فإن مقيم التعبير المدمج في Casbin لا يدعم الفهرسة في الخرائط أو المصفوفات (الشرائح)، ولا توسيع المصفوفات. لذلك، يوفر K8s-gatekeeper وظائف 'Casbin' متنوعة كامتدادات لتنفيذ هذه الميزات. إذا وجدت أن طلبك لا يمكن تلبيته بواسطة هذه الامتدادات، فلا تتردد في بدء مشكلة، أو إنشاء طلب سحب.

إذا لم تكن معتادًا على وظائف Casbin، يمكنك الرجوع إلى الوظيفة لمزيد من المعلومات.

إليك الوظائف الإضافية:

4.2.1 وظائف الإضافة​

4.2.1.1 الوصول​

يُستخدم الوصول لحل المشكلة التي لا يدعمها Casbin في الفهرسة في الخرائط أو المصفوفات. يوضح المثال example/allowed_repo/model.yaml استخدام هذه الوظيفة:

[matchers]
m = r.obj.Request.Namespace == "default" && r.obj.Request.Resource.Resource =="deployments" && \
access(r.obj.Request.Object.Object.Spec.Template.Spec.Containers , 0, "Image") == p.obj

في هذا المطابق، access(r.obj.Request.Object.Object.Spec.Template.Spec.Containers , 0, "Image") مكافئ لـ r.obj.Request.Object.Object.Spec.Template.Spec.Containers[0].Image، حيث r.obj.Request.Object.Object.Spec.Template.Spec.Containers هو شريحة.

يمكن للوصول أيضًا استدعاء وظائف بسيطة ليس لها معاملات وتعيد قيمة واحدة. يوضح المثال example/container_resource_limit/model.yaml هذا:

[matchers]
  m = r.obj.Request.Namespace == "default" && r.obj.Request.Resource.Resource =="deployments" && \
  parseFloat(access(r.obj.Request.Object.Object.Spec.Template.Spec.Containers , 0, "Resources","Limits","cpu","Value")) >= parseFloat(p.cpu) && \
  parseFloat(access(r.obj.Request.Object.Object.Spec.Template.Spec.Containers , 0, "Resources","Limits","memory","Value")) >= parseFloat(p.memory)

في هذا المطابق، access(r.obj.Request.Object.Object.Spec.Template.Spec.Containers , 0, "Resources","Limits","cpu","Value") مكافئ لـ r.obj.Request.Object.Object.Spec.Template.Spec.Containers[0].Resources.Limits["cpu"].Value()، حيث r.obj.Request.Object.Object.Spec.Template.Spec.Containers[0].Resources.Limits هو خريطة، وValue() هي وظيفة بسيطة ليس لها معاملات وتعيد قيمة واحدة.

4.2.1.2 accessWithWildcard​

أحيانًا، قد يكون لديك طلب مثل هذا: يجب أن يكون لجميع العناصر في مصفوفة بادئة "aaa". ومع ذلك، لا يدعم Casbin حلقات for. مع accessWithWildcard وميزة "توسيع الخريطة/الشريحة"، يمكنك تنفيذ مثل هذا الطلب بسهولة.

على سبيل المثال، لنفترض أن a.b.c هي مصفوفة [aaa,bbb,ccc,ddd,eee]، فإن نتيجة accessWithWildcard(a,"b","c","*") ستكون شريحة [aaa,bbb,ccc,ddd,eee]. باستخدام البدل *، يتم توسيع الشريحة.

بالمثل، يمكن استخدام البدل أكثر من مرة. على سبيل المثال، نتيجة accessWithWildcard(a,"b","c","*","*") ستكون [a.b.c[0][0], a.b.c[0][1], ..., a.b.c[1][0], a.b.c[1][1], ...].

4.2.1.3 وظائف تدعم المعاملات المتغيرة الطول​

في مقيم التعبير لـ Casbin، عندما يكون المعامل مصفوفة، سيتم توسيعه تلقائيًا كمعامل متغير الطول. باستخدام هذه الميزة لدعم توسيع المصفوفة/الشريحة/الخريطة، لقد دمجنا أيضًا عدة وظائف تقبل مصفوفة/شريحة كمعامل:

  • contain(): تقبل معاملات متعددة وتعيد ما إذا كان أي معامل (باستثناء المعامل الأخير) يساوي المعامل الأخير.
  • split(a,b,c...,sep,index): تُعيد مصفوفة تحتوي على [splits(a,sep)[index], splits(b,sep)[index], splits(a,sep)[index], ...].
  • len(): تُعيد طول الوسيطة ذات الطول المتغير.
  • matchRegex(a,b,c...,regex): تُعيد ما إذا كانت جميع الوسائط المعطاة (a, b, c, ...) تطابق العبارة النمطية المعطاة.

هنا مثال في example/disallowed_tag/model.yaml:

    [matchers]
    m = r.obj.Request.Namespace == "default" && r.obj.Request.Resource.Resource =="deployments" && \
    contain(split(accessWithWildcard(r.obj.Request.Object.Object.Spec.Template.Spec.Containers , "*", "Image"),":",1) , p.obj)

بافتراض أن accessWithWildcard(r.obj.Request.Object.Object.Spec.Template.Spec.Containers , "*", "Image") تُعيد ['a:b', 'c:d', 'e:f', 'g:h']، لأن الدالة splits تدعم الوسائط ذات الطول المتغير وتؤدي عملية التقسيم على كل عنصر، سيتم اختيار العنصر في المؤشر 1 وإعادته. لذلك، split(accessWithWildcard(r.obj.Request.Object.Object.Spec.Template.Spec.Containers , "*", "Image"),":",1) تُعيد ['b','d','f','h']. و contain(split(accessWithWildcard(r.obj.Request.Object.Object.Spec.Template.Spec.Containers , "*", "Image"),":",1) , p.obj) تُعيد ما إذا كان p.obj موجودًا في ['b','d','f','h'].

4.2.1.2 وظائف تحويل النوع​

  • ParseFloat(): تحلل عدد صحيح إلى عدد عشري (هذا ضروري لأن أي رقم يُستخدم في المقارنة يجب تحويله إلى عدد عشري).
  • ToString(): تحول كائن إلى نص. يجب أن يكون لهذا الكائن نوع أساسي من النوع string (على سبيل المثال، كائن من نوع XXX عندما يكون هناك بيان type XXX string).
  • IsNil(): تُعيد ما إذا كان الوسيط هو nil.

5. الإعدادات المتقدمة​

5.1 حول الشهادات​

في Kubernetes (k8s)، من الضروري أن يستخدم webhook بروتوكول HTTPS. هناك نهجان لتحقيق ذلك:

  • استخدام شهادات ذاتية التوقيع (الأمثلة في هذا المستودع تستخدم هذه الطريقة)
  • استخدام شهادة عادية

5.1.1 الشهادات ذاتية التوقيع​

استخدام شهادة ذاتية التوقيع يعني أن السلطة الشهادة (CA) التي تصدر الشهادة ليست واحدة من السلطات الشهادة المعروفة. لذلك، يجب إعلام k8s بهذه السلطة الشهادة.

حاليًا، المثال في هذا المستودع يستخدم سلطة شهادة مصنوعة ذاتيًا، حيث يتم تخزين المفتاح الخاص والشهادة في config/certificate/ca.crt و config/certificate/ca.key على التوالي. شهادة webhook هي config/certificate/server.crt، والتي تصدرها سلطة الشهادة المصنوعة ذاتيًا. نطاقات هذه الشهادة هي "webhook.domain.local" (لـ webhook خارجي) و "casbin-webhook-svc.default.svc" (لـ webhook داخلي).

يتم نقل معلومات عن سلطة الشهادة إلى k8s عبر ملفات تكوين webhook. كلا من config/webhook_external.yaml و config/webhook_internal.yaml يحتويان على حقل يسمى "CABundle"، والذي يحتوي على سلسلة مشفرة بترميز base64 لشهادة سلطة الشهادة.

في حالة الحاجة إلى تغيير الشهادة/النطاق (على سبيل المثال، إذا كنت ترغب في وضع هذا webhook في مساحة أخرى من k8s أثناء استخدام webhook داخلي، أو إذا كنت ترغب في تغيير النطاق أثناء استخدام webhook خارجي)، يجب اتباع الإجراءات التالية:

  1. إنشاء سلطة شهادة جديدة:

    • إنشاء المفتاح الخاص لسلطة الشهادة المزيفة:

      openssl genrsa -des3 -out ca.key 2048

    • إزالة حماية كلمة المرور للمفتاح الخاص:

      openssl rsa -in ca.key -out ca.key

  2. إنشاء مفتاح خاص لخادم webhook:

    openssl genrsa -des3 -out server.key 2048
    openssl rsa -in server.key -out server.key

  3. استخدم سلطة الشهادة المولدة ذاتيًا لتوقيع شهادة لـ webhook:

    • انسخ ملف تكوين openssl الخاص بنظامك للاستخدام المؤقت. يمكنك معرفة موقع ملف التكوين بتشغيل openssl version -a، وعادة ما يسمى openssl.cnf.

    • في ملف التكوين:

      • ابحث عن الفقرة [req] وأضف السطر التالي: req_extensions = v3_req

      • ابحث عن الفقرة [v3_req] وأضف السطر التالي: subjectAltName = @alt_names

      • أضف الأسطر التالية إلى الملف:

        [alt_names]
        DNS.2=<The domain you want>

        ملاحظة: استبدل 'casbin-webhook-svc.default.svc' بالاسم الحقيقي لخدمتك الخاصة إذا قررت تعديل اسم الخدمة.

    • استخدم ملف التكوين المعدل لإنشاء ملف طلب شهادة:

      openssl req -new -nodes -keyout server.key -out server.csr -config openssl.cnf

    • استخدم سلطة الشهادة المصنوعة ذاتيًا للرد على الطلب وتوقيع الشهادة:

      openssl x509 -req -days 3650 -in server.csr -out server.crt -CA ca.crt -CAkey ca.key -CAcreateserial -extensions v3_req -extensions SAN -extfile openssl.cnf

  4. استبدل حقل 'CABundle': كلا من config/webhook_external.yaml و config/webhook_internal.yaml يحتويان على حقل يسمى "CABundle"، والذي يحتوي على سلسلة مشفرة بترميز base64 لشهادة سلطة الشهادة. قم بتحديث هذا الحقل بالشهادة الجديدة.

  5. إذا كنت تستخدم helm، يجب تطبيق تغييرات مماثلة على الرسوم البيانية helm.

5.1.2 الشهادات القانونية​

إذا كنت تستخدم شهادات قانونية، فلن تحتاج إلى المرور بكل هذه الإجراءات. أزل حقل "CABundle" في config/webhook_external.yaml و config/webhook_internal.yaml، وغير النطاق في هذه الملفات إلى النطاق الذي تملكه.