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

Standard

הערה: במאמר הזה אנחנו משתמשים בתכונה שליטה במישור הבקרה של GKE, שהיא זמינה לכלל המשתמשים (GA) אבל רק ללקוחות Google Cloudשעומדים בדרישות. כדי לבקש גישה לתכונה הזו, פנו ל Google Cloud צוות ניהול החשבון

.

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

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

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

תכנון רוטציות של פרטי כניסה

במאמר הזה מוסבר איך להחליף את הרכיבים הבאים של פרטי הכניסה במישור הבקרה:

• רשות אישורי הבסיס של האשכול, רשות אישורי הבסיס של הצבירה, רשות אישורי הבסיס של ה-API של etcd ורשות אישורי הבסיס של ה-peer של etcd.
• מפתחות החתימה והאימות של Kubernetes ServiceAccount.

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

שיטה מומלצת:

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

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

• כברירת מחדל, התוקף של אישורי GKE שנחתמו על ידי רשויות אישורי הבסיס בשירות Certificate Authority Service (שירות CA) פג שנה אחרי תאריך היצירה.
• למפתחות ב-Cloud Key Management Service‏ (Cloud KMS) אין תאריך תפוגה. כדאי לבצע רוטציה ידנית של מפתחות רק אם יש בארגון דרישות לרוטציית מפתחות. כדי לצמצם את ההפרעות לעומסי העבודה שפועלים, אל תגדירו רוטציית מפתחות אוטומטית למפתחות האלה.

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

לפני שמתחילים, חשוב לוודא שביצעתם את המשימות הבאות:

• מפעילים את Google Kubernetes Engine API.
הפעלת Google Kubernetes Engine API
• כדי להשתמש ב-Google Cloud CLI למשימה הזו, מתקינים ואז מאתחלים את ה-CLI של gcloud. אם כבר התקנתם את ה-CLI של gcloud, הריצו את הפקודה gcloud components update כדי לקבל את הגרסה העדכנית. יכול להיות שבגרסאות קודמות של ה-CLI של gcloud אי אפשר להריץ את הפקודות שבמסמך הזה.
  הערה: אם ה-CLI של gcloud כבר מותקן, צריך להגדיר את המאפיין compute/region. אם אתם משתמשים בעיקר באשכולות אזוריים, הגדירו במקום זאת את compute/zone. אם מגדירים מיקום ברירת מחדל, אפשר להימנע משגיאות ב-CLI של gcloud כמו: One of [--zone, --region] must be supplied: Please specify location. יכול להיות שתצטרכו לציין את המיקום בפקודות מסוימות אם המיקום של האשכול שונה מברירת המחדל שהגדרתם.

• אשכול קיים שמשתמש ברשויות אישורים בניהול עצמי ובמפתחות של חשבון שירות, ופועלת בו גרסה 1.35.2-gke.1842000 או גרסה חדשה יותר של GKE.

• מזהים את מזהי הפרויקטים של הפרויקטים הבאים ב- Google Cloud :

  • פרויקט המפתח: הפרויקט שמכיל את המשאבים של Cloud KMS ושל שירות CA.
  • ‫Cluster project: הפרויקט שמכיל את אשכול GKE.

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

  • ‫Cloud Key Management Service (KMS) API: DATA_READ
  • ‫Certificate Authority Service:‏ ADMIN_READ

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

תפקידים והרשאות נדרשים

כדי לקבל את ההרשאות שדרושות לרוטציה של מפתחות ורשויות אישורים בניהול הלקוח, בקשו מהאדמין להקצות לכם את התפקידים הבאים ב-IAM:

• ניהול מפתחות או גרסאות של מפתחות: אדמין של Cloud KMS ‏(roles/cloudkms.admin) בפרויקט המפתחות
• ניהול של רשויות אישורים ברמה הבסיסית (root): אדמין של שירות CA (roles/privateca.admin) בפרויקט המפתחות
• הגדרת אשכולות לשימוש בפרטי כניסה חדשים: אדמין של אשכול Kubernetes Engine (roles/container.clusterAdmin) בפרויקט של האשכול

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

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

מגבלות

המפתחות האסימטריים של Cloud KMS שמשמשים לחתימה ולאימות של חשבונות שירות לא תומכים ברוטציית מפתחות אוטומטית.

החלפת מפתחות החתימה והאימות של חשבון השירות

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

כדי להחליף את המפתחות של חשבונות השירות:

1. משיגים את שם המשאב המלא של גרסת המפתח המקורית של מפתח החתימה של חשבון השירות:

   gcloud container clusters describe CLUSTER_NAME \
       --project=CLUSTER_PROJECT_ID \
       --location=CONTROL_PLANE_LOCATION \
       --format="value(userManagedKeysConfig.serviceAccountSigningKeys)"
   

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

   • ‫CLUSTER_NAME: שם האשכול.
   • ‫CONTROL_PLANE_LOCATION: המיקום של האשכול.
   • ‫CLUSTER_PROJECT_ID: מזהה הפרויקט של האשכול.

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

   projects/KEY_PROJECT_ID/locations/CONTROL_PLANE_LOCATION/keyRings/KEYRING_NAME/cryptoKeys/SIGNING_KEY_NAME/cryptoKeyVersions/ORIGINAL_SIGNING_KEY_VERSION
   

   בפלט הזה, SIGNING_KEY_NAME הוא שם המפתח ו-ORIGINAL_SIGNING_KEY_VERSION הוא מספר הגרסה של מפתח החתימה המקורי.

2. יוצרים גרסת מפתח חדשה למפתח החתימה של חשבון השירות:

   gcloud kms keys versions create \
       --key=SIGNING_KEY_NAME \
       --keyring=KEYRING_NAME \
       --location=CONTROL_PLANE_LOCATION \
       --project=KEY_PROJECT_ID
   

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

   • ‫SIGNING_KEY_NAME: השם של מפתח החתימה של חשבון השירות.
   • ‫KEYRING_NAME: השם של אוסף המפתחות שמכיל את המפתח.
   • ‫CONTROL_PLANE_LOCATION: המיקום של אוסף המפתחות ב- Google Cloud .
   • ‫KEY_PROJECT_ID: מזהה הפרויקט של הפרויקט עם המפתחות.

3. משיגים את שם המשאב המלא של גרסת המפתח החדשה:

   gcloud kms keys versions list \
       --key=SIGNING_KEY_NAME \
       --keyring=KEYRING_NAME \
       --location=CONTROL_PLANE_LOCATION \
       --project=KEY_PROJECT_ID \
       --filter="STATE=ENABLED" --sort-by=~ \
       --format="value(name)" | sed 1q
   

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

   projects/KEY_PROJECT_ID/locations/CONTROL_PLANE_LOCATION/keyRings/KEYRING_NAME/cryptoKeys/SIGNING_KEY_NAME/cryptoKeyVersions/NEW_SIGNING_KEY_VERSION
   

   בפלט הזה, SIGNING_KEY_NAME הוא שם המפתח ו-NEW_SIGNING_KEY_VERSION הוא המספר של גרסת מפתח החתימה החדשה.

4. מוסיפים את גרסת המפתח החדשה לקבוצת מפתחות האימות של חשבון השירות באשכול:

   gcloud container clusters update CLUSTER_NAME \
       --location=CONTROL_PLANE_LOCATION \
       --project=CLUSTER_PROJECT_ID \
       --service-account-verification-keys=ORIGINAL_KEY_VERSION_PATH,NEW_KEY_VERSION_PATH
   

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

   • ‫ORIGINAL_KEY_VERSION_PATH: שם המשאב המלא של גרסת מפתח החתימה המקורי מהפלט של השלב הראשון בקטע הזה. לדוגמה, projects/example-key-project/locations/us-central1/keyRings/example-keyring/cryptokeys/example-signing-key/cryptoKeyVersions/1.
   • ‫NEW_KEY_VERSION_PATH: שם המשאב המלא של הגרסה החדשה של מפתח החתימה, מהפלט של השלב הקודם. לדוגמה, projects/example-key-project/locations/us-central1/keyRings/example-keyring/cryptokeys/example-signing-key/cryptoKeyVersions/2.

   אחרי שפעולת העדכון של האשכול מסתיימת, יכול להיות שיעברו עד 10 דקות עד שהנתיב של גרסת המפתח החדשה יופץ לשרת ה-API של Kubernetes ולכל נקודת קצה ל-API של GKE.

5. כדי לוודא שהנתיב של גרסת המפתח החדשה הופץ במלואו:

   1. מקבלים את הרכיב הציבורי של מפתחות החתימה של האשכול מ-GKE API כ-JSON Web Key Set‏ (JWKS):

      curl https://container.googleapis.com/v1/projects/CLUSTER_PROJECT_ID/locations/CONTROL_PLANE_LOCATION/clusters/CLUSTER_NAME/jwks
      

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

      {
        "keys": [
          {
            "kty": "RSA",
            "alg": "RS256",
            "use": "sig",
            "kid": "KEY1_ID",
            "n": "KEY1_MODULUS",
            "e": "KEY1_EXPONENT"
          },
          {
            "kty": "RSA",
            "alg": "RS256",
            "use": "sig",
            "kid": "KEY2_ID",
            "n": "KEY2_MODULUS",
            "e": "KEY2_EXPONENT"
          }
        ]
      }
      

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

   2. מתחברים לאשכול כדי להריץ פקודות kubectl:

      gcloud container clusters get-credentials CLUSTER_NAME \
          --location=CONTROL_PLANE_LOCATION
      

   3. מקבלים את הרכיב הציבורי של מפתחות החתימה של האשכול משרת ה-API של Kubernetes כ-JWKS:

      kubectl get --raw /openid/v1/jwks | jq
      

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

      {
        "keys": [
          {
            "kty": "RSA",
            "alg": "RS256",
            "use": "sig",
            "kid": "KEY1_ID",
            "n": "KEY1_MODULUS",
            "e": "KEY1_EXPONENT"
          },
          {
            "kty": "RSA",
            "alg": "RS256",
            "use": "sig",
            "kid": "KEY2_ID",
            "n": "KEY2_MODULUS",
            "e": "KEY2_EXPONENT"
          }
        ]
      }
      

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

6. מעדכנים את האשכול כך שישתמש בגרסת המפתח החדשה כמפתח החתימה של חשבון השירות:

   gcloud container clusters update CLUSTER_NAME \
       --location=CONTROL_PLANE_LOCATION \
       --project=CLUSTER_PROJECT_ID \
       --service-account-signing-keys=NEW_KEY_VERSION_PATH
   

7. מוודאים שהטוקנים החדשים של חשבון השירות משתמשים בגרסת המפתח החדשה:

   1. יוצרים ServiceAccount:

      kubectl create serviceaccount test-sa-1
      

   2. יוצרים אסימון ל-ServiceAccount:

      kubectl create token test-sa-1
      

   3. מחלצים תקציר שנחתם לאחרונה מ-Logging:

      export SIGNED_DIGEST=$(gcloud logging read \
          'resource.type="gke_cluster"
          AND resource.labels.cluster_name="CLUSTER_NAME"
          AND protoPayload.methodName="google.cloud.gkeauth.v1.Auth.SignServiceAccountJWT"
          AND protoPayload.metadata.subject="system:serviceaccount:default:test-sa-1"' \
          --freshness=1h \
          --bucket=_Required \
          --location=global \
          --view=_AllLogs \
          --order=DESC \
          --limit=1 \
          --format="value(protoPayload.metadata.toBeSignedDigest)")
      

   4. מוודאים שהגרסה החדשה של מפתח החתימה נמצאת בשימוש:

      gcloud logging read \
          'resource.type="cloudkms_cryptokeyversion" 
          AND protoPayload.methodName="AsymmetricSign"
          AND protoPayload.request.digest.sha256="'${SIGNED_DIGEST}'"' \
          --freshness=1h \
          --bucket=_Default \
          --location=global \
          --view=_AllLogs \
          --order=DESC \
          --limit=1 \
          --format="value(protoPayload.resourceName)"
      

      הפלט הוא נתיב המשאב של גרסת מפתח החתימה החדשה.

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

   kubectl get pods -A -o json | jq -r '.items[]?.spec?.volumes[]?.projected?.sources[]?.serviceAccountToken?.expirationSeconds | select(. != null)' | sort -nr | head -n 1
   

   הערה: אם אתם מאחסנים אסימוני ServiceAccount ב-Secrets, צריך ליצור מחדש את ה-Secrets כדי ש-Kubernetes ייצור אסימונים חדשים שחתומים על ידי גרסת המפתח החדשה.

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

10. מסירים את גרסת המפתח המקורית מרשימת מפתחות האימות של האשכול:

    gcloud container clusters update CLUSTER_NAME \
        --location=CONTROL_PLANE_LOCATION \
        --project=CLUSTER_PROJECT_ID \
        --service-account-verification-keys=NEW_KEY_VERSION_PATH
    

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

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

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

רוטציה של רשויות האישורים לשליטה במישור הבקרה של GKE

בקטעים הבאים מוסבר איך להחליף את רשויות האישורים ברמה הבסיסית (root) שבהן משתמש האשכול לשליטה במישור הבקרה של GKE.

יצירת גרסאות חדשות של מפתחות לרשויות האישורים

1. יוצרים גרסת מפתח חדשה למפתח ה-CA ברמה הבסיסית של האשכול:

   gcloud kms keys versions create \
       --key=CLUSTER_CA_KEY_NAME \
       --keyring=KEYRING_NAME \
       --location=CONTROL_PLANE_LOCATION \
       --project=KEY_PROJECT_ID
   

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

   • ‫CLUSTER_CA_KEY_NAME: השם של מפתח ה-CA ברמה הבסיסית (root) של האשכול.
   • ‫KEYRING_NAME: השם של אוסף המפתחות שמכיל את המפתח.
   • ‫CONTROL_PLANE_LOCATION: המיקום של אוסף המפתחות ב- Google Cloud . המיקום הזה זהה למיקום של האשכול.
   • ‫KEY_PROJECT_ID: מזהה הפרויקט של הפרויקט עם המפתחות.

2. יוצרים גרסת מפתח חדשה למפתח ה-CA ברמה הבסיסית (root) של הצבירה:

   gcloud kms keys versions create \
       --key=AGGREGATION_CA_KEY_NAME \
       --keyring=KEYRING_NAME \
       --location=CONTROL_PLANE_LOCATION \
       --project=KEY_PROJECT_ID
   

   מחליפים את AGGREGATION_CA_KEY_NAME בשם של מפתח ה-CA של שורש הצבירה של האשכול.

3. יוצרים גרסת מפתח חדשה למפתח ה-CA ברמה הבסיסית של ה-API של etcd:

   gcloud kms keys versions create \
       --key=ETCD_API_CA_KEY_NAME \
       --keyring=KEYRING_NAME \
       --location=CONTROL_PLANE_LOCATION \
       --project=KEY_PROJECT_ID
   

   מחליפים את ETCD_API_CA_KEY_NAME בשם של מפתח ה-CA ברמה הבסיסית (root) של etcd API באשכול.

4. יוצרים גרסת מפתח חדשה למפתח ה-CA ברמה הבסיסית של עמית ה-etcd:

   gcloud kms keys versions create \
       --key=ETCD_PEER_CA_KEY_NAME \
       --keyring=KEYRING_NAME \
       --location=CONTROL_PLANE_LOCATION \
       --project=KEY_PROJECT_ID
   

   מחליפים את ETCD_PEER_CA_KEY_NAME בשם של מפתח ה-CA ברמה הבסיסית (root) של עמית ה-etcd באשכול.

יצירת רשויות אישורים חדשות ברמה הבסיסית (root)

1. משיגים את השם המלא של המשאב של גרסת מפתח ה-CA ברמה הבסיסית של האשכול החדש:

   gcloud kms keys versions list \
       --key=CLUSTER_CA_KEY_NAME \
       --keyring=KEYRING_NAME \
       --location=CONTROL_PLANE_LOCATION \
       --project=KEY_PROJECT_ID \
       --filter="STATE=ENABLED" --sort-by=~ \
       --format="value(name)" | sed 1q
   

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

   projects/KEY_PROJECT_ID/locations/CONTROL_PLANE_LOCATION/keyRings/KEYRING_NAME/cryptoKeys/CLUSTER_CA_KEY_NAME/cryptoKeyVersions/VERSION
   

   בפלט הזה, VERSION הוא המספר של גרסת המפתח החדשה.

2. יוצרים רשות אישורים חדשה ברמה הבסיסית (root CA) במאגר רשויות האישורים של האשכול:

   gcloud privateca roots create CLUSTER_ROOT_CA_NAME \
       --pool=CLUSTER_CA_POOL_NAME \
       --location=CONTROL_PLANE_LOCATION \
       --kms-key-version=CLUSTER_CA_KEY_PATH \
       --subject="CN=cluster-ca, O=ORGANIZATION" \
       --project=KEY_PROJECT_ID
   

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

   • ‫CLUSTER_ROOT_CA_NAME: שם ל-CA הבסיסי החדש.
   • ‫CLUSTER_CA_POOL_NAME: שם מאגר ה-CA של האשכול.
   • ‫CLUSTER_CA_KEY_PATH: שם המשאב המלא של גרסת המפתח החדשה מהפלט של השלב הקודם.
   • ‫ORGANIZATION: שם הארגון.

3. משיגים את השם המלא של המשאב של גרסת מפתח ה-CA החדשה ברמה הבסיסית (root) לצבירה:

   gcloud kms keys versions list \
       --key=AGGREGATION_CA_KEY_NAME \
       --keyring=KEYRING_NAME \
       --location=CONTROL_PLANE_LOCATION \
       --project=KEY_PROJECT_ID \
       --filter="STATE=ENABLED" --sort-by=~ \
       --format="value(name)" | sed 1q
   

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

   projects/KEY_PROJECT_ID/locations/CONTROL_PLANE_LOCATION/keyRings/KEYRING_NAME/cryptoKeys/AGGREGATION_CA_KEY_NAME/cryptoKeyVersions/VERSION
   

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

   gcloud privateca roots create AGGREGATION_ROOT_CA_NAME \
       --pool=AGGREGATION_CA_POOL_NAME \
       --location=CONTROL_PLANE_LOCATION \
       --kms-key-version=AGGREGATION_CA_KEY_PATH \
       --subject="CN=aggregation-ca, O=ORGANIZATION" \
       --project=KEY_PROJECT_ID
   

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

   • ‫AGGREGATION_ROOT_CA_NAME: שם לרשות האישורים החדשה של צבירת הבסיס.
   • ‫AGGREGATION_CA_POOL_NAME: השם של מאגר רשויות להנפקת אישורים (CA) לצבירה.
   • ‫AGGREGATION_CA_KEY_PATH: שם המשאב המלא של גרסת המפתח החדשה מהפלט של השלב הקודם.

5. משיגים את שם המשאב המלא של הגרסה החדשה של מפתח ה-CA ברמה הבסיסית (root) של ה-API של etcd:

   gcloud kms keys versions list \
       --key=ETCD_API_CA_KEY_NAME \
       --keyring=KEYRING_NAME \
       --location=CONTROL_PLANE_LOCATION \
       --project=KEY_PROJECT_ID \
       --filter="STATE=ENABLED" --sort-by=~ \
       --format="value(name)" | sed 1q
   

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

   projects/KEY_PROJECT_ID/locations/CONTROL_PLANE_LOCATION/keyRings/KEYRING_NAME/cryptoKeys/ETCD_API_CA_KEY_NAME/cryptoKeyVersions/VERSION
   

6. יוצרים רשות אישורים בסיסית חדשה של etcd API במאגר רשויות להנפקת אישורים (CA) של etcd API:

   gcloud privateca roots create ETCD_API_ROOT_CA_NAME \
       --pool=ETCD_API_CA_POOL_NAME \
       --location=CONTROL_PLANE_LOCATION \
       --kms-key-version=ETCD_API_CA_KEY_PATH \
       --subject="CN=etcd-api-ca, O=ORGANIZATION" \
       --project=KEY_PROJECT_ID
   

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

   • ‫ETCD_API_ROOT_CA_NAME: שם לרשות אישורים ברמה הבסיסית (root CA) חדשה של etcd API.
   • ‫ETCD_API_CA_POOL_NAME: השם של מאגר ה-CA של etcd API.
   • ‫ETCD_API_CA_KEY_PATH: שם המשאב המלא של גרסת המפתח החדשה מהפלט של השלב הקודם.

7. משיגים את השם המלא של המשאב של גרסת מפתח ה-CA ברמה הבסיסית של עמית ה-etcd החדש:

   gcloud kms keys versions list \
       --key=ETCD_PEER_CA_KEY_NAME \
       --keyring=KEYRING_NAME \
       --location=CONTROL_PLANE_LOCATION \
       --project=KEY_PROJECT_ID \
       --filter="STATE=ENABLED" --sort-by=~ \
       --format="value(name)" | sed 1q
   

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

   projects/KEY_PROJECT_ID/locations/CONTROL_PLANE_LOCATION/keyRings/KEYRING_NAME/cryptoKeys/ETCD_PEER_CA_KEY_NAME/cryptoKeyVersions/VERSION
   

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

   gcloud privateca roots create ETCD_PEER_ROOT_CA_NAME \
       --pool=ETCD_PEER_CA_POOL_NAME \
       --location=CONTROL_PLANE_LOCATION \
       --kms-key-version=ETCD_PEER_CA_KEY_PATH \
       --subject="CN=etcd-peer-ca, O=ORGANIZATION" \
       --project=KEY_PROJECT_ID
   

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

   • ‫ETCD_PEER_ROOT_CA_NAME: שם לרשות אישורי הבסיס החדשה של עמיתי etcd.
   • ‫ETCD_PEER_CA_POOL_NAME: השם של מאגר רשויות האישורים (CA) של עמיתי etcd.
   • ‫ETCD_PEER_CA_KEY_PATH: שם המשאב המלא של גרסת המפתח החדשה מהפלט של השלב הקודם.

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

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

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

1. מפעילים את ה-CA החדש ברמה הבסיסית (root) של האשכול:

   gcloud privateca roots enable CLUSTER_ROOT_CA_NAME \
       --pool=CLUSTER_CA_POOL_NAME \
       --location=CONTROL_PLANE_LOCATION \
       --project=KEY_PROJECT_ID
   

2. מפעילים את ה-CA החדש ברמה הבסיסית (root) לצבירת נתונים:

   gcloud privateca roots enable AGGREGATION_ROOT_CA_NAME \
       --pool=AGGREGATION_CA_POOL_NAME \
       --location=CONTROL_PLANE_LOCATION \
       --project=KEY_PROJECT_ID
   

3. מפעילים את ה-CA ברמה הבסיסית (root) של ה-API החדש של etcd:

   gcloud privateca roots enable ETCD_API_ROOT_CA_NAME \
       --pool=ETCD_API_CA_POOL_NAME \
       --location=CONTROL_PLANE_LOCATION \
       --project=KEY_PROJECT_ID
   

4. מפעילים את ה-CA החדש של שורש עמית ה-etcd:

   gcloud privateca roots enable ETCD_PEER_ROOT_CA_NAME \
       --pool=ETCD_PEER_CA_POOL_NAME \
       --location=CONTROL_PLANE_LOCATION \
       --project=KEY_PROJECT_ID
   

5. משביתים את ה-CA ברמה הבסיסית (root) של האשכול המקורי:

   gcloud privateca roots disable ORIGINAL_CLUSTER_ROOT_CA \
       --pool=CLUSTER_CA_POOL_NAME \
       --location=CONTROL_PLANE_LOCATION \
       --project=KEY_PROJECT_ID
   

   מחליפים את ORIGINAL_CLUSTER_ROOT_CA בשם של ה-CA המקורי ברמה הבסיסית (root) של האשכול שאתם מחליפים.

6. משביתים את ה-CA המקורי של הרמה הבסיסית (root) לצבירת נתונים:

   gcloud privateca roots disable ORIGINAL_AGGREGATION_ROOT_CA \
       --pool=AGGREGATION_CA_POOL_NAME \
       --location=CONTROL_PLANE_LOCATION \
       --project=KEY_PROJECT_ID
   

   מחליפים את ORIGINAL_AGGREGATION_ROOT_CA בשם של ה-CA המקורי של שורש הצבירה שאתם מחליפים.

7. משביתים את ה-CA ברמה הבסיסית (root) של ה-API המקורי של etcd:

   gcloud privateca roots disable ORIGINAL_ETCD_API_ROOT_CA \
       --pool=ETCD_API_CA_POOL_NAME \
       --location=CONTROL_PLANE_LOCATION \
       --project=KEY_PROJECT_ID
   

   מחליפים את ORIGINAL_ETCD_API_ROOT_CA בשם של ה-CA המקורי של שורש ה-API של etcd שאתם מחליפים.

8. משביתים את ה-CA ברמה הבסיסית (root) של עמית ה-etcd המקורי:

   gcloud privateca roots disable ORIGINAL_ETCD_PEER_ROOT_CA \
       --pool=ETCD_PEER_CA_POOL_NAME \
       --location=CONTROL_PLANE_LOCATION \
       --project=KEY_PROJECT_ID
   

   מחליפים את ORIGINAL_ETCD_PEER_ROOT_CA בשם של ה-CA המקורי של שורש העמית של etcd שאתם מחליפים.

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

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

מחיקת רשויות האישורים המקוריות ברמה הבסיסית (root)

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

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

כדי למחוק את רשויות השורש המקוריות לאישורים, משתמשים בפקודה gcloud privateca roots delete, כמו שמתואר בשלבים הבאים. בפקודות האלה, הדגל --ignore-active-certificates מוחק את ה-CA אחרי תקופת חסד, גם אם יש ל-CA אישורים שלא בוטלו או שהתוקף שלהם לא פג.

1. מוחקים את ה-CA הבסיסי המקורי של האשכול:

   gcloud privateca roots delete ORIGINAL_CLUSTER_ROOT_CA \
       --pool=CLUSTER_CA_POOL_NAME \
       --location=CONTROL_PLANE_LOCATION \
       --project=KEY_PROJECT_ID \
         --ignore-active-certificates
   

   מחליפים את ORIGINAL_CLUSTER_ROOT_CA בשם של ה-CA המקורי ברמה הבסיסית (root) של האשכול שאתם מחליפים.

2. מוחקים את ה-CA המקורי של שורש הצבירה:

   gcloud privateca roots delete ORIGINAL_AGGREGATION_ROOT_CA \
       --pool=AGGREGATION_CA_POOL_NAME \
       --location=CONTROL_PLANE_LOCATION \
       --project=KEY_PROJECT_ID \
         --ignore-active-certificates
   

   מחליפים את ORIGINAL_AGGREGATION_ROOT_CA בשם של ה-CA המקורי של שורש הצבירה שאתם מחליפים.

3. מוחקים את ה-CA ברמה הבסיסית (root) של ה-API המקורי של etcd:

   gcloud privateca roots delete ORIGINAL_ETCD_API_ROOT_CA \
       --pool=ETCD_API_CA_POOL_NAME \
       --location=CONTROL_PLANE_LOCATION \
       --project=KEY_PROJECT_ID \
         --ignore-active-certificates
   

   מחליפים את ORIGINAL_ETCD_API_ROOT_CA בשם של ה-CA המקורי של שורש ה-API של etcd שאתם מחליפים.

4. מוחקים את ה-CA המקורי של שורש עמית ה-etcd:

   gcloud privateca roots delete ORIGINAL_ETCD_PEER_ROOT_CA \
       --pool=ETCD_PEER_CA_POOL_NAME \
       --location=CONTROL_PLANE_LOCATION \
       --project=KEY_PROJECT_ID \
         --ignore-active-certificates
   

   מחליפים את ORIGINAL_ETCD_PEER_ROOT_CA בשם של ה-CA המקורי של שורש העמית של etcd שאתם מחליפים.

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

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

הפעלה מחדש של מישור הבקרה והצמתים

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

1. לשדרג את מישור הבקרה של האשכול לאותה גרסה שכבר נמצאת בשימוש.

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

   1. מאתרים את גרסת GKE שמישור הבקרה כבר משתמש בה:

      gcloud container clusters describe CLUSTER_NAME \
          --location=CONTROL_PLANE_LOCATION \
          --project=CLUSTER_PROJECT_ID \
          --format="value(currentMasterVersion)"
      

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

      • ‫CLUSTER_NAME: השם של אשכול GKE.
      • ‫CLUSTER_VERSION: גרסת GKE שכבר פועלת באשכול.
      • ‫CLUSTER_PROJECT_ID: מזהה הפרויקט של הפרויקט באשכול.

   2. שדרוג מישור הבקרה:

      gcloud container clusters upgrade CLUSTER_NAME \
          --master \
          --location=CONTROL_PLANE_LOCATION \
          --cluster-version=CLUSTER_VERSION \
          --project=CLUSTER_PROJECT_ID
      

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

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

   1. מאתרים את גרסת ה-GKE שבה משתמש מאגר הצמתים:

      gcloud container node-pools describe NODE_POOL_NAME \
          --cluster=CLUSTER_NAME \
          --location=CONTROL_PLANE_LOCATION \
          --project=CLUSTER_PROJECT_ID \
          --format="value(version)"
      

      מחליפים את NODE_POOL_NAME בשם של מאגר הצמתים שרוצים לשדרג.

   2. משדרגים את מאגר הצמתים:

      gcloud container clusters upgrade CLUSTER_NAME \
          --node-pool=NODE_POOL_NAME \
          --location=CONTROL_PLANE_LOCATION \
          --cluster-version=CLUSTER_VERSION \
          --project=CLUSTER_PROJECT_ID
      

3. אחרי שמישור הבקרה והצמתים מסיימים את השדרוג, מעדכנים את כל לקוחות ה-API של Kubernetes, כמו kubectl CLI, כדי להשתמש בחבילת האמון המעודכנת. אם אתם יוצרים אישורים באופן ידני באמצעות CertificateSigningRequests של Kubernetes, אתם צריכים להנפיק מחדש את כל האישורים האלה ולספק את האישורים החדשים ללקוחות ה-API.

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

• מחליפים את רשויות אישורי הבסיס המקוריות ברשויות אישורי הבסיס החדשות.
• מוחקים את רשויות אישורי הבסיס המקוריות.

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

• החלפת מפתחות ההצפנה של etcd ושל דיסק האתחול של מישור הבקרה
• אימות ההנפקה והשימוש בזהות