‫Anthos Service Mesh ו-Traffic Director נקראים עכשיו Cloud Service Mesh. מידע נוסף זמין בסקירה הכללית על Cloud Service Mesh.

Google uses AI technology to translate content into your preferred language. AI translations can contain errors.

דוגמה ל-Cloud Service Mesh: ‏ mTLS

ב-Cloud Service Mesh מגרסה 1.5 ואילך, פרוטוקול TLS הדדי אוטומטי (auto mTLS) מופעל כברירת מחדל. עם mTLS אוטומטי, שרת proxy מסוג קובץ עזר חיצוני בצד הלקוח מזהה באופן אוטומטי אם לשרת יש קובץ עזר חיצוני. ה-sidecar של הלקוח שולח mTLS לעומסי עבודה עם sidecar ושולח טקסט רגיל לעומסי עבודה בלי sidecar. עם זאת, שירותים מקבלים תעבורה של טקסט פשוט וגם תעבורה של mTLS. כשמזריקים פרוקסי מסוג sidecar ל-Pods, מומלץ גם להגדיר את השירותים כך שיקבלו רק תנועה של mTLS.

באמצעות Cloud Service Mesh, אתם יכולים לאכוף mTLS מחוץ לקוד האפליקציה, על ידי החלת קובץ YAML יחיד. עם Cloud Service Mesh, אתם יכולים להחיל מדיניות אימות על כל רשת השירותים, על מרחב שמות או על עומס עבודה ספציפי.

mTLS הדדי

עלויות

במסמך הזה משתמשים ברכיבים הבאים של Google Cloud, והשימוש בהם כרוך בתשלום:

כדי להעריך את ההוצאות בהתאם לתחזית השימוש שלכם, אתם יכולים להיעזר במחשבון העלויות.

משתמשים חדשים של Google Cloud ? יכול להיות שאתם זכאים לתקופת ניסיון בחינם.

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

לפני שמתחילים

מוודאים שהחיוב מופעל בפרויקט.
הקצאת Cloud Service Mesh באשכול GKE. יש מגוון שיטות הגדרה נתמכות:
- ‫Fleet API ומישור בקרה מנוהל ב- Google Cloud
- ‫asmcli ורמת בקרה לא מנוהלת בתוך האשכול Google Cloud

משכפלים את המאגר:

git clone https://github.com/GoogleCloudPlatform/anthos-service-mesh-samples
cd anthos-service-mesh-samples

פריסת שער כניסה

מגדירים את ההקשר הנוכחי של kubectl לאשכול:

הערה: אם האשכול הוא אשכול אזורי, צריך להשתמש ב---region במקום ב---zone.
```
gcloud container clusters get-credentials CLUSTER_NAME  \
--project=PROJECT_ID \
--zone=CLUSTER_LOCATION 
```
יוצרים מרחב שמות לשער הכניסה:
```
kubectl create namespace asm-ingress
```
מפעילים את מרחב השמות להחדרה. השלבים תלויים בהטמעה של מישור הבקרה.
מנוהל (TD)
מחילים את תווית ההזרקה שמוגדרת כברירת מחדל על מרחב השמות:
kubectl label namespace asm-ingress \ istio.io/rev- istio-injection=enabled --overwrite
מנוהל (Istiod)
מומלץ: מריצים את הפקודה הבאה כדי להחיל את תווית ברירת המחדל של הזרקה על מרחב השמות:
kubectl label namespace asm-ingress \ istio.io/rev- istio-injection=enabled --overwrite
אם אתם משתמשים קיימים במישור הבקרה המנוהל של Istiod: מומלץ להשתמש בהזרקה שמוגדרת כברירת מחדל, אבל יש תמיכה גם בהזרקה מבוססת-עדכון. פועלים לפי ההוראות הבאות:
1. מריצים את הפקודה הבאה כדי לאתר את ערוצי ההפצה הזמינים:
  
  kubectl -n istio-system get controlplanerevision
  
  הפלט אמור להיראות כך:
  
  NAME AGE asm-managed-rapid 6d7h
  הערה: אם מופיעות שתי גרסאות של מישור הבקרה ברשימה הקודמת, צריך להסיר אחת מהן. אין תמיכה בכמה ערוצי מישור בקרה באשכול.
  
  בפלט, הערך בעמודה NAME הוא תווית הגרסה שתואמת לערוץ ההפצה שזמין לגרסה של Cloud Service Mesh.
2. החלת תווית הגרסה על מרחב השמות:
  
  kubectl label namespace asm-ingress \ istio-injection- istio.io/rev=REVISION_LABEL --overwrite

פורסים את שער לדוגמה במאגר anthos-service-mesh-samples:

kubectl apply -n asm-ingress \
-f docs/shared/asm-ingress-gateway

הפלט אמור להיראות כך:

serviceaccount/asm-ingressgateway configured
service/asm-ingressgateway configured
deployment.apps/asm-ingressgateway configured
gateway.networking.istio.io/asm-ingressgateway configured

פריסה של אפליקציית Online Boutique לדוגמה

אם לא עשיתם זאת, מגדירים את ההקשר הנוכחי של kubectl לאשכול:

  gcloud container clusters get-credentials CLUSTER_NAME  \
    --project=PROJECT_ID \
    --zone=CLUSTER_LOCATION

יוצרים את מרחב השמות של האפליקציה לדוגמה:
```
  kubectl create namespace onlineboutique
```
מתייגים את מרחב השמות onlineboutique כדי להחדיר אוטומטית שרתי proxy של Envoy. פועלים לפי השלבים להפעלת הוספה אוטומטית של קובצי sidecar.
פורסים את האפליקציה לדוגמה, את VirtualService לקצה הקדמי ואת חשבונות השירות לעומסי העבודה. במדריך הזה תפרסו את Online Boutique, אפליקציית הדגמה של מיקרו-שירות.
```
  kubectl apply \
  -n onlineboutique \
  -f docs/shared/online-boutique/virtual-service.yaml
  kubectl apply \
  -n onlineboutique \
  -f docs/shared/online-boutique/service-accounts
```

צפייה בשירותים

צופים בפודים במרחב השמות onlineboutique:

kubectl get pods -n onlineboutique

הפלט אמור להיראות כך:

NAME                                     READY   STATUS    RESTARTS   AGE
adservice-85598d856b-m84m6               2/2     Running   0          2m7s
cartservice-c77f6b866-m67vd              2/2     Running   0          2m8s
checkoutservice-654c47f4b6-hqtqr         2/2     Running   0          2m10s
currencyservice-59bc889674-jhk8z         2/2     Running   0          2m8s
emailservice-5b9fff7cb8-8nqwz            2/2     Running   0          2m10s
frontend-77b88cc7cb-mr4rp                2/2     Running   0          2m9s
loadgenerator-6958f5bc8b-55q7w           2/2     Running   0          2m8s
paymentservice-68dd9755bb-2jmb7          2/2     Running   0          2m9s
productcatalogservice-84f95c95ff-c5kl6   2/2     Running   0          114s
recommendationservice-64dc9dfbc8-xfs2t   2/2     Running   0          2m9s
redis-cart-5b569cd47-cc2qd               2/2     Running   0          2m7s
shippingservice-5488d5b6cb-lfhtt         2/2     Running   0          2m7s

כל הפודים של האפליקציה צריכים לפעול, ובעמודה READY צריך להופיע 2/2. המשמעות היא שפרוקסי קובץ עזר חיצוני Envoy הוזרק לפודים בהצלחה. אם הסמל 2/2 לא מופיע אחרי כמה דקות, אפשר להיעזר במדריך לפתרון בעיות.

מקבלים את כתובת ה-IP החיצונית ומגדירים אותה כמשתנה:

kubectl get services -n asm-ingress
export FRONTEND_IP=$(kubectl --namespace asm-ingress \
get service --output jsonpath='{.items[0].status.loadBalancer.ingress[0].ip}' \
)

הפלט אמור להיראות כך:

NAME                   TYPE           CLUSTER-IP      EXTERNAL-IP   PORT(S)                                      AGE
asm-ingressgateway   LoadBalancer   10.19.247.233   35.239.7.64   80:31380/TCP,443:31390/TCP,31400:31400/TCP   27m

נכנסים לכתובת EXTERNAL-IP בדפדפן האינטרנט. החנות Online Boutique אמורה להופיע בדפדפן.

יצירת פוד TestCurl

יוצרים Pod TestCurl כדי לשלוח תעבורת נתונים של טקסט לא מוצפן לבדיקה.

  apiVersion: v1
  kind: Pod
  metadata:
    name: testcurl
    namespace: default
    annotations:
      sidecar.istio.io/inject: "false"
  spec:
    containers:
    - name: curl
      image: curlimages/curl
      command: ["sleep", "600"]

גישה לבוטיק אונליין

מגדירים את ההקשר הנוכחי של kubectl לקלאסטר שבו פרסתם את Online Boutique:

gcloud container clusters get-credentials CLUSTER_NAME  \
    --project=PROJECT_ID \
    --zone=CLUSTER_LOCATION

מציגים את רשימת השירותים במרחב השמות frontend:
```
kubectl get services -n frontend
```
שימו לב ש-frontend-external הוא LoadBalancer, ויש לו כתובת IP חיצונית. האפליקציה לדוגמה כוללת שירות שהוא מאזן עומסים, כך שאפשר לפרוס אותה ב-GKE בלי Cloud Service Mesh.
נכנסים לאפליקציה בדפדפן באמצעות כתובת ה-IP החיצונית של שירות frontend-external:
```
http://FRONTEND_EXTERNAL_IP/
```
Cloud Service Mesh מאפשר לכם לפרוס שער כניסה. אפשר גם לגשת ל-Online Boutique באמצעות כתובת ה-IP החיצונית של שער הכניסה. מקבלים את כתובת ה-IP החיצונית של השער. מחליפים את ה-placeholders בפרטים הבאים:
- ‫GATEWAY_SERVICE_NAME : השם של שירות שער הכניסה. אם פרסתם את שער הדוגמה ללא שינוי, או אם פרסתם את שער הכניסה שמוגדר כברירת מחדל, השם הוא istio-ingressgateway.
- ‫GATEWAY_NAMESPACE: מרחב השמות שבו פרסתם את שער הכניסה. אם פרסתם את שער הכניסה שמוגדר כברירת מחדל, מרחב השמות הוא istio-system.
```
kubectl get service GATEWAY_NAME -n GATEWAY_NAMESPACE
```
פותחים כרטיסייה נוספת בדפדפן ועוברים לאפליקציה באמצעות כתובת ה-IP החיצונית של שער הכניסה:
```
http://INGRESS_GATEWAY_EXTERNAL_IP/
```
מריצים את הפקודה הבאה כדי curl את שירות frontend באמצעות HTTP רגיל מ-Pod אחר. מכיוון שהשירותים נמצאים במרחבי שמות שונים, צריך להשתמש בפקודת curl כדי להשיג את שם ה-DNS של שירות frontend.
```
kubectl debug --image istio/base --target istio-proxy -it \
  $(kubectl get pod -l app=productcatalogservice -n product-catalog -o jsonpath={.items..metadata.name}) \
  -n product-catalog -- \
  curl http://frontend.frontend.svc.cluster.local:80/ -o /dev/null -s -w '%{http_code}\n'
```
הבקשה מצליחה עם הסטטוס 200, כי כברירת מחדל, גם תעבורת TLS וגם תעבורת טקסט רגיל מתקבלות.

הפעלת mTLS לכל מרחב שמות

כדי לאכוף mTLS, צריך להחיל PeerAuthentication מדיניות עם kubectl.

שומרים את מדיניות האימות הבאה בשם mtls-namespace.yaml.
```
cat <<EOF > mtls-namespace.yaml
apiVersion: "security.istio.io/v1beta1"
kind: "PeerAuthentication"
metadata:
  name: "namespace-policy"
spec:
  mtls:
    mode: STRICT
EOF
```
השורה mode: STRICT בקובץ ה-YAML מגדירה את השירותים כך שהם יקבלו רק mTLS. כברירת מחדל, הערך של mode הוא PERMISSIVE, שמגדיר את השירותים לקבל גם טקסט לא מוצפן וגם mTLS.

מחילים את מדיניות האימות כדי להגדיר את כל השירותים של Online Boutique כך שיקבלו רק mTLS:

for ns in ad cart checkout currency email frontend loadgenerator \
     payment product-catalog recommendation shipping; do
kubectl apply -n $ns -f mtls-namespace.yaml
done

הפלט אמור להיראות כך:

peerauthentication.security.istio.io/namespace-policy created
peerauthentication.security.istio.io/namespace-policy created
peerauthentication.security.istio.io/namespace-policy created
peerauthentication.security.istio.io/namespace-policy created
peerauthentication.security.istio.io/namespace-policy created
peerauthentication.security.istio.io/namespace-policy created
peerauthentication.security.istio.io/namespace-policy created
peerauthentication.security.istio.io/namespace-policy created
peerauthentication.security.istio.io/namespace-policy created
peerauthentication.security.istio.io/namespace-policy created
peerauthentication.security.istio.io/namespace-policy created

עוברים לכרטיסייה בדפדפן שדרכה ניגשים לחנות הווירטואלית באמצעות כתובת ה-IP החיצונית של שירות frontend-external:
```
http://FRONTEND_EXTERNAL_IP/
```
יש לרענן את הדף. הדפדפן מציג את השגיאה הבאה:

רענון הדף גורם לשליחת טקסט רגיל לשירות frontend. בגלל STRICTמדיניות האימות, שרת ה-proxy מסוג קובץ עזר חיצוני חוסם את הבקשה לשירות.
עוברים לכרטיסייה בדפדפן שדרכה ניגשים לחנות הווירטואלית באמצעות כתובת ה-IP החיצונית של istio-ingressgateway, ומרעננים את הדף. הדף מוצג בהצלחה. כשניגשים ל-Online Boutique באמצעות שער הכניסה, הבקשה עוברת בנתיב הבא:

תהליך האימות של mTLS:
1. הדפדפן שולח בקשת HTTP בטקסט לא מוצפן לשרת.
2. הבקשה מנותבת דרך קונטיינר של שרת proxy של שער כניסה.
3. שרת ה-proxy של שער הכניסה מבצע לחיצת יד בפרוטוקול TLS עם שרת ה-proxy בצד השרת (שירות קצה קדמי בדוגמה הזו). הלחיצת יד הזו כוללת החלפה של אישורים. האישורים האלה נטענים מראש למאגרי ה-proxy על ידי Cloud Service Mesh.
4. שרת ה-proxy של שער הכניסה מבצע בדיקה מאובטחת של השמות באישור של השרת, כדי לוודא שזהות מורשית מפעילה את השרת.
5. שערי הכניסה ושרתי ה-proxy יוצרים חיבור TLS הדדי, ושרת ה-proxy מעביר את הבקשה לקונטיינר של אפליקציית השרת (השירות בחזית).
מריצים את הפקודה הבאה כדי curl את שירות frontend באמצעות HTTP רגיל מ-Pod אחר.
```
kubectl exec testcurl -n default -- curl \
  http://frontend.frontend.svc.cluster.local:80/ -o /dev/null -s -w '%{http_code}\n'
```
הבקשה שלך נכשלת כי אנחנו שולחים תעבורת נתונים בטקסט לא מוצפן מעומס עבודה ללא sidecar, שבו מוחלת מדיניות STRICT peerAuthentication.

חיפוש ומחיקה של מדיניות אימות

כדי לראות רשימה של כל כללי המדיניות של PeerAuthentication ב-Service Mesh:

kubectl get peerauthentication --all-namespaces

הפלט אמור להיראות כך:

NAMESPACE         NAME               MODE     AGE
ad                namespace-policy   STRICT   17m
cart              namespace-policy   STRICT   17m
checkout          namespace-policy   STRICT   17m
currency          namespace-policy   STRICT   17m
email             namespace-policy   STRICT   17m
frontend          namespace-policy   STRICT   17m
loadgenerator     namespace-policy   STRICT   17m
payment           namespace-policy   STRICT   17m
product-catalog   namespace-policy   STRICT   17m
recommendation    namespace-policy   STRICT   17m
shipping          namespace-policy   STRICT   17m

מוחקים את מדיניות האימות מכל מרחבי השמות של Online Boutique:

for ns in ad cart checkout currency email frontend loadgenerator payment \
  product-catalog recommendation shipping; do
    kubectl delete peerauthentication -n $ns namespace-policy
done;

הפלט אמור להיראות כך:

peerauthentication.security.istio.io "namespace-policy" deleted
peerauthentication.security.istio.io "namespace-policy" deleted
peerauthentication.security.istio.io "namespace-policy" deleted
peerauthentication.security.istio.io "namespace-policy" deleted
peerauthentication.security.istio.io "namespace-policy" deleted
peerauthentication.security.istio.io "namespace-policy" deleted
peerauthentication.security.istio.io "namespace-policy" deleted
peerauthentication.security.istio.io "namespace-policy" deleted
peerauthentication.security.istio.io "namespace-policy" deleted
peerauthentication.security.istio.io "namespace-policy" deleted
peerauthentication.security.istio.io "namespace-policy" deleted

ניגשים אל Online Boutique באמצעות כתובת ה-IP החיצונית של שירות frontend-external ומרעננים את הדף. הדף מוצג כמו שציפיתם.

מריצים את הפקודה הבאה כדי curl את שירות frontend באמצעות HTTP רגיל מ-Pod אחר.

kubectl debug --image istio/base --target istio-proxy -it \
  $(kubectl get pod -l app=productcatalogservice -n product-catalog -o jsonpath={.items..metadata.name}) \
  -n product-catalog -- \
  curl http://frontend.frontend.svc.cluster.local:80/ -o /dev/null -s -w '%{http_code}\n'

הבקשה מצליחה עם הסטטוס 200, כי כברירת מחדל, גם תעבורת TLS וגם תעבורת טקסט רגיל מתקבלות.

אם מרעננים את הדף במסוף שבו מוצגת רשימת Workloads, הסטטוס של mTLS יהיה Permissive. Google Cloud

הפעלת פרוטוקול TLS הדדי לכל עומס עבודה

כדי להגדיר מדיניות PeerAuthentication עבור עומס עבודה ספציפי, צריך להגדיר את הקטע selector ולציין את התוויות שתואמות לעומס העבודה הרצוי. עם זאת, Cloud Service Mesh לא יכול לצבור מדיניות ברמת עומס העבודה לתעבורת mTLS יוצאת לשירות. כדי לנהל את ההתנהגות הזו, צריך להגדיר כלל יעד.

החלת מדיניות אימות על עומס עבודה ספציפי. שימו לב איך המדיניות הבאה משתמשת בתוויות ובבוררים כדי לטרגט את הפריסה הספציפית frontend.

cat <<EOF | kubectl apply -n frontend -f -
apiVersion: "security.istio.io/v1beta1"
kind: "PeerAuthentication"
metadata:
  name: "frontend"
  namespace: "frontend"
spec:
  selector:
    matchLabels:
      app: frontend
  mtls:
    mode: STRICT
EOF

הפלט אמור להיראות כך:

peerauthentication.security.istio.io/frontend created

מגדירים כלל ניתוב תואם.

cat <<EOF | kubectl apply -n frontend -f -
apiVersion: "networking.istio.io/v1alpha3"
kind: "DestinationRule"
metadata:
  name: "frontend"
spec:
  host: "frontend.demo.svc.cluster.local"
  trafficPolicy:
    tls:
      mode: ISTIO_MUTUAL
EOF

הפלט אמור להיראות כך:

destinationrule.networking.istio.io/frontend created

ניגשים אל Online Boutique באמצעות כתובת ה-IP החיצונית של שירות frontend-external ומרעננים את הדף. הדף לא מוצג כי frontend service מוגדר ל-STRICT mTLS, והבקשה נחסמת על ידי פרוקסי ה-sidecar.
מריצים את הפקודה הבאה כדי curl את שירות frontend באמצעות HTTP רגיל מ-Pod אחר.
```
kubectl exec testcurl -n default -- curl \
  http://frontend.frontend.svc.cluster.local:80/ -o /dev/null -s -w '%{http_code}\n'
```
הבקשה שלך נכשלת כי אנחנו שולחים תעבורת נתונים בטקסט לא מוצפן מעומס עבודה ללא sidecar, שבו מוחלת מדיניות STRICT peerAuthentication.

מחיקת מדיניות האימות:

kubectl delete peerauthentication -n frontend frontend

הפלט אמור להיראות כך:

peerauthentication.security.istio.io "frontend" deleted

מחיקת כלל היעד:

kubectl delete destinationrule -n frontend frontend

הפלט אמור להיראות כך:

destinationrule.networking.istio.io "frontend" deleted

אכיפת mTLS בכל הרשת

כדי למנוע מכל השירותים ברשת לקבל תעבורת נתונים בטקסט לא מוצפן, צריך להגדיר מדיניות PeerAuthentication ברמת הרשת עם מצב mTLS שמוגדר ל-STRICT. למדיניות PeerAuthentication ברמת הרשת לא יכול להיות בורר, והיא חייבת להיות מוחלת במרחב השמות הבסיסי, istio-system. כשפורסים את המדיניות, מישור הבקרה מקצה באופן אוטומטי אישורי TLS כדי שעומסי העבודה יוכלו לבצע אימות אחד של השני.

אכיפת mTLS בכל הרשת:

kubectl apply -f - <<EOF
apiVersion: "security.istio.io/v1beta1"
kind: "PeerAuthentication"
metadata:
  name: "mesh-wide"
  namespace: "istio-system"
spec:
  mtls:
    mode: STRICT
EOF

הפלט אמור להיראות כך:

peerauthentication.security.istio.io/mesh-wide created

ניגשים אל Online Boutique באמצעות כתובת ה-IP החיצונית של שירות frontend-external ומרעננים את הדף. הדף לא מוצג.
מריצים את הפקודה הבאה כדי curl את שירות frontend באמצעות HTTP רגיל מ-Pod אחר.
```
kubectl exec testcurl -n default -- curl \
  http://frontend.frontend.svc.cluster.local:80/ -o /dev/null -s -w '%{http_code}\n'
```
הבקשה שלך נכשלת כי אנחנו שולחים תעבורת נתונים בטקסט לא מוצפן מעומס עבודה ללא sidecar, שבו מוחלת מדיניות STRICT peerAuthentication.

מחיקת המדיניות mesh-wide:

kubectl delete peerauthentication -n istio-system mesh-wide

הפלט אמור להיראות כך:

peerauthentication.security.istio.io "mesh-wide" deleted

הסרת המשאבים

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

כדי למנוע חיובים נוספים, צריך למחוק את האשכול:

gcloud container clusters delete  CLUSTER_NAME  \
    --project=PROJECT_ID \
    --zone=CLUSTER_LOCATION

אם רוצים לשמור את האשכול ולהסיר את הדוגמה Online Boutique:

מוחקים את מרחבי השמות של האפליקציה:

  kubectl delete -f online-boutique/kubernetes-manifests/namespaces

הפלט אמור להיראות כך:

namespace "ad" deleted
namespace "cart" deleted
namespace "checkout" deleted
namespace "currency" deleted
namespace "email" deleted
namespace "frontend" deleted
namespace "loadgenerator" deleted
namespace "payment" deleted
namespace "product-catalog" deleted
namespace "recommendation" deleted
namespace "shipping" deleted

מחיקת רשומות השירות:

  kubectl delete -f online-boutique/istio-manifests/allow-egress-googleapis.yaml

הפלט אמור להיראות כך:

serviceentry.networking.istio.io "allow-egress-googleapis" deleted
serviceentry.networking.istio.io "allow-egress-google-metadata" deleted

המאמרים הבאים

מדריך כללי להגדרת מדיניות PeerAuthentication זמין במאמר הגדרת אבטחת תעבורה.

דוגמה ל-Cloud Service Mesh: ‏ mTLS קל לארגן דפים בעזרת אוספים אפשר לשמור ולסווג תוכן על סמך ההעדפות שלך.

עלויות

לפני שמתחילים

פריסת שער כניסה

מנוהל (TD)

מנוהל (Istiod)

פריסה של אפליקציית Online Boutique לדוגמה

צפייה בשירותים

יצירת פוד TestCurl

גישה לבוטיק אונליין

הפעלת mTLS לכל מרחב שמות

חיפוש ומחיקה של מדיניות אימות

הפעלת פרוטוקול TLS הדדי לכל עומס עבודה

אכיפת mTLS בכל הרשת

הסרת המשאבים

המאמרים הבאים

דוגמה ל-Cloud Service Mesh: ‏ mTLS