ב-Google Distributed Cloud נעשה שימוש באישורים ובמפתחות פרטיים כדי לאמת ולהצפין חיבורים בין רכיבי המערכת באשכולות של המשתמשים. אשכול האדמין יוצר קבוצה חדשה של רשויות אישורים (CA) לכל אשכול משתמש, ומשתמש באישורי CA כדי להנפיק אישורי קצה נוספים לרכיבי המערכת. באמצעות אשכול האדמין, אפשר לנהל את ההפצה של אישורי ה-CA הציבוריים ושל זוגות המפתחות של אישורי העלה לרכיבי המערכת, כדי ליצור תקשורת מאובטחת ביניהם.
התכונה 'רוטציה של אישורי CA באשכול משתמשים' מאפשרת להפעיל רוטציה של אישורי המערכת המרכזיים באשכול משתמשים. במהלך רוטציה, אשכול האדמין מחליף את רשויות האישורים של מערכת הליבה של אשכול המשתמש ברשויות אישורים חדשות שנוצרו, ומפיץ את אישורי ה-CA הציבוריים החדשים ואת זוגות המפתחות של אישורי הקצה לרכיבי המערכת של אשכול המשתמש. הרוטציה מתבצעת בהדרגה, כדי שרכיבי המערכת יוכלו להמשיך לתקשר במהלך הרוטציה. חשוב לזכור שעומסי העבודה והצמתים מופעלים מחדש במהלך הרוטציה.
יש שלוש רשויות אישורים של המערכת שמנוהלות על ידי אשכול האדמין לכל אשכול משתמשים:
- רשות האישורים של etcd מאבטחת את התקשורת משרת ה-API לרפליקות של etcd, וגם את התנועה בין הרפליקות של etcd. ה-CA הזה הוא בחתימה עצמית.
- ה-CA של האשכול מאבטח את התקשורת בין שרת ה-API לבין כל לקוחות ה-API הפנימיים של Kubernetes (kubelets, controllers, schedulers). ה-CA הזה הוא בחתימה עצמית.
- רשות האישורים של שרת ה-proxy הקדמי מאבטחת את התקשורת עם ממשקי API נצברים. רשות האישורים הזו בחתימה עצמית.
יכול להיות גם שאתם משתמשים ברשות אישורים ארגונית כדי לחתום על האישור שהוגדר באמצעות האפשרות authentication.sni.
רשות האישורים הזו ואישור ה-SNI משמשים להצגת ה-API של Kubernetes ללקוחות מחוץ לאשכול. אתם מנהלים את ה-CA הזה ויוצרים באופן ידני את אישור ה-SNI. התכונה של החלפת ה-CA באשכול המשתמש לא משפיעה על ה-CA הזה או על אישור ה-SNI.
מגבלות
שימו לב למגבלה הבאה באשכולות מתקדמים:
- גרסה 1.31: אין תמיכה בהחלפת אישורים (CA) באשכולות מתקדמים.
- גרסה 1.32 ואילך: רוטציית CA נתמכת באשכולות מתקדמים, אבל יש כמה הבדלים קלים שצוינו במקומות הרלוונטיים במסמך הזה.
רוטציית אישורי ה-CA מוגבלת ל-etcd, לאשכול ול-front-proxy CAs שצוינו קודם.
רוטציה של אישורי CA מוגבלת לאישורים שהונפקו באופן אוטומטי על ידי Google Distributed Cloud. היא לא מעדכנת אישורים שהונפקו באופן ידני על ידי אדמין, גם אם האישורים האלה נחתמו על ידי רשויות האישורים של המערכת.
רוטציה של רשות אישורים מפעילה מחדש את שרת ה-API, תהליכים אחרים של מישור הבקרה וכל צומת באשכול כמה פעמים. כל שלב ברוטציה של רשות האישורים מתקדם באופן דומה לשדרוג של אשכול. למרות שאשכול המשתמשים נשאר פעיל במהלך רוטציה של CA, צריך לצפות לכך שעומסי העבודה יופעלו מחדש ויתזמנו מחדש. בנוסף, אם באשכול המשתמשים שלכם אין מישור בקרה עם זמינות גבוהה, צפויים להיות פרקי זמן קצרים של השבתה של מישור הבקרה.
אחרי רוטציה של CA, צריך לעדכן את קובץ ה-kubeconfig של אשכול המשתמשים ואת קובצי ההגדרה של האימות. הסיבה לכך היא שהאישור הישן של האשכול בוטל, ופרטי הכניסה בקובץ kubeconfig כבר לא פועלים.
אחרי שמתחילים רוטציה של רשות אישורים, אי אפשר להשהות או לבטל אותה.
השלמת רוטציה של CA עשויה להימשך זמן רב, בהתאם לגודל של אשכול המשתמשים.
ביצוע רוטציה של רשות אישורים
מתחילים את הסבב:
gkectl update credentials certificate-authorities rotate \ --config USER_CLUSTER_CONFIG \ --kubeconfig ADMIN_CLUSTER_KUBECONFIGמחליפים את מה שכתוב בשדות הבאים:
USER_CLUSTER_CONFIG: הנתיב של קובץ התצורה של אשכול המשתמש
ADMIN_CLUSTER_KUBECONFIG: הנתיב לקובץ ה-kubeconfig של אשכול האדמין
ההתנהגות של הפקודה משתנה בהתאם להפעלה של אשכול מתקדם:
מושבתת
אם לא מפעילים את האפשרות advanced cluster באשכול, הפקודה היא אסינכרונית, היא מתחילה את רוטציית ה-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.