הגדרת אימות מנוהל של Workload Identity ב-GKE

רשות אישורים שמוגדרת כברירת מחדל

כדי לקשר את רשות האישורים שמוגדרת כברירת מחדל למאגר הזהויות של עומס העבודה, מעדכנים את מאגר הזהויות של עומס העבודה באמצעות הדגל use-default-shared-ca.

  gcloud iam workload-identity-pools update TRUST_DOMAIN_NAME \
      --location="global" \
      --use-default-shared-ca \
      --project=PROJECT_ID

מחליפים את מה שכתוב בשדות הבאים:

• TRUST_DOMAIN_NAME:

  שם דומיין האמון. בהתאם לסוג המאגר, צריך לעצב את השם באופן הבא:

  • מאגר בניהול Google: PROJECT_ID.s3ns.svc.id.goog
  • מאגר בניהול עצמי: POOL_NAME.global.POOL_HOST_PROJECT_NUMBER.workload.id.goog
• ‫PROJECT_ID: מזהה הפרויקט של פרויקט המארח של ה-Fleet.

רשות אישורים בהתאמה אישית

1. הגדרת CA Service להנפקת אישורים לזהויות מנוהלות של עומסי עבודה.
2. קישור רשויות האישורים למאגר הזהויות של עומסי העבודה.
3. איך נותנים הרשאה לזהויות מנוהלות של עומסי עבודה לבקש אישורים ממאגר רשויות האישורים

הגדרת שירות CA להנפקת אישורים לזהויות מנוהלות של עומסי עבודה

כדי להגדיר זהויות מנוהלות של עומסי עבודה ב-GKE, צריך קודם להגדיר רשות אישורים (CA) ורשות אישורים משנית אחת או יותר. ההגדרה הזו נקראת היררכיית רשויות אישורים.

אפשר להשתמש במאגרי CA Service כדי להגדיר את ההיררכיה הזו. בהיררכיה הזו, מאגר CA משני מנפיק לעומסי העבודה שלכם את אישורי הזהות של עומסי העבודה מסוג X.509.

מאגרי רשויות האישורים שהוגדרו להנפקת אישורים לעומסי עבודה באמצעות זהויות מנוהלות של עומסי עבודה חייבים להיות באותו אזור כמו עומס העבודה. אם רוצים לתכנן ארכיטקטורה במספר אזורים כדי להבטיח עמידות במקרה של הפסקות אזוריות, מומלץ להגדיר מאגר משני של רשות אישורים (CA) של Certificate Authority Service לכל אזור שבו מפעילים עומסי עבודה. כך כל עומס עבודה יכול להפנות למאגר CA של Certificate Authority Service משנית באזור.

הגדרת מאגר רשויות אישורים (CA) עליונות

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

יוצרים את מאגר רשויות האישורים (CA) העליונות במסלול Enterprise באמצעות gcloud privateca pools create. המסלול הזה מיועד להנפקת אישורים לטווח ארוך בכמויות קטנות.

gcloud privateca pools create ROOT_CA_POOL_ID \
    --location=REGION \
    --project=CA_PROJECT_ID \
    --tier=enterprise

מחליפים את מה שכתוב בשדות הבאים:

• ‫ROOT_CA_POOL_ID: מזהה ייחודי של מאגר אישורי ה-CA הבסיסיים. המזהה יכול להכיל עד 64 תווים, והוא חייב לכלול רק תווים אלפאנומריים (אותיות קטנות וגדולות), קווים תחתונים או מקפים. מזהה המאגר חייב להיות ייחודי באזור.

• ‫REGION: האזור שבו נמצא מאגר רשויות האישורים (CA) העליונות.

• ‫CA_PROJECT_ID: מזהה הפרויקט שבו רוצים ליצור את רשות האישורים הבסיסית.

מידע נוסף על מאגרי CA, רמות ואזורים זמין במאמר יצירת מאגרי CA.

הגדרת רשות האישורים (CA) העליונה

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

כדי ליצור רשות אישורים (CA) בסיסית, מריצים את הפקודה הבאה:

gcloud privateca roots create ROOT_CA_ID \
    --pool=ROOT_CA_POOL_ID \
    --subject="CN=ROOT_CA_CN, O=ROOT_CA_ORGANIZATION" \
    --key-algorithm="KEY_ALGORITHM" \
    --max-chain-length=1 \
    --location=REGION \
    --project=CA_PROJECT_ID \
    --auto-enable

מחליפים את מה שכתוב בשדות הבאים:

• ‫ROOT_CA_ID: שם ייחודי של רשות האישורים הבסיסית. השם של רשות האישורים יכול להיות באורך של עד 64 תווים, והוא חייב להכיל רק תווים אלפאנומריים באותיות קטנות וגדולות, קווים תחתונים או מקפים. השם של ה-CA חייב להיות ייחודי באזור.
• ‫ROOT_CA_POOL_ID: המזהה של מאגר אישורי ה-CA הבסיסי.
• ‫ROOT_CA_CN: השם הנפוץ של רשות האישורים הבסיסית.
• ‫ROOT_CA_ORGANIZATION: הארגון של רשות האישורים הבסיסית.
• ‫KEY_ALGORITHM: אלגוריתם המפתח, לדוגמה ec-p256-sha256.
• ‫REGION: האזור שבו נמצא מאגר רשויות האישורים (CA) העליונות.
• ‫CA_PROJECT_ID: מזהה הפרויקט שבו יצרתם את רשות האישורים הבסיסית.

מידע נוסף על השדות subject של רשות האישורים זמין במאמר בנושא נושא.

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

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

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

• תרחישים שונים להנפקת אישורים: אם יש לכם תרחישים שונים להנפקת אישורים, אתם יכולים ליצור CA משני לכל תרחיש.

• איזון עומסים טוב יותר: הוספה של כמה רשויות אישורים משניות למאגר רשויות אישורים עוזרת להשיג איזון עומסים טוב יותר של בקשות לאישורים.

כדי ליצור מאגר של רשויות אישורים משניות ורשות אישורים משנית:

1. יוצרים את מאגר ה-CA המשני ברמת DevOps, שמתאימה להנפקת אישורים לטווח קצר בכמויות גדולות.

   gcloud privateca pools create SUBORDINATE_CA_POOL_ID \
       --location=REGION \
       --project=CA_PROJECT_ID \
       --tier=devops
   

   מחליפים את מה שכתוב בשדות הבאים:

   • ‫SUBORDINATE_CA_POOL_ID: מזהה ייחודי של מאגר ה-CA המשני. המזהה יכול להכיל עד 64 תווים, והוא חייב לכלול רק תווים אלפאנומריים באותיות קטנות וגדולות, קווים תחתונים או מקפים. מזהה המאגר חייב להיות ייחודי באזור.
   • ‫REGION: האזור שבו ייצור המאגר המשני של רשויות אישורים.
   • ‫CA_PROJECT_ID: מזהה הפרויקט שבו יצרתם את רשות האישורים המשנית.

   מידע נוסף זמין במאמר בנושא יצירת מאגרי CA.

2. יוצרים רשות אישורים משנית במאגר רשויות אישורים משניות. לא לשנות את מצב ההנפקה מבוסס-ההגדרות שמוגדר כברירת מחדל.

   gcloud privateca subordinates create SUBORDINATE_CA_ID \
       --pool=SUBORDINATE_CA_POOL_ID \
       --location=REGION \
       --issuer-pool=ROOT_CA_POOL_ID \
       --issuer-location=REGION \
       --subject="CN=SUBORDINATE_CA_CN, O=SUBORDINATE_CA_ORGANIZATION" \
       --key-algorithm="KEY_ALGORITHM" \
       --use-preset-profile=subordinate_mtls_pathlen_0 \
       --project=CA_PROJECT_ID \
       --auto-enable
   

   מחליפים את מה שכתוב בשדות הבאים:

   • ‫SUBORDINATE_CA_ID: שם ייחודי של רשות אישורים משנית. השם יכול להיות באורך של עד 64 תווים והוא חייב להכיל רק תווים אלפאנומריים באותיות קטנות וגדולות, קווים תחתונים או מקפים. השם של מאגר כתובות ה-IP צריך להיות ייחודי באזור.
   • SUBORDINATE_CA_POOL_ID: השם של מאגר רשויות האישורים המשניות.
   • ‫REGION: האזור שבו נמצא מאגר ה-CA המשני.
   • ‫ROOT_CA_POOL_ID: המזהה של מאגר אישורי ה-CA הבסיסי.
   • ‫REGION: האזור של מאגר רשויות האישורים הבסיסיות.
   • ‫SUBORDINATE_CA_CN: השם הנפוץ של רשות האישורים המשנית.
   • ‫SUBORDINATE_CA_ORGANIZATION: השם של הארגון המנפיק של רשות האישורים המשנית.
   • ‫KEY_ALGORITHM: אלגוריתם המפתח, לדוגמה ec-p256-sha256.
   • ‫CA_PROJECT_ID: מזהה הפרויקט שבו יצרתם את רשות האישורים המשנית.

   מידע נוסף על השדות subject של רשות האישורים זמין במאמר בנושא נושא.

יצירת קובץ תצורה להנפקת אישורים

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

כדי להגדיר את הגדרות הנפקת האישורים, יוצרים קובץ הגדרות הנפקת אישורים בשם cic.json. הפורמט של הקובץ דומה לזה:

{
  "inlineCertificateIssuanceConfig": {
      "caPools": {
        "REGION1": "projects/CA_PROJECT_NUMBER1/locations/REGION1/caPools/SUBORDINATE_CA_POOL_ID1",
        "REGION2": "projects/CA_PROJECT_NUMBER2/locations/REGION2/caPools/SUBORDINATE_CA_POOL_ID2"
      },
      "lifetime": "DURATION",
      "rotationWindowPercentage": ROTATION_WINDOW_PERCENTAGE,
      "keyAlgorithm": "ALGORITHM"
  }
}

מחליפים את מה שכתוב בשדות הבאים:

• ‫REGION: האזורים שבהם נמצאים רשויות האישורים.

• ‫CA_PROJECT_NUMBER: מספר הפרויקט שבו יצרתם את מאגר ה-CA המשני. כדי לקבל את מספר הפרויקט של פרויקט CA_PROJECT_ID, מריצים את הפקודה הבאה:

  gcloud projects describe CA_PROJECT_ID --format="value(projectNumber)"
  

• SUBORDINATE_CA_POOL_ID: השם של מאגר רשויות האישורים המשניות.

• ‫ALGORITHM: אופציונלי. אלגוריתם ההצפנה ששימש ליצירת המפתח הפרטי. הערכים התקפים הם ECDSA_P256, ‏ ECDSA_P384,‏ RSA_2048, ‏ RSA_3072, ‏ RSA_4096. אם לא מציינים אלגוריתם, ECDSA_P256 משמש כאלגוריתם ברירת המחדל.

• ‫DURATION: אופציונלי. משך התוקף של אישור הקצה, בשניות. הערך צריך להיות בין 86,400 (יום אחד) לבין 2,592,000 (30 ימים). אם לא מציינים ערך, המערכת משתמשת בערך ברירת המחדל 86,400 (יום אחד). תוקף האישור בפועל תלוי גם ב-CA שהנפיק אותו, כי הוא יכול להגביל את משך החיים של האישור שהונפק.

• ROTATION_WINDOW_PERCENTAGE: אופציונלי: אחוז משך החיים של האישור שבו מופעל חידוש. הערך צריך להיות בין 50 ל-80. אם לא מציינים ערך, נעשה שימוש בערך ברירת המחדל 50.

קישור רשויות האישורים למאגר הזהויות של עומסי העבודה

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

עדכון מאגר הזהויות של עומסי העבודה

כדי לעדכן את המאגר, מריצים את הפקודה הבאה:

gcloud iam workload-identity-pools update TRUST_DOMAIN_NAME \
    --location="global" \
    --inline-certificate-issuance-config-file=CIC_JSON_FILE_PATH \
    --project=PROJECT_ID

מחליפים את מה שכתוב בשדות הבאים:

• ‫TRUST_DOMAIN_NAME: השם של דומיין האמון. בהתאם לסוג המאגר, צריך לעצב את השם באופן הבא:

  • מאגר בניהול Google: PROJECT_ID.s3ns.svc.id.goog
  • מאגר בניהול עצמי: POOL_NAME.global.POOL_HOST_PROJECT_NUMBER.workload.id.goog

• ‫CIC_JSON_FILE_PATH: הנתיב לקובץ ההגדרות להנפקת אישורים בפורמט JSON (cic.json) שיצרתם קודם.

אימות העדכון של מאגר הזהויות של עומסי העבודה

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

gcloud iam workload-identity-pools describe TRUST_DOMAIN_NAME \
    --location="global" \
    --project=PROJECT_ID

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

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

inlineCertificateIssuanceConfig:
    caPools:
      REGION1: projects/PROJECT_NUMBER1/locations/REGION1/caPools/SUBORDINATE_CA_POOL_ID1,
      REGION2: projects/PROJECT_NUMBER2/locations/REGION2/caPools/SUBORDINATE_CA_POOL_ID2
    keyAlgorithm: ALGORITHM
    lifetime: DURATION
    rotationWindowPercentage: ROTATION_WINDOW_PERCENTAGE
mode: TRUST_DOMAIN
name: TRUST_DOMAIN_NAME
state: ACTIVE

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

איך מאשרים לזהויות מנוהלות של עומסי עבודה לבקש אישורים ממאגר ה-CA

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

1. נותנים את תפקיד ה-IAM‏ CA Service Workload Certificate Requester (roles/privateca.workloadCertificateRequester) לכל מאגר CA משני בדומיין המהימן. הפקודה gcloud privateca pools add-iam-policy-binding הבאה מאשרת לדומיין המהימן לבקש אישורים משרשראות האישורים של שירות רשות האישורים.

   gcloud privateca pools add-iam-policy-binding SUBORDINATE_CA_POOL_ID \
       --location=REGION \
       --role=roles/privateca.workloadCertificateRequester \
       --member="principal://iam.googleapis.com/projects/PROJECT_NUMBER/name/locations/global/workloadIdentityPools/TRUST_DOMAIN_NAME" \
       --project=CA_PROJECT_ID
   

   מחליפים את מה שכתוב בשדות הבאים:

   • ‫SUBORDINATE_CA_POOL_ID: המזהה של מאגר רשויות האישורים המשניות.
   • ‫REGION: האזור של מאגר רשויות האישורים המשניות.

   • ‫PROJECT_NUMBER: מספר הפרויקט שמכיל את מאגר הזהויות של עומסי העבודה ב-GKE.

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

     gcloud projects describe WORKLOAD_IDENTITY_POOL_PROJECT_ID --format="value(projectNumber)"
     

   • ‫WORKLOAD_IDENTITY_POOL_PROJECT_ID: מזהה הפרויקט שמכיל את מאגר הזהויות של עומסי העבודה.

   • ‫TRUST_DOMAIN_NAME: השם של דומיין האמון. בהתאם לסוג המאגר, צריך לעצב את השם באופן הבא:

     • מאגר בניהול Google: PROJECT_ID.s3ns.svc.id.goog
     • מאגר בניהול עצמי: POOL_NAME.global.POOL_HOST_PROJECT_NUMBER.workload.id.goog

   • ‫CA_PROJECT_ID: מזהה הפרויקט שבו יצרתם את רשות האישורים המשנית.

2. מקצים את התפקיד CA Service Pool Reader (roles/privateca.poolReader) במאגרי CA משניים לזהות המנוהלת של עומס העבודה. כך מאשרים לזהות המנוהלת של עומס העבודה לקבל את אישורי X.509 החתומים משרשרות האישורים של רשות האישורים.

   gcloud privateca pools add-iam-policy-binding SUBORDINATE_CA_POOL_ID \
       --location=REGION \
       --role=roles/privateca.poolReader \
       --member="principal://iam.googleapis.com/projects/PROJECT_NUMBER/name/locations/global/workloadIdentityPools/TRUST_DOMAIN_NAME" \
       --project=CA_PROJECT_ID
   

   מחליפים את מה שכתוב בשדות הבאים:

   • ‫SUBORDINATE_CA_POOL_ID: המזהה של מאגר רשויות האישורים המשניות.
   • ‫REGION: האזור של מאגר רשויות האישורים המשניות.
   • ‫PROJECT_NUMBER: מספר הפרויקט שמכיל את מאגר הזהויות של עומסי העבודה ב-GKE.
   • ‫TRUST_DOMAIN_NAME: השם של דומיין האמון. בהתאם לסוג המאגר, הפורמט של השם הוא:
     • מאגר בניהול Google: PROJECT_ID.s3ns.svc.id.goog
     • מאגר בניהול עצמי: POOL_NAME.global.POOL_HOST_PROJECT_NUMBER.workload.id.goog
   • ‫CA_PROJECT_ID: מזהה הפרויקט שבו יצרתם את רשות האישורים המשנית.

מאגר בניהול Google

כדי לפרוס Pod לבדיקה באשכול:

1. מקבלים את פרטי הכניסה לאשכול.

   gcloud container clusters get-credentials CLUSTER_NAME \
       --location=CLUSTER_ZONE \
       --project=CLUSTER_PROJECT_ID
   

2. יוצרים את מרחב השמות של Kubernetes.

   kubectl create namespace KUBERNETES_NAMESPACE
   

3. פריסת PodSpec לבדיקה.

   cat <<EOF | kubectl apply -f -
   apiVersion: v1
   kind: Pod
   metadata:
     namespace: KUBERNETES_NAMESPACE
     name: example-pod
   spec:
     containers:
     - name: main
       image: debian
       command: ['sleep', 'infinity']
       volumeMounts:
       - name: fleet-spiffe-credentials
         mountPath: /var/run/secrets/workload-spiffe-credentials
         readOnly: true
     nodeSelector:
       iam.gke.io/gke-metadata-server-enabled: "true"
     volumes:
     - name: fleet-spiffe-credentials
       csi:
         driver: podcertificate.gke.io
         volumeAttributes:
           signerName: spiffe.gke.io/fleet-svid
           trustDomain: fleet-project/s3ns.svc.id.goog
   EOF
   

מאגר בניהול עצמי

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

1. מגדירים מאגר זהויות של עומסי עבודה בניהול עצמי ומגדירים את אשכולות ה-Fleet כך שישתמשו במאגר הזה.

2. מקבלים את פרטי הכניסה לאשכול.

   gcloud container clusters get-credentials CLUSTER_NAME \
       --location=CLUSTER_ZONE \
       --project=CLUSTER_PROJECT_ID
   

3. יוצרים את מרחב השמות של Kubernetes.

   kubectl create namespace KUBERNETES_NAMESPACE
   

4. פריסת PodSpec לבדיקה.

   ההגדרה הבאה של PodSpec מגדירה את מאפיין עוצמת הקול trustDomain למאגר זהויות של כוח עבודה בניהול עצמי:

   cat <<EOF | kubectl apply -f -
   apiVersion: v1
   kind: Pod
   metadata:
     namespace: KUBERNETES_NAMESPACE
     name: example-pod
   spec:
     containers:
     - name: main
       image: debian
       command: ['sleep', 'infinity']
       volumeMounts:
       - name: fleet-spiffe-credentials
         mountPath: /var/run/secrets/workload-spiffe-credentials
         readOnly: true
     nodeSelector:
       iam.gke.io/gke-metadata-server-enabled: "true"
     volumes:
     - name: fleet-spiffe-credentials
       csi:
         driver: podcertificate.gke.io
         volumeAttributes:
           signerName: spiffe.gke.io/fleet-svid
           trustDomain: fleet-project/tenancy-scope
   EOF