Geekly articles weekly

مقدمة في ترخيص Kubernetes من Hashicorp القنصل


هذا صحيح ، بعد إصدار Hashicorp Consul 1.5.0 في أوائل مايو 2019 في القنصل ، يمكنك تفويض التطبيقات والخدمات التي تعمل في Kubernetes محليًا.


في هذا البرنامج التعليمي ، سنقوم خطوة بخطوة بإنشاء POC (إثبات المفهوم ، PoC - إثبات المفهوم] - لإظهار هذه الميزة الجديدة. المعرفة الأساسية عن Kubernetes و قنصل Hashicorp متوقعة منك. يمكنك استخدام أي نظام أساسي سحابي أو بيئة محلية ، في هذا الدليل ، سنستخدم منصة Google السحابية.


نظرة عامة


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



الشكل 1: نظرة عامة على طريقة تفويض القنصل


دعنا نلقي نظرة على الوثائق الخاصة بطريقة ترخيص Kubernetes المحددة .


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


قبل أن ننتقل إلى إنشاء POC الخاص بنا ، دعنا نعود إلى نظرة عامة على أساليب التصريح القنصل (الشكل 1) وصقله في سياق Kubernetes.


هندسة معمارية


في هذا الدليل ، سنقوم بإنشاء خادم قنصل على جهاز منفصل يتفاعل مع نظام Kubernetes مع تثبيت عميل القنصل. بعد ذلك ، سننشئ تطبيقنا الوهمي في الموقد ونستخدم طريقة التفويض المخصصة الخاصة بنا للقراءة من مستودع مفتاح / قيمة القنصل.


يوضح الرسم البياني أدناه بالتفصيل الهيكل الذي ننشئه في هذا الدليل ، وكذلك منطق طريقة التفويض ، والتي سيتم شرحها لاحقًا.



الشكل 2: نظرة عامة على طريقة الترخيص في Kubernetes


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


لذلك ، إذا أخذنا مخطط نظرة عامة على القنصل (المخطط 1) وتطبيق Kubernetes عليه ، نحصل على المخطط أعلاه (المخطط 2) ، وهنا سيكون المنطق كما يلي:


  1. سيكون لكل جراب حساب خدمة مرفق به رمز JWT تم إنشاؤه ومعروف بواسطة Kubernetes. يتم إدراج هذا الرمز المميز أيضًا في الباطن افتراضيًا.
  2. يبدأ تطبيقنا أو خدمتنا داخل الموقد في أمر إدخال عميل القنصل لدينا. سيشير طلب تسجيل الدخول أيضًا إلى الرمز المميز واسم طريقة الترخيص التي تم إنشاؤها خصيصًا (مثل Kubernetes). تقابل هذه الخطوة رقم 2 الخطوة 1 من مخطط القنصل (المخطط 1).
  3. سيقوم عميل القنصل لدينا بإعادة توجيه هذا الطلب إلى خادم القنصل لدينا.
  4. MAGIC! وهنا يتحقق خادم القنصل من صحة الطلب ، ويجمع معلومات حول هوية الطلب ومقارنته بأي قواعد محددة مسبقًا مرتبطة بها. يوجد أدناه رسم تخطيطي آخر لتوضيح هذا. تقابل هذه الخطوة الخطوات 3 و 4 و 5 من مخطط نظرة عامة على القنصل (المخطط 1).
  5. ينشئ خادم القنصل لدينا رمزًا قنصليًا له أذونات وفقًا لقواعد طريقة الترخيص التي حددناها (والتي حددناها) فيما يتعلق بهوية الطالب. ثم سوف يرسل هذا الرمز مرة أخرى. هذا يتوافق مع الخطوة 6 من مخطط القنصل (المخطط 1).
  6. يعيد عميل القنصل توجيه الرمز المميز إلى التطبيق أو الخدمة المطلوبة.

يمكن الآن لتطبيقنا أو خدمتنا استخدام رمز القنصل هذا للتواصل مع بيانات القنصل الخاصة بنا ، كما هو محدد بواسطة امتيازات الرمز المميز.


وكشف السحر!


بالنسبة لأولئك منكم الذين لا يرضون بالأرنب الموجود في القبعة ويريدون أن يعرفوا كيف يعمل ... اسمحوا لي أن "أريك مدى عمق حفرة الأرانب ".


كما ذكرنا سابقًا ، فإن الخطوة "السحرية" (المخطط 2: الخطوة 4) هي أن خادم القنصل يتحقق من صحة الطلب ، ويقوم بجمع معلومات حول الطلب ومقارنته بأي قواعد محددة مسبقًا مرتبطة بها. تقابل هذه الخطوة الخطوات 3 و 4 و 5 من مخطط نظرة عامة على القنصل (المخطط 1). يوجد أدناه مخطط (المخطط 3) ، والغرض منه هو إظهار ما يحدث بالفعل بوضوح تحت غطاء أسلوب ترخيص Kubernetes معين.



المخطط 3: كشف السحر!


  1. كنقطة بداية ، يقوم عميل القنصل لدينا بإعادة توجيه طلب تسجيل الدخول إلى خادم القنصل الخاص بنا باستخدام رمز حساب Kubernetes واسم المثيل المحدد لطريقة التفويض التي تم إنشاؤها مسبقًا. تقابل هذه الخطوة الخطوة 3 في التفسير السابق للدائرة.
  2. الآن يحتاج خادم القنصل (أو القائد) إلى التحقق من صحة الرمز المميز المستلم. لذلك ، سيتشاور مع مجموعة Kubernetes (من خلال عميل القنصل) ، ومع الأذونات المناسبة ، سوف نكتشف ما إذا كان الرمز أصلي ولمن ينتمي.
  3. ثم يعود الطلب الذي تم التحقق منه إلى قائد القنصل ، ويبحث خادم القنصل عن مثيل لطريقة التفويض بالاسم المحدد من طلب تسجيل الدخول (واكتب Kubernetes).
  4. يحدد قائد القنصل المثيل المحدد لطريقة التفويض (إذا وجد واحدًا) ويقرأ مجموعة القواعد الملزمة المرتبطة بها. ثم يقرأ هذه القواعد ويقارنها بسمات الهوية التي تم التحقق منها.
  5. تادا! انتقل إلى الخطوة 5 في الشرح السابق للدائرة.

تشغيل القنصل خادم على جهاز الظاهري العادية


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


  • بدء تشغيل الجهاز الظاهري (مثيل / الخادم).


  • إنشاء قاعدة لجدار الحماية (مجموعة الأمان في AWS):
  • أود تعيين نفس اسم الجهاز للقاعدة وعلامة الشبكة ، وفي هذه الحالة يكون "skywiz-consul-server-poc".
  • ابحث عن عنوان IP الخاص بالكمبيوتر المحلي وأضفه إلى قائمة عناوين IP المصدر حتى نتمكن من الوصول إلى واجهة المستخدم (UI).
  • افتح المنفذ 8500 لواجهة المستخدم. انقر فوق إنشاء. سنقوم بتغيير جدار الحماية هذا [ الارتباط ] مرة أخرى قريبًا.
  • أضف القاعدة لجدار الحماية إلى المثيل. ارجع إلى لوحة معلومات VM على خادم القنصل وأضف "skywiz-consul-server-poc" إلى حقل علامة الشبكة. انقر فوق حفظ.


  • تثبيت القنصل على جهاز افتراضي ، تحقق هنا. تذكر أنك تحتاج إلى إصدار القنصل ≥ 1.5 [الرابط]
  • إنشاء قنصل واحد القنصل - التكوين على النحو التالي.

groupadd --system consul useradd -s /sbin/nologin --system -g consul consul mkdir -p /var/lib/consul chown -R consul:consul /var/lib/consul chmod -R 775 /var/lib/consul mkdir /etc/consul.d chown -R consul:consul /etc/consul.d

  • للحصول على دليل أكثر تفصيلاً حول تثبيت القنصل وإعداد مجموعة من 3 عقد ، انظر هنا .
  • قم بإنشاء الملف /etc/consul.d/agent.json كما يلي [ link ]:

 ### /etc/consul.d/agent.json { "acl" : { "enabled": true, "default_policy": "deny", "enable_token_persistence": true } }

  • إطلاق خادم القنصل لدينا:

 consul agent \ -server \ -ui \ -client 0.0.0.0 \ -data-dir=/var/lib/consul \ -bootstrap-expect=1 \ -config-dir=/etc/consul.d

  • يجب أن تشاهد مجموعة من الإخراج وينتهي بـ "... تم حظر التحديث من قِبل ACL".
  • حدد موقع عنوان IP الخارجي لخادم القنصل وافتح متصفحًا بعنوان IP هذا على المنفذ 8500. تأكد من فتح واجهة المستخدم.
  • حاول إضافة زوج مفتاح / قيمة. يجب أن يكون هناك خطأ. هذا لأننا قمنا بتحميل خادم القنصل باستخدام ACL ورفضنا جميع القواعد.
  • ارجع إلى shell الخاص بك على خادم القنصل وابدأ العملية في الخلفية أو بطريقة أخرى لكي تعمل ، وأدخل ما يلي:

 consul acl bootstrap

  • ابحث عن القيمة "SecretID" وعد إلى واجهة المستخدم. في علامة تبويب ACL ، أدخل المعرف السري للرمز الذي قمت بنسخه للتو. انسخ SecretID في مكان آخر ، وسنحتاجها لاحقًا.
  • الآن إضافة زوج مفتاح / قيمة. بالنسبة إلى نقطة POC هذه ، أضف ما يلي: مفتاح: "custom-ns / test_key" ، القيمة: "أنا في مجلد custom-ns!"

إطلاق Kubernetes Cluster لطلبنا مع القنصل العميل كما Daemonset


  • إنشاء كتلة K8s (Kubernetes). سنقوم بإنشائه في نفس المنطقة كخادم للوصول بشكل أسرع ، وبالتالي يمكننا استخدام نفس الشبكة الفرعية لسهولة الاتصال مع عناوين IP الداخلية. سوف نسميها skywiz-app-with-consul-client-poc.


  • كملاحظة ، إليك دليل جيد صادفته عند إعداد نظام POC Consul مع Consul Connect.
  • سنستخدم أيضًا مخطط رأس Hashicorp مع ملف قيم ممتد.
  • تثبيت وتكوين هيلم. خطوات التكوين:

 kubectl create serviceaccount tiller --namespace kube-system kubectl create clusterrolebinding tiller-admin-binding \ --clusterrole=cluster-admin --serviceaccount=kube-system:tiller ./helm init --service-account=tiller ./helm update 


 ### poc-helm-consul-values.yaml global: enabled: false image: "consul:latest" # Expose the Consul UI through this LoadBalancer ui: enabled: false # Allow Consul to inject the Connect proxy into Kubernetes containers connectInject: enabled: false # Configure a Consul client on Kubernetes nodes. GRPC listener is required for Connect. client: enabled: true join: ["<PRIVATE_IP_CONSUL_SERVER>"] extraConfig: | { "acl" : { "enabled": true, "default_policy": "deny", "enable_token_persistence": true } } # Minimal Consul configuration. Not suitable for production. server: enabled: false # Sync Kubernetes and Consul services syncCatalog: enabled: false

  • تطبيق مخطط الدفة:

 ./helm install -f poc-helm-consul-values.yaml ./consul-helm - name skywiz-app-with-consul-client-poc

  • عند محاولة البدء ، ستحتاج إلى أذونات لخادم القنصل ، لذلك دعونا نضيفهم.
  • انتبه إلى "مجموعة عناوين Pod" الموجودة على لوحة معلومات نظام المجموعة والعودة إلى قاعدة جدار الحماية skywiz-consul-server-poc.
  • أضف نطاق عناوين IPA إلى قائمة عناوين IP وافتح المنفذين 8301 و 8300.


  • انتقل إلى القنصل UI ، وفي غضون دقائق قليلة سترى أن المجموعة الخاصة بنا ستظهر في علامة التبويب عقدة.


تكوين طريقة التفويض من خلال دمج القنصل مع Kubernetes


  • العودة إلى shell خادم القنصل وتصدير الرمز المميز الذي قمت بحفظه مسبقًا:

 export CONSUL_HTTP_TOKEN=<SecretID>

  • نحتاج إلى معلومات من نظام Kubernetes الخاص بنا لإنشاء مثيل لطريقة المصادقة:
  • kubernetes المضيفة

 kubectl get endpoints | grep kubernetes

  • kubernetes الخدمة وحساب JWT

 kubectl get sa <helm_deployment_name>-consul-client -o yaml | grep "\- name:" kubectl get secret <secret_name_from_prev_command> -o yaml | grep token:

  • يتم تشفير الرمز المميز في base64 ، لذا فك تشفيره باستخدام الأداة المفضلة لديك [ link ]
  • kubernetes-كاليفورنيا-سيرت

 kubectl get secret <secret_name_from_prev_command> -o yaml | grep ca.crt:

  • خذ الشهادة "ca.crt" (بعد فك التشفير باستخدام base64) واكتبها في الملف "ca.crt".
  • قم الآن بإنشاء مثيل لطريقة المصادقة ، واستبدال العناصر النائبة بالقيم التي تلقيتها للتو.

 consul acl auth-method create \ -type "kubernetes" \ -name "auth-method-skywiz-consul-poc" \ -description "This is an auth method using kubernetes for the cluster skywiz-app-with-consul-client-poc" \ -kubernetes-host "<k8s_endpoint_retrieved earlier>" \ -kubernetes-ca-cert=@ca.crt \ -kubernetes-service-account- jwt="<decoded_token_retrieved_earlier>"

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

 ### kv-custom-ns-policy.hcl key_prefix "custom-ns/" { policy = "write" }

  • تطبيق القاعدة

 consul acl policy create \ -name kv-custom-ns-policy \ -description "This is an example policy for kv at custom-ns/" \ -rules @kv-custom-ns-policy.hcl

  • ابحث عن معرف القاعدة التي أنشأتها للتو من الإخراج.
  • إنشاء دور مع قاعدة جديدة.

 consul acl role create \ -name "custom-ns-role" \ -description "This is an example role for custom-ns namespace" \ -policy-id <policy_id> 


 consul acl binding-rule create \ -method=auth-method-skywiz-consul-poc \ -bind-type=role \ -bind-name='custom-ns-role' \ -selector='serviceaccount.namespace=="custom-ns"'

التكوينات الأخيرة


حقوق الوصول


  • إنشاء أذونات. نحتاج إلى منح القنصل الإذن للتحقق من هوية رمز حساب خدمة K8s وتحديدها.
  • اكتب التالي [link] إلى الملف:

 ###skywiz-poc-consul-server_rbac.yaml --- kind: ClusterRoleBinding apiVersion: rbac.authorization.k8s.io/v1 metadata: name: review-tokens namespace: default subjects: - kind: ServiceAccount name: skywiz-app-with-consul-client-poc-consul-client namespace: default roleRef: kind: ClusterRole name: system:auth-delegator apiGroup: rbac.authorization.k8s.io --- kind: ClusterRole apiVersion: rbac.authorization.k8s.io/v1 metadata: name: service-account-getter namespace: default rules: - apiGroups: [""] resources: ["serviceaccounts"] verbs: ["get"] --- kind: ClusterRoleBinding apiVersion: rbac.authorization.k8s.io/v1 metadata: name: get-service-accounts namespace: default subjects: - kind: ServiceAccount name: skywiz-app-with-consul-client-poc-consul-client namespace: default roleRef: kind: ClusterRole name: service-account-getter apiGroup: rbac.authorization.k8s.io

  • إنشاء حقوق الوصول

 kubectl create -f skywiz-poc-consul-server_rbac.yaml

الاتصال القنصل العميل


  • كما هو موضح هنا ، هناك عدة خيارات للاتصال بـ daemonset ، لكننا سننتقل إلى الحل البسيط التالي:
  • قم بتطبيق الملف التالي [ link ].

 ### poc-consul-client-ds-svc.yaml apiVersion: v1 kind: Service metadata: name: consul-ds-client spec: selector: app: consul chart: consul-helm component: client hasDNS: "true" release: skywiz-app-with-consul-client-poc ports: - protocol: TCP port: 80 targetPort: 8500

  • ثم استخدم الأمر المضمن التالي لإنشاء configmap [ link ]. يرجى ملاحظة أننا نشير إلى اسم خدمتنا ، واستبدالها إذا لزم الأمر.

 cat <<EOF | kubectl apply -f - apiVersion: v1 kind: ConfigMap metadata: labels: addonmanager.kubernetes.io/mode: EnsureExists name: kube-dns namespace: kube-system data: stubDomains: | {"consul": ["$(kubectl get svc consul-ds-client -o jsonpath='{.spec.clusterIP}')"]} EOF

اختبار طريقة المصادقة


الآن دعونا ننظر إلى السحر في العمل!


  • قم بإنشاء عدد قليل من مجلدات المفاتيح بنفس مفتاح المستوى الأعلى (أي <new_folder> / sample_key) وقيمة اختيارك. إنشاء سياسات وأدوار مناسبة للمسارات الرئيسية الجديدة. سنفعل الارتباطات في وقت لاحق.


اختبار مساحة الاسم المخصصة:


  • قم بإنشاء مساحة الاسم الخاصة بنا:

 kubectl create namespace custom-ns

  • إنشاء تحت في مساحة الاسم الجديدة لدينا. اكتب التكوين للموقد.

 ###poc-ubuntu-custom-ns.yaml apiVersion: v1 kind: Pod metadata: name: poc-ubuntu-custom-ns namespace: custom-ns spec: containers: - name: poc-ubuntu-custom-ns image: ubuntu command: ["/bin/bash", "-ec", "sleep infinity"] restartPolicy: Never

  • إنشاء تحت:

 kubectl create -f poc-ubuntu-custom-ns.yaml

  • بمجرد بدء تشغيل الحاوية ، اذهب إلى هناك وقم بتركيب الضفيرة.

 kubectl exec poc-ubuntu-custom-ns -n custom-ns -it /bin/bash apt-get update && apt-get install curl -y

  • سنرسل الآن طلبًا لدخول القنصل باستخدام طريقة التفويض التي أنشأناها مسبقًا [ link ].
  • لعرض الرمز المميز الذي تم إدخاله من حساب الخدمة الخاص بك:

 cat /run/secrets/kubernetes.io/serviceaccount/token

  • اكتب ما يلي إلى ملف داخل الحاوية:

 ### payload.json { "AuthMethod": "auth-method-test", "BearerToken": "<jwt_token>" }

  • تسجيل الدخول!

 curl \ --request POST \ --data @payload.json \ consul-ds-client.default.svc.cluster.local/v1/acl/login

  • لإكمال الخطوات المذكورة أعلاه في سطر واحد (حيث سنجري العديد من الاختبارات) ، يمكنك القيام بما يلي:

 echo "{ \ \"AuthMethod\": \"auth-method-skywiz-consul-poc\", \ \"BearerToken\": \"$(cat /run/secrets/kubernetes.io/serviceaccount/token)\" \ }" \ | curl \ --request POST \ --data @- \ consul-ds-client.default.svc.cluster.local/v1/acl/login

  • إنه يعمل! يجب على الأقل. الآن خذ SecretID وحاول الوصول إلى المفتاح / القيمة التي يجب أن يكون لدينا الوصول إليها.

 curl \ consul-ds-client.default.svc.cluster.local/v1/kv/custom-ns/test_key --header “X-Consul-Token: <SecretID_from_prev_response>”

  • يمكنك فك تشفير base64 "القيمة" ونرى أنها تتطابق مع القيمة في ns / test_key المخصصة في واجهة المستخدم. إذا استخدمت نفس القيمة أعلاه في هذا الدليل ، فستكون القيمة المشفرة IkknbSBpbiB0aGUgY3VzdG9tLW5zIGZvbGRlciE.

اختبار حساب خدمة المستخدم:


  • قم بإنشاء ServiceAccount مخصص باستخدام الأمر التالي [ link ].

 kubectl apply -f - <<EOF apiVersion: v1 kind: ServiceAccount metadata: name: custom-sa EOF

  • إنشاء ملف تكوين جديد للموقد. يرجى ملاحظة أنني قمت بتشغيل تثبيت حليقة لإنقاذ العمل :)

 ###poc-ubuntu-custom-sa.yaml apiVersion: v1 kind: Pod metadata: name: poc-ubuntu-custom-sa namespace: default spec: serviceAccountName: custom-sa containers: - name: poc-ubuntu-custom-sa image: ubuntu command: ["/bin/bash","-ec"] args: ["apt-get update && apt-get install curl -y; sleep infinity"] restartPolicy: Never

  • بعد ذلك ، قم بتشغيل الغلاف داخل الحاوية.

 kubectl exec -it poc-ubuntu-custom-sa /bin/bash

  • تسجيل الدخول!

 echo "{ \ \"AuthMethod\": \"auth-method-skywiz-consul-poc\", \ \"BearerToken\": \"$(cat /run/secrets/kubernetes.io/serviceaccount/token)\" \ }" \ | curl \ --request POST \ --data @- \ consul-ds-client.default.svc.cluster.local/v1/acl/login

  • تم رفض الإذن. أوه ، لقد نسينا إضافة قاعدة جديدة ملزمة مع الأذونات المناسبة ، دعونا نفعل ذلك الآن.

كرر الخطوات السابقة أعلاه:
أ) قم بإنشاء سياسة متطابقة للبادئة "custom-sa /".
ب) إنشاء دور ، وتسميته "دور مخصص"
ج) إرفاق سياسة الدور.


  • إنشاء قاعدة ربط (ممكن فقط من CLI / api). لاحظ القيمة المختلفة لعلامة المحدد.

 consul acl binding-rule create \ -method=auth-method-skywiz-consul-poc \ -bind-type=role \ -bind-name='custom-sa-role' \ -selector='serviceaccount.name=="custom-sa"'

  • تسجيل الدخول مرة أخرى من الحاوية poc-ubuntu-custom-sa. النجاح!
  • تحقق من وصولنا إلى المسار المخصص / المفتاح.

 curl \ consul-ds-client.default.svc.cluster.local/v1/kv/custom-sa/test_key --header “X-Consul-Token: <SecretID>”

  • يمكنك أيضًا التأكد من أن هذا الرمز المميز لا يوفر الوصول إلى kv في "custom-ns /". ما عليك سوى تكرار الأمر أعلاه بعد استبدال "custom-sa" بالبادئة "custom-ns".
    تم رفض الإذن.

مثال التراكب:


  • تجدر الإشارة إلى أنه سيتم إضافة جميع التعيينات الملزمة للقواعد إلى الرمز المميز بهذه الحقوق.
  • توجد حاوية poc-ubuntu-custom-sa الخاصة بنا في مساحة الاسم الافتراضية - لذلك دعونا نستخدمها في ربط قواعد آخر.
  • كرر الخطوات السابقة:
    أ) قم بإنشاء سياسة متطابقة لبادئة المفتاح "default /".
    ب) إنشاء دور ، وتسميته "دور افتراضي افتراضي"
    ج) إرفاق سياسة الدور.
  • إنشاء قاعدة ربط (ممكن فقط من CLI / api)

 consul acl binding-rule create \ -method=auth-method-skywiz-consul-poc \ -bind-type=role \ -bind-name='default-ns-role' \ -selector='serviceaccount.namespace=="default"'

  • ارجع إلى حاوية poc-ubuntu-custom-sa وحاول الوصول إلى المسار الافتراضي / kv.
  • تم رفض الإذن.
    يمكنك عرض بيانات الاعتماد المحددة لكل رمز مميز في واجهة المستخدم ضمن ACL> الرموز. كما ترون ، يتم إرفاق "دور مخصص مخصص" برمزنا الحالي فقط. تم إنشاء الرمز المميز الذي نستخدمه حاليًا عند تسجيل الدخول ، وبعد ذلك لم يكن هناك سوى قاعدة واحدة ملزمة ، والتي تقابلها بعد ذلك. نحتاج إلى تسجيل الدخول مرة أخرى واستخدام الرمز المميز الجديد.
  • تأكد من أنه يمكنك القراءة من كل من "custom-sa /" ومسارات kv "الافتراضية /".
    النجاح!
    وذلك لأن poc-ubuntu-custom-sa لدينا يطابق روابط قواعد custom-sa و default-ns.

استنتاج


TTL رمزية mgmt؟


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


من الممكن إنشاء رمز مميز يدويًا باستخدام TTL:



آمل أن نتمكن في المستقبل القريب من التحكم في كيفية إنشاء الرموز (لكل قاعدة أو طريقة ترخيص) وإضافة TTL.


حتى ذلك الحين ، يُقترح استخدام نقطة النهاية للخروج من النظام في منطقك.



اقرأ أيضًا مقالات أخرى على مدونتنا:


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

More articles:


All Articles