יכול להיות שחלק מהמידע בדף הזה או כולו לא רלוונטי ל-Cloud de Confiance by S3NS. פרטים נוספים מופיעים במאמר מה ההבדל מ-Google Cloud.

Google uses AI technology to translate content into your preferred language. AI translations can contain errors.

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

טייס אוטומטי רגילה

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

מוודאים שיש לכם אשכול קיים של 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}'

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

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

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

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

אזהרה: יכול להיות שיתרחשו שגיאות ביצירה מחדש של צומת אם מנסים לבצע רוטציה אחרי שתוקף ה-CA של האשכול כבר פג. השגיאה הזו מסומנת ביומנים שמכילים את ההודעה הבאה: x509: certificate has expired or is not yet valid. כדי לנסות לתקן את השגיאה הזו, משלימים את הרוטציה, יוצרים מאגרי צמתים חדשים, מעבירים את עומסי העבודה ואז מוחקים את מאגרי הצמתים הישנים. עם זאת, מכיוון שבדרך כלל אי אפשר לשחזר אשכולות עם רשויות אישורים שתוקפן פג, יכול להיות שהניסיון הזה ייכשל ותצטרכו ליצור אשכול חדש.

אחרי שמגדירים מחדש את שרת ה-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 \
    --cluster-version=VERSION
```
מחליפים את VERSION בגרסת GKE זהה שבה כבר נעשה שימוש באשכול.
בקטרי סטנדרט, צריך לשדרג ידנית כל מאגר צמתים.

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

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

כדי לעקוב אחרי פעולת הרוטציה, מריצים את הפקודה הבאה:
```
gcloud container operations list \
    --filter="operationType=UPGRADE_NODES AND status=RUNNING" \
    --format="value(name)"
```
הפקודה הזו מחזירה את מזהה הפעולה של פעולת שדרוג הצומת.
כדי לבדוק את סטטוס הפעולה, מעבירים את מזהה הפעולה לפקודה הבאה:
```
gcloud container operations wait OPERATION_ID
```

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

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

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

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

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

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