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

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

בניגוד לרשות אישורי ברירת המחדל של הרשת, ל-CA Service יש הסכם SLA מפורש והחיוב עליו מתבצע בנפרד. מכיוון ש-CA Service לא נתמך בהגדרת ברירת המחדל של Fleet במהלך יצירת האשכול, צריך להגדיר את Cloud Service Mesh לכל אשכול. למידע על מישורי בקרה בתוך האשכול, קראו את המאמר התקנת תכונות ברירת המחדל ושירות רשות האישורים (CA).

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

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

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

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

דרישות

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

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

הגדרת שירות CA

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

3. אם הוא מיועד רק לאישורי שירות לעומסי עבודה של 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/") )
   

   הערה: השיטה המומלצת לרשתות מרובות אשכולות היא להגדיר מאגר רשויות להנפקת אישורים (CA) משני אחד לכל אזור ייחודי של אשכולות. כל מאגרי רשויות האישורים המשניות צריכים להיות משורשרים לאותו מאגר של רשות אישורים בסיסית.

4. כדי לעדכן את מדיניות ההנפקה של מאגר ה-CA, משתמשים בפקודה הבאה:

   gcloud privateca pools update CA_POOL --location ca_region --issuance-policy policy.yaml
   

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

5. אם אתם משתמשים בתבנית אישור, צריך להגדיר אותה עכשיו. למידע נוסף, עיינו במדריך של שירות CA בנושא אישורי Workload Identity. חשוב לוודא שתבנית האישור נוצרה באותו אזור שבו נמצא מאגר ה-CA. אם יש כמה אזורים למאגרי ה-CA, צריך ליצור תבנית אישור לכל אזור.

התפקידים שנדרשים כדי להשתמש בשירות 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"

מגבלות

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

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

הערה: הקפידו לבצע את כל השלבים הבאים לפני שאתם מפעילים את הניהול האוטומטי.

1. מוודאים שמרחב השמות istio-system קיים, ואם הוא חסר יוצרים אותו:

     kubectl create ns istio-system
   

2. בודקים אם configmap של asm-options קיים במרחב השמות istio-system:

     kubectl get configmap/asm-options -n istio-system
   

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

     kubectl create configmap -n istio-system asm-options
   

4. מתקנים את 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"}}'
   

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

     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 בניהול Google על ידי הפעלת הניהול האוטומטי.