🥇 مقدمة إلى ترخيص Kubernetes لقنصل Hashicorp

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

في هذا البرنامج التعليمي ، سننشئ خطوة بخطوة POC (إثبات المفهوم ، PoC) يوضح هذه الميزة الجديدة. من المتوقع أن تكون لديك معرفة أساسية بـ Kubernetes و Hashicorp's Consul. وبينما يمكنك استخدام أي نظام أساسي سحابي أو بيئة محلية ، في هذا البرنامج التعليمي ، سنستخدم Google Cloud Platform.

مراجعة

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

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

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

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

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

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

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

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

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

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

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

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

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

تم الكشف عن السحر!

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

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

الشكل 3: تم الكشف عن السحر!

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

قم بتشغيل Consul-server في جهاز ظاهري عادي

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

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

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

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

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

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

### /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. تأكد من فتح واجهة المستخدم.
حاول إضافة زوج مفتاح / قيمة. يجب أن يكون هناك خطأ. هذا لأننا حملنا خادم القنصل بقائمة التحكم بالوصول ورفضنا جميع القواعد.
ارجع إلى قوقعتك على خادم القنصل وابدأ العملية في الخلفية أو بطريقة أخرى لجعلها تعمل واكتب ما يلي:

consul acl bootstrap

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

بدء مجموعة Kubernetes لتطبيقنا مع عميل القنصل باعتباره Daemonset

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

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

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

مخطط خوذة: https://www.consul.io/docs/platform/k8s/helm.html
استخدم ملف القيم التالي (ملاحظة قمت بتعطيل معظمها):

### 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

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

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

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

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

export CONSUL_HTTP_TOKEN=<SecretID>

نحتاج إلى معلومات من مجموعة Kubernetes لإنشاء مثيل للتابع auth:
مضيف 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 ، لذا فك تشفيره بأداتك المفضلة [رابط]
kubernetes-ca-cert

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>" 
[email protected] 
-kubernetes-service-account-
jwt="<decoded_token_retrieved_earlier>"

بعد ذلك ، نحتاج إلى إنشاء قاعدة وإرفاقها بالدور الجديد. بالنسبة لهذا الجزء ، يمكنك استخدام Consul 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>

سنربط الآن دورنا الجديد بمثيل طريقة المصادقة. لاحظ أن علامة "المحدد" تحدد ما إذا كان طلب تسجيل الدخول سيتلقى هذا الدور. تحقق هنا من خيارات المحدد الأخرى: https://www.consul.io/docs/acl/auth-methods/kubernetes.html#trusted-identity-attributes

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 والتعرف عليها.
اكتب ما يلي في الملف [وصلة]:

###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

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

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

### 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 [رابط]. لاحظ أننا نشير إلى اسم خدمتنا ، قم بتغييره إذا لزم الأمر.

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

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

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

قم بإنشاء عدد قليل من المجلدات الرئيسية بنفس مفتاح المستوى الأعلى (على سبيل المثال. / 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

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

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 "القيمة" ومعرفة أنه يطابق القيمة في custom-ns / test_key في واجهة المستخدم. إذا استخدمت نفس القيمة الواردة سابقًا في هذا الدليل ، فستكون القيمة المشفرة هي IkknbSBpbiB0aGUgY3VzdG9tLW5zIGZvbGRlciEi.

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

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

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" موجودة في مساحة الاسم الافتراضية - لذا فلنستخدمها لربط قاعدة أخرى.
كرر الخطوات السابقة:
أ) قم بإنشاء سياسة متطابقة لبادئة المفتاح "الافتراضي /".
ب) أنشئ دورًا ، أطلق عليه اسم "الدور الافتراضي - ns"
ج) إرفاق السياسة بالدور.
إنشاء قاعدة ملزمة (ممكن فقط من 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)> الرموز المميزة. كما ترى ، لا يوجد سوى "دور مخصص-sa" مرتبط بالرمز المميز الحالي الخاص بنا. تم إنشاء الرمز المميز الذي نستخدمه حاليًا عندما قمنا بتسجيل الدخول وكان هناك رابط واحد فقط للقاعدة ثم المطابق. نحتاج إلى تسجيل الدخول مرة أخرى واستخدام الرمز المميز الجديد.
تأكد من أنه يمكنك قراءة كل من مسارات kv "custom-sa /" و "default /" kv.
!
هذا لأن "poc-ubuntu-custom-sa" يطابق ارتباطات القاعدة "custom-sa" و "default-ns".

اختتام

TTL token mgmt؟

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

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

https://www.consul.io/docs/acl/acl-system.html#acl-tokens
وقت انتهاء الصلاحية - الوقت الذي سيتم إبطال هذا الرمز المميز. (اختياري ؛ مضاف في Consul 1.5.0)
موجود فقط للإنشاء / التحديث اليدوي https://www.consul.io/api/acl/tokens.html#expirationtime

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

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

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