היכרות עם הרשאת Kubernetes של Hashicorp Consult

נכון, אחרי השחרור Hashicorp Consul 1.5.0 בתחילת מאי 2019, ב-Consul תוכל לאשר יישומים ושירותים הפועלים ב-Kubernetes באופן מקורי.

במדריך זה ניצור צעד אחר צעד POC (הוכחת קונספט, PoC) המדגימה תכונה חדשה זו. מצופה ממך ידע בסיסי ב- Kubernetes והקונסול של Hashicorp. אמנם תוכל להשתמש בכל פלטפורמת ענן או סביבה מקומית, אבל במדריך זה נשתמש בפלטפורמת הענן של גוגל.

סקירה

אם נלך ל עיין בתיעוד על שיטת ההרשאה שלו, נקבל סקירה מהירה של מטרתו ומקרה השימוש שלו, כמו גם כמה פרטים טכניים וסקירה כללית של ההיגיון. אני ממליץ בחום לקרוא אותו לפחות פעם אחת לפני שתמשיך, כי עכשיו אסביר ואלעס את הכל.

תרשים 1: סקירה רשמית של שיטת אישור הקונסול

בואו נסתכל פנימה תיעוד עבור שיטת הרשאה ספציפית של Kubernetes.

בטח, יש שם מידע שימושי, אבל אין מדריך איך להשתמש בכל זה בפועל. לכן, כמו כל אדם שפוי, אתה סורק באינטרנט כדי לקבל הדרכה. ואז... אתה נכשל. זה קורה. בוא נתקן את זה.

לפני שנעבור ליצירת ה-POC שלנו, הבה נחזור לסקירה הכללית של שיטות ההרשאה של קונסול (תרשים 1) ונחדד אותה בהקשר של Kubernetes.

אדריכלות

במדריך זה, ניצור שרת Consul על מחשב נפרד שיתקשר עם אשכול Kubernetes עם לקוח Consul מותקן. לאחר מכן ניצור את אפליקציית הדמה שלנו בפוד ונשתמש בשיטת ההרשאה המוגדרת שלנו כדי לקרוא ממאגר המפתח/ערך של Consul.

התרשים שלהלן מפרט את הארכיטקטורה שאנו יוצרים במדריך זה, כמו גם את ההיגיון מאחורי שיטת ההרשאה, שתוסבר בהמשך.

תרשים 2: סקירה כללית של שיטת ההרשאה של Kubernetes

הערה מהירה: שרת הקונסול לא צריך לחיות מחוץ לאשכול Kubernetes כדי שזה יעבוד. אבל כן, הוא יכול לעשות את זה ככה וככה.

אז, אם לוקחים את דיאגרמת סקירת הקונסול (תרשים 1) ומחילים עליו את Kubernetes, אנו מקבלים את הדיאגרמה שלמעלה (תרשים 2), וההיגיון כאן הוא כדלקמן:

1. לכל פוד יצורף חשבון שירות המכיל אסימון JWT שנוצר ומוכר על ידי Kubernetes. אסימון זה מוכנס גם לתרמיל כברירת מחדל.
2. האפליקציה או השירות שלנו בתוך הפוד יוזם פקודת התחברות ללקוח הקונסול שלנו. בקשת ההתחברות תכלול גם את האסימון והשם שלנו נוצר במיוחד שיטת הרשאה (סוג Kubernetes). שלב מס' 2 זה מתאים לשלב 1 בתרשים הקונסול (סכמה 1).
3. לקוח הקונסול שלנו יעביר את הבקשה הזו לשרת הקונסול שלנו.
4. קֶסֶם! זה המקום שבו שרת ה-Consul מוודא את האותנטיות של הבקשה, אוסף מידע על זהות הבקשה ומשווה אותו לכל כללים מוגדרים מראש הקשורים אליו. להלן תרשים נוסף כדי להמחיש זאת. שלב זה מתאים לשלבים 3, 4 ו-5 בתרשים סקירת הקונסול (תרשים 1).
5. שרת ה-Consul שלנו מייצר אסימון קונסול עם הרשאות בהתאם לכללי שיטת ההרשאה שצוינו (שהגדרנו) לגבי זהות המבקש. לאחר מכן הוא ישלח את האסימון בחזרה. זה מתאים לשלב 6 בתרשים הקונסול (תרשים 1).
6. לקוח הקונסול שלנו מעביר את האסימון לאפליקציה או לשירות המבקשים.

האפליקציה או השירות שלנו יכולים כעת להשתמש באסימון הקונסול הזה כדי לתקשר עם נתוני הקונסול שלנו, כפי שנקבע על פי ההרשאות של האסימון.

הקסם מתגלה!

לאלו מכם שלא שמחים רק עם ארנב מתוך כובע ורוצים לדעת איך זה עובד... הרשו לי "להראות לכם כמה עמוק חור הארנב".

כפי שהוזכר קודם לכן, שלב ה"קסם" שלנו (איור 2: שלב 4) הוא המקום שבו שרת הקונסול מאמת את הבקשה, אוסף מידע על הבקשה ומשווה אותו לכללים מוגדרים מראש הקשורים אליו. שלב זה מתאים לשלבים 3, 4 ו-5 בתרשים סקירת הקונסול (תרשים 1). להלן תרשים (תרשים 3), שמטרתו להראות בבירור מה קורה בפועל מתחת למכסת המנוע שיטת הרשאה ספציפית של Kubernetes.

תרשים 3: הקסם מתגלה!

1. כנקודת התחלה, לקוח הקונסול שלנו מעביר את בקשת הכניסה לשרת הקונסול שלנו עם אסימון חשבון Kubernetes ושם מופע ספציפי של שיטת ההרשאה שנוצרה קודם לכן. שלב זה מתאים לשלב 3 בהסבר המעגל הקודם.
2. כעת שרת הקונסול (או המנהיג) צריך לאמת את האותנטיות של האסימון שהתקבל. לכן, היא תתייעץ עם אשכול Kubernetes (דרך הלקוח של Consul) ועם ההרשאות המתאימות, נברר אם האסימון אמיתי ולמי הוא שייך.
3. לאחר מכן הבקשה המאומתת מוחזרת למנהיג הקונסול, ושרת הקונסול מחפש את מופע שיטת ההרשאה עם השם שצוין מבקשת הכניסה (וסוג Kubernetes).
4. מנהיג הקונסול מזהה את מופע שיטת ההרשאה שצוין (אם נמצא) וקורא את מערכת הכללים המחייבים המצורפים לו. לאחר מכן הוא קורא את הכללים הללו ומשווה אותם לתכונות הזהות המאומתות.
5. טה דה! נעבור לשלב 5 בהסבר המעגל הקודם.

הפעל את Consul-server על מכונה וירטואלית רגילה

מעתה ואילך, אני בעיקר אתן הוראות כיצד ליצור את ה-POC הזה, לעתים קרובות בתבליטים, ללא הסברים מלאים למשפטים. כמו כן, כפי שצוין קודם לכן, אשתמש ב-GCP כדי ליצור את כל התשתית, אבל אתה יכול ליצור את אותה תשתית בכל מקום אחר.

• הפעל את המכונה הוירטואלית (מופע/שרת).

• צור כלל עבור חומת האש (קבוצת אבטחה ב-AWS):
• אני אוהב להקצות את אותו שם מכונה גם לכלל וגם לתג הרשת, במקרה הזה "skywiz-consul-server-poc".
• מצא את כתובת ה-IP של המחשב המקומי שלך והוסף אותה לרשימת כתובות ה-IP של המקור כדי שנוכל לגשת לממשק המשתמש (UI).
• פתח את יציאה 8500 עבור ממשק המשתמש. לחץ על צור. אנו נשנה את חומת האש הזו שוב בקרוב [קשר].
• הוסף כלל חומת אש למופע. חזור ללוח המחוונים של VM ב-Consul Server והוסף "skywiz-consul-server-poc" לשדה תגי הרשת. לחץ על שמור.

• התקן את Consul על מכונה וירטואלית, בדוק כאן. זכור שאתה צריך גירסת Consul ≥ 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

• למדריך מפורט יותר על התקנת 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

• אתה אמור לראות חבורה של פלט ולסיים עם "... עדכון חסום על ידי ACLs."
• מצא את כתובת ה-IP החיצונית של שרת ה-Consul ופתח דפדפן עם כתובת ה-IP הזו ביציאה 8500. ודא שה-UI נפתח.
• נסה להוסיף צמד מפתח/ערך. חייבת להיות טעות. הסיבה לכך היא שהעמסנו את שרת ה-Consul עם ACL והשבתנו את כל הכללים.
• חזור למעטפת שלך בשרת הקונסול והתחל את התהליך ברקע או בדרך אחרת כדי להפעיל אותו והזן את הדברים הבאים:

consul acl bootstrap

• מצא את הערך "SecretID" וחזור לממשק המשתמש. בלשונית ACL, הזן את המזהה הסודי של האסימון שזה עתה העתקת. העתק את SecretID למקום אחר, נזדקק לו מאוחר יותר.
• כעת הוסף צמד מפתח/ערך. עבור POC זה, הוסף את הדברים הבאים: מפתח: "custom-ns/test_key", ערך: "אני בתיקייה Custom-ns!"

השקת אשכול Kubernetes עבור האפליקציה שלנו עם לקוח הקונסול כ-Daemonset

• צור אשכול K8s (Kubernetes). אנו ניצור אותו באותו אזור כמו השרת לגישה מהירה יותר, וכך נוכל להשתמש באותה רשת משנה כדי להתחבר בקלות לכתובות IP פנימיות. אנחנו נקרא לזה "skywiz-app-with-consul-client-poc".

• כהערה צדדית, הנה מדריך טוב שנתקלתי בו בזמן הקמת אשכול POC Consul עם 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 Address Range" הממוקם בלוח המחוונים של האשכול ופנה אל כלל חומת האש "skywiz-consul-server-poc" שלנו.
• הוסף את טווח הכתובות של הפוד לרשימת כתובות ה-IP והיציאות הפתוחות 8301 ו-8300.

• עבור אל ה-Consul UI ולאחר מספר דקות תראה את האשכול שלנו מופיע בלשונית הצמתים.

הגדרת שיטת הרשאה על ידי שילוב של Consul עם Kubernetes

• חזור למעטפת השרת של Consul וייצא את האסימון ששמרת קודם לכן:

export CONSUL_HTTP_TOKEN=<SecretID>

• נזדקק למידע מאשכול Kubernetes שלנו כדי ליצור את שיטת האימות:
• kubernetes-host

kubectl get endpoints | grep kubernetes

• kubernetes-service-account-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

מתחבר ל-Consul Client

• כפי שצוין כאןישנן מספר אפשרויות לחיבור ל-demonset, אך נעבור לפתרון הפשוט הבא:
• החל את הקובץ הבא [קשר].

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

• לאחר מכן השתמש בפקודה המובנית הבאה כדי ליצור מפת תצורה [קשר]. שימו לב שאנו מתייחסים לשם השירות שלנו, החליפו אותו במידת הצורך.

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

• לאחר שהמיכל פועל, עבור לשם והתקן את curl.

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

• אתה יכול לפענח את "Value" ב-base64 ולראות שהוא תואם את הערך ב-custom-ns/test_key בממשק המשתמש. אם השתמשת באותו ערך לעיל במדריך זה, הערך המקודד שלך יהיה IkknbSBpbiB0aGUgY3VzdG9tLW5zIGZvbGRlciEi.

בדיקת חשבון שירות משתמש:

• צור חשבון שירות מותאם אישית באמצעות הפקודה הבאה [קשר].

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/".
ב) צור תפקיד, קרא לו "תפקיד מותאם אישית"
ג) צרף את המדיניות לתפקיד.

• צור Rule-Binding (אפשר רק מ-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-ns-role"
  ג) צרף את המדיניות לתפקיד.
• צור כריכת כללים (אפשרי רק מ-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 > Tokens. כפי שאתה יכול לראות, לטוקן הנוכחי שלנו יש רק "תפקיד מותאם אישית" אחד מחובר אליו. האסימון בו אנו משתמשים כעת נוצר כשנכנסנו והייתה רק מחייב כלל אחד שהתאים אז. עלינו להתחבר שוב ולהשתמש באסימון החדש.
• ודא שאתה יכול לקרוא גם מהנתיבים "custom-sa/" וגם "ברירת מחדל/" 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.

עד אז, מומלץ להשתמש בנקודת קצה ליציאה בלוגיקה שלך.

• https://www.consul.io/api/acl/acl.html#logout-from-auth-method
• https://www.consul.io/docs/acl/acl-auth-methods.html#overall-login-process

קרא גם מאמרים אחרים בבלוג שלנו:

• למה הובילה ההגירה מ-ClickHouse ללא הרשאה ל-ClickHouse עם הרשאה?
• כיצד להפעיל צינורות מרובים באמצעות GitLab CI/CD
• שלושה טריקים פשוטים לכווץ תמונות Docker
• Traefik כבקר Ingress עבור K8S
• גיבוי של מספר רב של פרויקטי אינטרנט הטרוגניים
• בוט טלגרם עבור Redmine. איך לפשט את החיים לעצמך ולאחרים

מקור: www.habr.com