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

רגילה

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

.

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

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

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

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

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

• רשות האישורים (CA) העליונה של האשכול, רשות האישורים (CA) העליונה של הצבירה, רשות האישורים (CA) העליונה של etcd API ורשות האישורים (CA) העליונה של etcd peer.
• מפתחות החתימה והאימות של Kubernetes ServiceAccount.

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

שיטה מומלצת:

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

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

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

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

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

• מפעילים את ממשק Google Kubernetes Engine API.
הפעלת Google Kubernetes Engine API
• כדי להשתמש ב-CLI של Google Cloud למשימה הזו, צריך להתקין ואז להפעיל את gcloud CLI. אם התקנתם בעבר את ה-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. יכול להיות שתצטרכו לציין את המיקום בפקודות מסוימות אם המיקום של האשכול שונה מברירת המחדל שהגדרתם.

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

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

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

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

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

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

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

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

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

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

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

מגבלות

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

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

כשמגדירים שליטה במישור הבקרה של GKE, מוסיפים מפתח חתימה של חשבון שירות ומפתחות אימות של חשבון שירות לאשכול. ‫GKE משתמש במפתחות האלה כדי לחתום על אסימוני bearer ולאמת אותם עבור חשבונות שירות של 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 ובכל נקודת קצה של GKE API.

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. מקבלים את הרכיב הציבורי של מפתחות החתימה של האשכול משרת Kubernetes API כ-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. יוצרים טוקן עבור חשבון השירות:

      kubectl create token test-sa-1
      

   3. כדי לחלץ סיכום חתום מהיומן:

      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 דוחה בקשות שמשתמשות בטוקן מסוג bearer עם גרסת המפתח המקורית, כי גרסת המפתח המקורית לא קיימת בהגדרת האשכול.

סיבוב של רשויות אישורים (CA) של מישור הבקרה של GKE

בקטעים הבאים מוסבר איך להחליף את רשויות האישורים הבסיסיות שבהן האשכול משתמש לצורך הרשאות של מישור הבקרה ב-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 הבסיסי של האשכול.
   • ‫KEYRING_NAME: השם של אוסף המפתחות שמכיל את המפתח.
   • ‫CONTROL_PLANE_LOCATION: Google Cloud המיקום של אוסף המפתחות. זהה למיקום האשכול.
   • ‫KEY_PROJECT_ID: מזהה הפרויקט של פרויקט המפתח.

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

   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 בסיסי של etcd API:

   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 הבסיסי של 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 הבסיסי של עמית etcd עבור האשכול.

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

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. יוצרים CA חדש ברמה הבסיסית במאגר ה-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: שם עבור רשות האישורים הבסיסית החדשה.
   • ‫CLUSTER_CA_POOL_NAME: השם של מאגר רשויות האישורים של האשכול.
   • ‫CLUSTER_CA_KEY_PATH: שם המשאב המלא של גרסת המפתח החדשה מהפלט של השלב הקודם.
   • ‫ORGANIZATION: שם הארגון.

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

   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. יוצרים CA חדש ברמה הבסיסית של הצבירה במאגר ה-CA של הצבירה:

   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: שם ל-CA הבסיסי החדש של הצבירה.
   • ‫AGGREGATION_CA_POOL_NAME: השם של מאגר רשויות האישורים המצטבר.
   • ‫AGGREGATION_CA_KEY_PATH: שם המשאב המלא של גרסת המפתח החדשה מהפלט של השלב הקודם.

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

   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. יוצרים CA חדש של שורש API של etcd במאגר ה-CA של API של etcd:

   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: שם ל-CA הבסיסי החדש של etcd API.
   • ‫ETCD_API_CA_POOL_NAME: השם של מאגר האישורים של etcd API CA.
   • ‫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. יוצרים רשות אישורים (CA) חדשה ברמה הבסיסית של etcd peer במאגר רשויות האישורים של etcd peer:

   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: שם ל-CA הבסיסי החדש של עמית etcd.
   • ‫ETCD_PEER_CA_POOL_NAME: שם מאגר רשויות האישורים של עמיתי etcd.
   • ‫ETCD_PEER_CA_KEY_PATH: שם המשאב המלא של גרסת המפתח החדשה מהפלט של השלב הקודם.

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

החלפת רשויות אישורים (CA) בסיסיות מקוריות ברשויות אישורים (CA) בסיסיות חדשות

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

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

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

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

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

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

   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 המקורי של הבסיס של האשכול:

   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 בשם של רשות האישורים הבסיסית המקורית של האשכול שאתם מבצעים רוטציה שלה.

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

   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) העליונה של etcd API המקורי:

   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) הבסיסית המקורית של עמית 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) העליונות המקוריות

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

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

כדי למחוק את רשויות האישורים המקוריות של הבסיס, משתמשים בפקודה 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 בשם של רשות האישורים הבסיסית המקורית של האשכול שאתם מבצעים רוטציה שלה.

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) הבסיסית המקורית של etcd API:

   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. אופציונלי: מעבירים את השינויים ל-CA הבסיסי כדי להוסיף אותו לחבילת האישורים של האשכול. הוראות מפורטות מופיעות בקטע הפעלה מחדש של מישור הבקרה והצמתים. אם מדלגים על השלב הזה, רשויות האישורים המקוריות של הבסיס מוסרות במהלך השדרוג הבא של מישור הבקרה וגרסת הצומת.

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

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

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

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

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

   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. לסיבוב של CA בסיס באשכול בלבד, מפעילים יצירה מחדש של צמתים על ידי שדרוג כל אחד ממאגרי הצמתים לאותה גרסה שכבר נמצאת בשימוש.

   זהירות: 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, כמו ה-CLI של kubectl, כדי להשתמש בחבילת האישורים המעודכנת. אם אתם יוצרים אישורים באופן ידני באמצעות Kubernetes CertificateSigningRequests, צריך להנפיק מחדש את כל האישורים האלה ולספק את האישורים החדשים ללקוחות API.

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

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

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

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