עדכון של פרטי הכניסה לאשכול

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

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

מידע על רוטציית פרטי כניסה ב-GKE

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

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

• רוטציית פרטי כניסה:

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

• רוטציה של כתובות IP:

  • החלפת כתובת ה-IP שבה משתמש מישור הבקרה לשרת ה-API של Kubernetes.
  • החלפת ה-CA ברמה הבסיסית (root) של האשכול.

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

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

מתי לבצע רוטציית פרטי כניסה

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

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

משך החיים של פרטי הכניסה לאשכול

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

• לצברי שרתים שנוצרו לפני אוקטובר 2021 יש תוקף של 5 שנים ל-CA.
• לצברים שנוצרו אחרי אוקטובר 2021 יש תוקף של 30 שנה ל-CA.
• לצבירי שרתים שהוחלפו אחרי ינואר 2022 בערך יש תוקף של 30 שנה ל-CA.

חיפוש אשכולות עם אישורים שתוקפם עומד לפוג או שתוקפם פג

אם תוקף האישורים של האשכול יפוג ב-180 הימים הבאים, או אם תוקף האישורים של האשכול כבר פג, GKE יציג תובנה והמלצה שמסבירות שצריך לבצע רוטציה של האישורים באשכול הזה. ההנחיות האלה כוללות את תאריך התפוגה של פרטי הכניסה. אפשר לראות את ההנחיות האלה במסוף Cloud de Confiance . לחלופין, אפשר להציג את ההנחיות האלה באמצעות ה-CLI של gcloud או Recommender API, ולציין את סוג המשנה CLUSTER_CA_EXPIRATION.

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

מדיניות האוטומציה של GKE למניעת הפסקות זמניות בפעילות של אשכולות

כדי למנוע מצב שבו לא ניתן לשחזר את האשכול אם תוקף פרטי הכניסה הנוכחיים יפוג, GKE מתחיל באופן אוטומטי רוטציית פרטי כניסה תוך 30 יום מתאריך התפוגה של ה-CA הנוכחי. לדוגמה, אם תוקף אישור ה-CA של האשכול יפוג ב-6 בינואר 2024 ולא תבצעו רוטציה של פרטי הכניסה עד 5 בדצמבר 2023. ‫GKE מתחיל רוטציה אוטומטית ב-7 בדצמבר 2023 או אחרי התאריך הזה, ומנסה להשלים את הרוטציה הזו שבעה ימים אחרי שהפעולה מתחילה. הרוטציה האוטומטית הזו היא ניסיון אחרון למנוע הפסקת פעולה של אשכול, ויש לקחת בחשבון את הנקודות הבאות:

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

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

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

• מפעילים את ממשק ה-API של Google Kubernetes Engine.
הפעלת Google Kubernetes Engine API
• כדי להשתמש ב-Google Cloud CLI למשימה הזו, מתקינים ואז מאתחלים את ה-CLI של gcloud. אם התקנתם בעבר את ה-CLI של gcloud, מריצים את הפקודה gcloud components update כדי לקבל את הגרסה העדכנית. יכול להיות שבגרסאות קודמות של ה-CLI של gcloud אי אפשר להריץ את הפקודות שבמסמך הזה.

• מוודאים שיש לכם אשכול קיים במצב Autopilot או במצב Standard. אם אתם צריכים אשכול, צרו אשכול Autopilot.

בדיקת משך החיים של פרטי הכניסה

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

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

gcloud container clusters describe CLUSTER_NAME \
    --location LOCATION \
    --format "value(masterAuth.clusterCaCertificate)" \
    | base64 --decode \
    | openssl x509 -noout -dates

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

notBefore=Mar 17 16:45:34 2023 GMT
notAfter=Mar  9 17:45:34 2053 GMT

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

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

gcloud container clusters list --project PROJECT_ID \
    --format="value(name,masterAuth.clusterCaCertificate)" | \
while read -r cluster ca; do \
    expiry_date=$(echo -e "$ca" | base64 --decode | openssl x509 -noout -enddate | awk -F'=' '{print $2}'); \
    printf "%-40s  | %s\n" "$cluster" "$expiry_date" ; \
done | \
column -t | \
awk -F',' 'BEGIN{print "Cluster Name    |  Certificate Expiry Date"} {print}'

ביצוע רוטציית פרטי כניסה

כל רוטציית פרטי כניסה כוללת את השלבים הבאים:

1. מתחילים את הרוטציה: מישור הבקרה מתחיל לפעול בכתובת IP חדשה בנוסף לכתובת ה-IP המקורית. פרטי כניסה חדשים מונפקים לעומסי עבודה ולמישור הבקרה.
2. יצירה מחדש של הצמתים: מערכת GKE יוצרת מחדש את הצמתים באשכול כדי שהצמתים ישתמשו בכתובת ה-IP ובפרטי הכניסה החדשים, תוך התחשבות בזמינות של חלונות זמן לתחזוקה ובחריגים. אתם יכולים גם ליצור מחדש את הצמתים באופן ידני על ידי שדרוג גרסת הצומת לאותה גרסת GKE שכבר פועלת בצמתים.
3. עדכון של לקוחות API: אחרי התחלת הרוטציה, צריך לעדכן את כל לקוחות ה-API של האשכול, כמו מכונות פיתוח שמשתמשות ב-kubectl, כדי לתקשר עם מישור הבקרה באמצעות כתובת ה-IP החדשה.
4. השלמת הרוטציה: מישור הבקרה מפסיק להעביר תנועה דרך כתובת ה-IP המקורית. פרטי הכניסה הישנים מבוטלים, כולל פרטי כניסה סטטיים קיימים של חשבונות שירות ב-Kubernetes.

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

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

התחלת הסבב

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

gcloud container clusters update CLUSTER_NAME \
    --location LOCATION \
    --start-credential-rotation

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

הפעלה מחדש של רכיבים בתוך האשכול עם חיבורים לטווח ארוך

אחרי שמתחילים רוטציה של כתובת IP או של רוטציית פרטי כניסה, גם רשות האישורים (CA) של האשכול עוברת רוטציה. יכול להיות שרכיבים מסוימים בתוך האשכול ששומרים על חיבורי TLS לטווח ארוך, כמו metrics-server ו-konnectivity-agent, לא יבטחו אוטומטית ב-CA החדש של האשכול.

במצב כזה, החיבורים האלה עלולים להיכשל כשמתקשרים עם צמתים או עם נקודות קצה אחרות של האשכול, ויכול להיות שיופיעו שגיאות של לחיצת יד בפרוטוקול TLS ביומני הרכיבים, כמו x509: certificate signed by unknown authority.

אם השגיאות האלה מופיעות אחרי שהתחלתם רוטציה, יכול להיות שתצטרכו להפעיל מחדש את ה-Pods באופן ידני. הפעלה מחדש מאלצת את ה-Pod לאתחל מחדש את החיבור שלו ולטעון את אישורי ה-CA החדשים של האשכול. לדוגמה, כדי להפעיל מחדש את metrics-server ו-konnectivity-agent, מריצים את הפקודות הבאות:

kubectl rollout restart deployment metrics-server -n kube-system
kubectl rollout restart deployment konnectivity-agent -n kube-system

יצירה מחדש של צמתים

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

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

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

• באשכולות Autopilot, משדרגים ידנית את מישור הבקרה:

  gcloud container clusters upgrade CLUSTER_NAME \
      --location=LOCATION \
      --master \
      --cluster-version=VERSION
  

  מחליפים את VERSION בגרסת GKE זהה לגרסה שכבר נמצאת בשימוש באשכול.

• באשכולות רגילים, שדרגו ידנית כל מאגר צמתים.

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

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

1. כדי לעקוב אחרי פעולת הרוטציה, מריצים את הפקודה הבאה:

   gcloud container operations list \
       --filter="operationType=UPGRADE_NODES AND status=RUNNING" \
       --format="value(name)"
   

   הפקודה הזו מחזירה את מזהה הפעולה של פעולת שדרוג הצומת.

2. כדי לבדוק את סטטוס הפעולה, מעבירים את מזהה הפעולה לפקודה הבאה:

   gcloud container operations wait OPERATION_ID
   

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

עדכון לקוחות API

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

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

gcloud container clusters get-credentials CLUSTER_NAME \
    --location LOCATION

עדכון פרטי הכניסה של ServiceAccount ב-Kubernetes

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

כדי למצוא פרטי כניסה סטטיים של ServiceAccount שקיימים באשכול, מריצים את הפקודה הבאה:

kubectl get secrets --all-namespaces --field-selector type=kubernetes.io/service-account-token

אם הפלט של הפקודה הזו הוא No resources found, המשמעות היא שלקלאסטר אין פרטי כניסה סטטיים של ServiceAccount.

עדכון של כתובות IP וכללים לחומת אש שהוזנו ישירות לקוד

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

השלמת הסבב

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

gcloud container clusters update CLUSTER_NAME \
    --location=LOCATION \
    --complete-credential-rotation

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

ERROR: (gcloud.container.clusters.update) ResponseError: code=400, message=Node pool "test-pool-1" requires recreation.

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

שחזור אשכול אחרי שפג תוקף של רשות אישורים

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

x509: certificate has expired or is not yet valid

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

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

3. יוצרים מאגרי צמתים חדשים כדי להחליף את מאגרי הצמתים הקיימים.

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

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

5. מעדכנים את לקוחות Kubernetes API כדי להשתמש בפרטי הכניסה החדשים ובכתובת ה-IP החדשה של מישור הבקרה.

6. עדכון של פרטי כניסה סטטיים של Kubernetes ServiceAccount כדי להשתמש באסימונים שנחתמים על ידי רשות האישורים החדשה.

אם אי אפשר לשחזר את האשכול גם אחרי שמבצעים את השלבים האלה, צריך ליצור אשכול חדש.

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

• מידע נוסף על אובייקט Kubernetes Secret
• איך מחליפים את כתובת ה-IP של מישור הבקרה
• מידע ולמידה על שיטות מומלצות לשימוש ב-RBAC ב-GKE
• מידע נוסף על פתרון בעיות ב-GKE