החלפת רשויות האישורים של אשכול המשתמשים

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

מידע על רשויות אישורים של אשכולות משתמשים

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

• רשות האישורים של etcd מאבטחת את התקשורת משרת ה-API לרפליקות של etcd, ואת התנועה בין הרפליקות של etcd.
• רשות האישורים של האשכול מאבטחת את התקשורת בין שרת ה-API לבין כל לקוחות ה-API הפנימיים של Kubernetes (רכיבי kubelet, בקרים, מתזמנים).
• רשות האישורים של שרת ה-proxy הקדמי מאבטחת את התקשורת עם ממשקי API נצברים.

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

מגבלות

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

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

  • גרסה 1.31: אין תמיכה ברוטציית CA באשכולות מתקדמים.
  • גרסה 1.32 ואילך: רוטציית CA נתמכת באשכולות מתקדמים, אבל יש כמה הבדלים קלים שצוינו במקומות הרלוונטיים במסמך הזה.

• רוטציית אישורי ה-CA מוגבלת ל-etcd, לאשכול ול-front-proxy CAs שצוינו קודם.

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

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

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

• אחרי שמתחילים רוטציה של CA, אי אפשר להשהות או לבטל אותה.

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

ביצוע רוטציה של רשות אישורים

1. מתחילים את הסבב:

   gkectl update credentials certificate-authorities rotate \
       --config USER_CLUSTER_CONFIG \
       --kubeconfig ADMIN_CLUSTER_KUBECONFIG
   

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

   • ‫USER_CLUSTER_CONFIG: הנתיב של קובץ התצורה של אשכול המשתמש

   • ‫ADMIN_CLUSTER_KUBECONFIG: הנתיב לקובץ kubeconfig של אשכול האדמין

ההתנהגות של הפקודה משתנה בהתאם להגדרה של אשכול מתקדם:

מושבתת

אם באשכול לא מופעל אשכול מתקדם, הפקודה היא אסינכרונית והיא מתחילה את רוטציית ה-CA ואז יוצאת. אין צורך לעקוב אחרי הפלט של הפקודה לאורך כל משך הזמן של רוטציית ה-CA. במקום זאת, אפשר לבדוק מדי פעם את ההתקדמות על ידי הפעלת הפקודה gkectl update credentials certificate-authorities status.

אם רוטציית ה-CA מתחילה בהצלחה, תופיע הודעה דומה לזו:

successfully started the CA rotation with CAVersion 2, use gkectl update credentials certificate-authorities status command to view the current state of CA rotation

אם כבר מתבצעת רוטציה של רשות אישורים, תופיע הודעת שגיאה דומה לזו:

Exit with error:
admission webhook "vonpremusercluster.onprem.cluster.gke.io" denied the request: requests must not modify CAVersion when cluster is not ready: ready condition is not true: ClusterCreateOrUpdate: Creating or updating user cluster control plane workloads

כדי לראות את סטטוס הרוטציה:

gkectl update credentials certificate-authorities status \
    --config USER_CLUSTER_CONFIG \
    --kubeconfig ADMIN_CLUSTER_KUBECONFIG

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

אם רוטציית ה-CA כבר הושלמה, תופיע הודעה דומה לזו:

State of CARotation with CAVersion 2 is -
status: True,
reason: CARotationCompleted,
message: Control plane has CA bundle [2], certs from CA 2, CA 2 is CSR signer. Data plane has CA bundle [2], CA 2 was CSR signer at last restart.

אם רוטציית ה-CA עדיין מתבצעת, תופיע הודעה דומה לזו:

State of CARotation with CAVersion 2 is -
status: False,
reason: CARotationProgressed,
message: Control plane has CA bundle [1 2], certs from CA 2, CA 1 is CSR signer. Data plane has CA bundle [1 2], CA 1 was CSR signer at last restart.

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

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

מורידים קובץ kubeconfig חדש:

kubectl --kubeconfig ADMIN_CLUSTER_KUBECONFIG get secret admin \
  -n USER_CLUSTER_NAME -o jsonpath='{.data.admin\.conf}' \
  | base64 --decode > USER_CLUSTER_NAME-kubeconfig

מופעל

אם האשכול המתקדם מופעל, הפקודה gkectl update credentials certificate-authorities rotate היא סינכרונית. הפקודה מפיקה הודעות סטטוס לתחנת העבודה של האדמין בזמן שרוטציית ה-CA מתבצעת.

אחרי שהרוטציה של ה-CA מסתיימת, הפקודה מסתיימת ונוצר באופן אוטומטי קובץ kubeconfig חדש. פלט הפקודה מספק את השם של קובץ ה-kubeconfig החדש, והוא דומה לזה:

Beginning CA rotation with generated CA
...
Successfully rotated CA for user cluster "USER_CLUSTER_NAME". The
kubeconfig file "/home/ubuntu"/USER_CLUSTER_NAME-kubeconfig" has
been updated.

הקובץ kubeconfig החדש נמצא באותה ספרייה שבה נמצא הקובץ kubeconfig של אשכול האדמין שציינתם בפקודה. השם של ה-kubeconfig החדש הוא USER_CLUSTER_NAME-kubeconfig.

הפצת קובץ kubeconfig החדש

מפיצים את קובץ ה-kubeconfig החדש לכל מי שמשתמש בקובץ kubeconfig כדי לתקשר עם האשכול.

עדכון קובצי תצורה של אימות

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

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

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

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

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

gkectl update credentials certificate-authorities status \
--config USER_CLUSTER_CONFIG \
--kubeconfig ADMIN_CLUSTER_KUBECONFIG

המידע מופיע בסוף השדה message תוך עשר שעות מהשדרוג. לדוגמה:

Last Leaf Certificates Rotation Version: 1.16.0-gke.0.

פתרון בעיות ברוטציה של רשות אישורים

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

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