‫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.

הגדרת Certificate Authority Service ל-Managed Cloud Service Mesh

במדריך הזה מוסבר איך להגדיר את Certificate Authority Service (שירות רשות האישורים) ל-Cloud Service Mesh מנוהל. מידע על Cloud Service Mesh בתוך אשכול זמין במאמר בנושא התקנת תכונות ברירת מחדל ושירות רשות אישורים (CA).

בנוסף לרשות האישורים של Cloud Service Mesh, אפשר להגדיר את Cloud Service Mesh כך שישתמש בCertificate Authority Service. במדריך הזה מוצגת הזדמנות לשילוב עם CA Service, שמומלץ לתרחישי השימוש הבאים:

אם אתם צריכים רשויות אישורים שונות כדי לחתום על אישורים של עומסי עבודה באשכולות שונים.
אם אתם צריכים לגבות את מפתחות החתימה ב-Cloud HSM.
אם אתם פועלים בתחום עם רגולציה מחמירה וכפופים לדרישות תאימות.
אם רוצים לשרשר את רשות האישורים של Cloud Service Mesh לאישור בסיס ארגוני מותאם אישית כדי לחתום על אישורים של עומסי עבודה.

העלות של רשות האישורים של Cloud Service Mesh כלולה בתמחור של Cloud Service Mesh. שירות ה-CA לא נכלל במחיר הבסיסי של Cloud Service Mesh, והוא מחויב בנפרד. בנוסף, שירות CA מגיע עם SLA מפורש, אבל רשות האישורים של Cloud Service Mesh לא מגיעה עם SLA.

דרישות מוקדמות

כנקודת התחלה, במדריך הזה אנחנו מניחים שיש לכם:

פרויקט בענן
חשבון לחיוב ב-Cloud
קיבלתם את ההרשאות הנדרשות כדי להקצות את Cloud Service Mesh
הפעלתם איחוד זהויות של עומסי עבודה ל-GKE באשכולות ובמאגרי הצמתים.
אחד או יותר אשכולות עם גרסה נתמכת של GKE, באחד מהאזורים הנתמכים. כדי ללמוד איך ליצור אשכול Google Kubernetes Engine עם Cloud Service Mesh מופעל, אפשר לעיין בהגדרות לכל אשכול במסמך הקצאת מישור בקרה מנוהל של Cloud Service Mesh ב-Google Kubernetes Engine. הפעלת Cloud Service Mesh מנוהל כהגדרת ברירת מחדל לצי ורישום אשכולות לצי במהלך יצירת האשכולות תומכת רק ב-Mesh CA. צריך להגדיר את Cloud Service Mesh לכל אשכול ולהפעיל את שירות ה-CA באופן מפורש לכל אשכול.

דרישות

מפעילים את ממשק ה-API הנדרש בפרויקט שבו יוגדר מאגר רשויות האישורים.

 gcloud services enable privateca.googleapis.com \
      --project=CA_PROJECT_ID

הגדרת שירות רשות האישורים

כדי להימנע מבעיות של השהיה מוגזמת או מהפסקות זמניות בשירות פוטנציאליות בין אזורים, צריך ליצור את מאגר אישורים ברמה DevOps ובאותו אזור כמו האשכול שהוא משרת. מידע נוסף זמין במאמר בנושא רמות שירות שעברו אופטימיזציה לעומסי עבודה.
יוצרים את ה-CA כדי שיהיה לפחות רשות אישורים פעילה אחת במאגר ה-CA באותו פרויקט כמו אשכול GKE. שימוש ב-CA משני לחתימה על אישורים של עומסי עבודה ב-Cloud Service Mesh. רושמים את מאגר רשויות האישורים שמתאים לרשות האישורים המשנית.
אם רוצים שהמאגר ישמש רק להנפקת אישורים לעומסי עבודה של Cloud Service Mesh, צריך להגדיר את מדיניות ההנפקה הבאה למאגר CA:
policy.yaml
```
baselineValues:
  keyUsage:
    baseKeyUsage:
      digitalSignature: true
      keyEncipherment: true
    extendedKeyUsage:
      serverAuth: true
      clientAuth: true
  caOptions:
    isCa: false
identityConstraints:
  allowSubjectPassthrough: false
  allowSubjectAltNamesPassthrough: true
  celExpression:
    expression: subject_alt_names.all(san, san.type == URI && san.value.startsWith("spiffe://PROJECT_ID.svc.id.goog/ns/") )
```
הערה: השיטה המומלצת לרשתות מרובות אשכולות היא להגדיר מאגר אחד של רשויות אישורים משניות לכל אזור אשכול ייחודי. כל מאגרי האישורים המשניים צריכים להיות מקושרים לאותו מאגר אישורים ראשי.
כדי לעדכן את מדיניות הנפקת האישורים של מאגר רשויות האישורים, משתמשים בפקודה הבאה:
```
gcloud privateca pools update CA_POOL --location ca_region --issuance-policy policy.yaml
```
מידע על הגדרת מדיניות במאגר זמין במאמר שימוש במדיניות הנפקת אישורים.
אם אתם משתמשים בתבנית אישור, צריך להגדיר אותה עכשיו. מידע נוסף זמין במדריך CA Service בנושא אישורים לזיהוי עומסי עבודה. מוודאים שתבנית האישור נוצרה באותו אזור שבו נוצר מאגר רשויות האישורים. אם יש כמה אזורים למאגרי רשויות אישורים, צריך ליצור תבנית אישור לכל אזור.

תפקידים שנדרשים לשימוש בשירות CA

כדי להשתמש בשילוב הזה, כל עומסי העבודה ב-Cloud Service Mesh צריכים את תפקידי ה-IAM הבאים. צריך להחיל את הקישורים האלה לתפקידים באופן מפורש על עומסי עבודה של Cloud Service Mesh:

    WORKLOAD_IDENTITY="FLEET_PROJECT_ID.svc.id.goog:/allAuthenticatedUsers/"

    gcloud privateca pools add-iam-policy-binding CA_POOL \
      --project FLEET_PROJECT_ID \
      --location ca_region \
      --member "group:${WORKLOAD_IDENTITY}" \
      --role "roles/privateca.workloadCertificateRequester"

    gcloud privateca pools add-iam-policy-binding CA_POOL \
      --project FLEET_PROJECT_ID \
      --location ca_region \
      --member "group:${WORKLOAD_IDENTITY}" \
      --role "roles/privateca.auditor"

אם משתמשים בתבניות של אישורים:

    gcloud privateca templates add-iam-policy-binding CERT_TEMPLATE_ID \
        --member "group:${WORKLOAD_IDENTITY}" \
        --role "roles/privateca.templateUser"

מגבלות

מגדירים ובוחרים את ה-CA לפני הקצאת מישור הבקרה של Cloud Service Mesh. אין תמיכה בשינוי של רשות האישורים.

הגדרת Cloud Service Mesh מנוהל לשימוש בשירות CA

מוודאים שמרחב השמות istio-system קיים, או יוצרים אותו אם הוא חסר:
```
  kubectl create ns istio-system
```
בודקים אם ה-configmap‏ asm-options קיים במרחב השמות istio-system:
```
  kubectl get configmap/asm-options -n istio-system
```

יוצרים את ה-configmap אם הוא לא קיים:

  kubectl create configmap -n istio-system asm-options

מבצעים תיקון של ה-configmap כדי להוסיף הגדרת CAS:

  kubectl patch configmap/asm-options -n istio-system --type merge \
  -p '{"data":{"ASM_OPTS": "CA=PRIVATECA;CAAddr=projects/CA_PROJECT_ID/locations/ca_region/caPools/CA_POOL"}}'

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

  kubectl patch configmap/asm-options -n istio-system --type merge \
  -p '{"data":{"ASM_OPTS": "CA=PRIVATECA;CAAddr=projects/CA_PROJECT_ID/locations/ca_region/caPools/CA_POOL:projects/PROJECT_ID/locations/ca_region/certificateTemplates/CERT_TEMPLATE_ID"}}'

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