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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

עדכון פרטי הכניסה של חשבון שירות ב-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 פג

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

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

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